Step by Step Guide to solve n8n Webhook CORS Errors
Quick Diagnosis (Featured Snippet)
CORS errors in n8n webhooks occur because the browser blocks cross‑origin requests that lack a proper Access‑Control‑Allow‑Origin header. We cover this in detail in the n8n Webhook Errors.
| Step | Action | Where |
|---|---|---|
| 1 | Enable CORS in the n8n global config (N8N_CORS_ENABLED=true) |
.env or Docker env |
| 2 | Add the required header in the Webhook node (or a Function node) | Webhook → Headers tab |
| 3 | If behind a reverse proxy, forward the header or set it in the proxy (NGINX/Traefik) | Proxy config |
| 4 | Test with curl -I or the browser dev‑tools → 200 and Access-Control-Allow-Origin: * (or your domain) |
Verify |
After these steps the browser will stop blocking the request and the webhook will fire normally.
1. Why n8n Webhooks Trigger CORS Errors
If you encounter any authentication failure resolve them before continuing with the setup.
What happens: Browsers enforce CORS, requiring the server to explicitly allow a request from a different origin. n8n’s built‑in HTTP server does not send CORS headers by default, so a front‑end app calling https://n8n.example.com/webhook/my-hook from https://app.example.com receives a *“No ‘Access‑Control‑Allow‑Origin’ header”* error.
Security note: In production avoid
*forAccess-Control-Allow-Origin. Whitelist the exact origin(s) to prevent CSRF‑type attacks.
2. Core Causes of CORS Errors in n8n
If you encounter any ssl certificate issues resolve them before continuing with the setup.
| Cause | Symptom | Why it Happens |
|---|---|---|
Global CORS disabled (N8N_CORS_ENABLED=false) |
Browser blocks every webhook call | n8n never adds any CORS header |
| Missing header in Webhook node | 200 response but still blocked | Browser sees no Access-Control-Allow-Origin |
| Reverse proxy strips/overwrites headers | 200 from n8n, but proxy response lacks header | Proxy configuration (proxy_hide_header) removes it |
| Mixed HTTP/HTTPS origins | “Blocked by CORS policy” with Mixed Content warning |
Different schemes count as different origins |
Pre‑flight (OPTIONS) not handled |
405 Method Not Allowed on OPTIONS request |
n8n only responds to GET/POST by default |
3. Enabling CORS at the n8n Application Level
3.1. Set the environment variables
Add the variables to your Docker Compose file (or .env for a self‑hosted install).
services:
n8n:
image: n8nio/n8n
environment:
- N8N_CORS_ENABLED=true
- N8N_CORS_ALLOW_ORIGIN=https://app.example.com # restrict to your domain
– N8N_CORS_ENABLED toggles the built‑in CORS middleware.
– N8N_CORS_ALLOW_ORIGIN accepts a comma‑separated list of allowed origins (default *).
Tip: After editing, restart the container (
docker compose up -d) or reload the system service for a self‑hosted install.
3.2. Verify the header
Run a quick curl request to confirm the header is present:
curl -I https://n8n.example.com/webhook/test
Expected response headers (excerpt):
HTTP/2 200 access-control-allow-origin: https://app.example.com access-control-allow-credentials: true
If the header is missing, continue to the per‑webhook configuration in Section 4.
4. Adding CORS Headers Directly in a Webhook Node
When different webhooks need distinct origins, set headers on the node itself.
4.1. Header rows in the Webhook node
| Header | Value |
|---|---|
| Access-Control-Allow-Origin | https://app.example.com |
| Access-Control-Allow-Methods | GET,POST,OPTIONS |
| Access-Control-Allow-Headers | Content-Type,Authorization |
| Access-Control-Allow-Credentials | true |
4.2. Handle the pre‑flight OPTIONS request
Add a **Function** node after the Webhook to return a 204 response for pre‑flight checks.
// Detect an OPTIONS pre‑flight request
if (items[0].json.__requestMethod === 'OPTIONS') {
return [
{
json: {},
headers: {
'Access-Control-Allow-Origin': 'https://app.example.com',
'Access-Control-Allow-Methods': 'GET,POST,OPTIONS',
'Access-Control-Allow-Headers': 'Content-Type,Authorization',
'Access-Control-Max-Age': '86400',
},
statusCode: 204,
},
];
}
// Normal request – pass the payload downstream return items;
Security note: The pre‑flight handler must return 204 No Content; any other status may cause the browser to reject the request.
5. When n8n Runs Behind a Reverse Proxy
5.1. NGINX configuration
**Server block** – terminates TLS and forwards traffic to n8n:
server {
listen 443 ssl;
server_name n8n.example.com;
location / {
proxy_pass http://localhost:5678;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# Preserve CORS headers from n8n
proxy_pass_header Access-Control-Allow-Origin;
proxy_pass_header Access-Control-Allow-Methods;
proxy_pass_header Access-Control-Allow-Headers;
proxy_pass_header Access-Control-Allow-Credentials;
}
}
5.2. Traefik (Docker labels)
Define a CORS middleware:
labels: - "traefik.http.middlewares.cors.headers.accessControlAllowOrigin=https://app.example.com"
- "traefik.http.middlewares.cors.headers.accessControlAllowMethods=GET,POST,OPTIONS"
- "traefik.http.middlewares.cors.headers.accessControlAllowHeaders=Content-Type,Authorization"
- "traefik.http.routers.n8n.middlewares=cors@docker"
Best practice: Do not set
Access-Control-Allow-Origin: *in the proxy if you already restrict it in n8n; the most restrictive header wins.
6. Debugging Checklist
| Check List | Item |
|---|---|
| ✔ | N8N_CORS_ENABLED=true in environment |
| ✔ | N8N_CORS_ALLOW_ORIGIN matches the calling domain |
| ✔ | Webhook node contains the required header rows |
| ✔ | OPTIONS pre‑flight returns a 204 response |
| ✔ | Proxy forwards all Access-Control-* headers |
| ✔ | No mixed‑content warnings (both sides use HTTPS) |
| ✔ | Browser dev‑tools → Network → Response Headers show the header |
| ✔ | curl -I shows the header (isolates proxy vs n8n) |
If any check fails, revisit the corresponding section.
7. Production‑Grade Tips
| Tip | Reason |
|---|---|
Whitelist origins instead of * |
Prevents malicious sites from abusing your webhook |
Enable Access-Control-Allow-Credentials only when needed |
Allows cookies/Authorization headers; otherwise keep it false |
Log rejected origins (capture __requestHeaders.origin in a Function node) |
Helps audit abuse attempts |
| Rate‑limit the webhook (use n8n’s **Rate Limit** node) | Mitigates DoS attacks that could bypass CORS checks |
| Enforce HTTPS everywhere | Browsers block insecure origins from secure pages, which appears as a CORS issue |
8. Frequently Asked Questions
- Q1. Do I need to set CORS both in n8n and the proxy?
A: If the proxy forwards the header unchanged, configuring n8n alone is sufficient. If the proxy adds its own CORS headers, ensure they are consistent or let the proxy handle CORS exclusively. - Q2. My front‑end still shows “CORS header ‘Access‑Control‑Allow‑Origin’ missing”.
A: Verify that anOPTIONShandler exists. Add the Function node snippet from Section 4.2 to return a 204 response. - Q3. Can I disable CORS for a single webhook while keeping it enabled globally?
A: Yes. KeepN8N_CORS_ENABLED=trueglobally, then override per webhook by adding a header with a different origin or by returningAccess-Control-Allow-Origin: nullin a Function node.
10. Next Steps
- Secure your webhook with HMAC verification – see the child page “n8n webhook signature validation”.
- Automate CORS configuration across many workflows using the n8n API – see “Programmatic webhook creation with proper CORS”.
By following this guide you’ll eliminate CORS blocks, keep your n8n instance secure, and ensure reliable communication between your front‑end applications and n8n webhooks.
