Hardcoded bearer token in n8n
Why bearer tokens in HTTP headers expose your API access to anyone with workflow access
What is this issue?
A bearer token hardcoded in HTTP request headers is visible to anyone who can view the workflow. When you export, share, or commit the workflow, the token goes with it—giving others full access to your API.
Common patterns detected:
•Authorization: Bearer eyJhbGciOi... in HTTP Request headers•X-API-Key: sk-... in custom headers•Access tokens copied directly from API docs•OAuth tokens stored as header values
Why is this dangerous?
Token exposure
Anyone with read access to the workflow can copy and use your bearer token.
Export risks
Exported workflow JSON files contain the token in plain text.
Version control leaks
Tokens committed to Git repositories remain in history even after deletion.
Non-portability
Workflows with hardcoded tokens can't be shared or moved between environments.
How to fix it
- 1
Create n8n credential
Go to Settings → Credentials and create an HTTP Header Auth or API Key credential.
- 2
Reference credential in node
In HTTP Request node, select the credential from Authentication dropdown instead of manual headers.
- 3
Remove hardcoded token
Delete the Authorization header from the node after setting up credential-based auth.
- 4
Rotate exposed tokens
If the workflow was shared, consider the token compromised and generate a new one.
Scan your workflow now
Upload your n8n workflow JSON and detect bearer tokens and API keys in HTTP headers.