The Hidden Vulnerability in N8N's HTTP Request Node: Your API Keys Are Being Exposed

N8N, the popular workflow automation tool beloved by developers and operations teams alike, has a security risk hiding in its default configuration. A seemingly harmless setting may be writing your API keys into server logs — and you might have no idea it's happening.

The Problem Lives in the HTTP Request Node

The culprit is N8N's heavily-used HTTP Request Node. The issue isn't in how it sends requests — it's in how it handles the responses it gets back, especially when things go wrong.

By default, N8N logs the full response body to server logs. Most of the time, this seems harmless. But when an API call fails, servers often return detailed error messages — and those error messages may echo back exactly what you sent, including any secrets that were supposed to stay secret.

In other words, a single failed request is enough to land a plaintext API key in your log files. For anyone with log access, that's essentially leaving the keys on the table.

Why This Is a Serious Problem

What makes this kind of leak so dangerous is how quietly it happens. The key isn't stolen through some obvious exploit — your own system is actively and continuously writing it into the logs. It could be happening right now, completely unnoticed by your operations team.

Server logs are typically treated as "internal" data, but they're not especially locked down — developers, ops teams, third-party log aggregation services, and monitoring platforms may all have access. Once a plaintext credential enters that chain, its exposure surface expands dramatically. Worse, logs are often archived for extended periods, meaning a single bad error response could leave a key retrievable months or even years later.

For workflows handling payments, user data, or core business APIs, this default behavior is essentially a ticking time bomb.

From a security classification standpoint, this falls under Credential Exposure — unlike active attacks such as SQL injection or man-in-the-middle attacks, it's triggered entirely by the system's own behavior. Many enterprise compliance frameworks (such as SOC 2 and ISO 27001) explicitly prohibit plaintext credentials in logs. If flagged during an audit, you're looking at remediation pressure and potential damage to client trust. Third-party log aggregation services like Datadog, Splunk, and Elastic Stack store log data in the cloud, further expanding both the geographic reach and the range of parties who could access exposed keys. Additionally, many API providers (such as Stripe and OpenAI) actively revoke keys when they detect a leak — at which point every automated workflow depending on that key breaks simultaneously, causing a cascading business impact.

A Fix That Takes 15 Seconds

The good news: fixing this is remarkably simple, taking about 15 seconds per node.

Here's what to do: open the HTTP Request Node settings, find the Log Response Data option under the Response section, and toggle it to Never.

It's a tiny change, but it's critical for security. Once disabled, N8N will no longer write response bodies to server logs, cutting off the path to credential leakage at the source.

One important caveat: this setting is per-node. You'll need to apply it to every HTTP Request Node that handles sensitive data — don't assume a single global config will cover everything.

A Security Checklist for Automated Workflows

This case is also a reminder that low-code/no-code automation platforms lower the barrier to development, but they don't automatically lower security risk. Default configurations tend to prioritize "easy debugging" over "production safety."

Before deploying any N8N workflow that involves credentials, consider building these habits:

• Review the log settings on every HTTP Request Node and disable response logging for sensitive data
• For truly sensitive credentials, use N8N's built-in Credentials Manager rather than hardcoding values
• Periodically audit existing server logs for any plaintext keys that may have already slipped in — and rotate any affected credentials as needed
• Restrict log access permissions and set reasonable retention periods for log data

Security rarely comes from stacking up sophisticated technology. It comes from accumulating small actions like these — ones that take about fifteen seconds each. Protect your keys, and you protect your entire workflow.

N8N's Credentials Manager is the recommended way to handle sensitive information. It encrypts API keys and other credentials in the database, injecting them dynamically at runtime so they never appear as plaintext in node configurations or logs. For self-hosted N8N instances, make sure the database encryption key (set via the N8N_ENCRYPTION_KEY environment variable) is properly secured — otherwise the Credentials Manager's protections are significantly weakened. N8N Cloud handles encryption storage on the official side, but users still need to pay attention to workflow log configuration to prevent response data from being recorded at the platform level.