How to fix CORS misconfiguration

What an attacker can do

The concrete impact of leaving CORS Misconfiguration unpatched.

How to fix CORS Misconfiguration

6 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Decide: do you actually need CORS?

   If your API is only consumed by your own origin (same-origin SPAs), you don't need CORS at all. The safest CORS config is 'no CORS headers'.

   Many APIs that ship CORS don't actually need it — it was added 'just in case'. If your frontend is at app.example.com and your API is at api.example.com, you DO need CORS. If your frontend is at example.com and your API is at example.com/api, you DON'T need CORS. Remove the headers entirely; the browser's same-origin policy gives you protection for free.

   ExpressStep 1

   // If frontend and API are on the same origin, just don't use cors():
   import express from 'express';
   const app = express();
   
   app.get('/api/me', requireAuth, async (req, res) => {
     res.json({ user: req.user });
   });
   
   // No app.use(cors(...)) — browser same-origin policy protects you for free

2. 2

   Use an explicit allow-list of origins — never wildcard with credentials

   If you do need CORS, allow exactly the origins that need it. Listing them as strings (no regex). Never combine '*' with credentials.

   Wildcard origin (Access-Control-Allow-Origin: *) is OK for public APIs that don't use credentials (no cookies, no auth header). For ANYTHING credentialed, use specific origins. The CORS spec explicitly forbids wildcard + credentials and modern browsers reject it — but some servers still set both because of bad copy-paste, and CDN/proxy layers sometimes recombine headers in weird ways. Never set both.

   Express / cors middlewareStep 2

   import cors from 'cors';
   
   const ALLOWED_ORIGINS = new Set([
     'https://app.yourdomain.com',
     'https://www.yourdomain.com',
   ]);
   
   app.use(cors({
     origin: (origin, callback) => {
       // No origin = curl/server-side request → allow without CORS headers
       if (!origin) return callback(null, true);
       // Strict allow-list — exact match only, no regex
       if (ALLOWED_ORIGINS.has(origin)) return callback(null, origin);
       return callback(new Error('CORS: origin not allowed'));
     },
     credentials: true,
     methods: ['GET','POST','PUT','PATCH','DELETE'],
     allowedHeaders: ['Content-Type','Authorization'],
     maxAge: 600,
   }));

3. 3

   Reject Origin: null explicitly

   Sandboxed iframes (sandbox attribute), file:// URLs, and data: URIs all send Origin: null. Never accept null as an allowed origin.

   Origin: null is the silent ambush. Many CORS configs that allow-list specific origins forget to explicitly reject null. Attacker hosts a sandbox iframe on a static site (or even a saved HTML file the user opens locally), iframe makes the cross-origin request, browser sends Origin: null, server echoes 'null' as Allow-Origin, attack succeeds. Always check origin !== 'null' before adding it to the response.

   FastAPIStep 3

   from fastapi.middleware.cors import CORSMiddleware
   
   # Explicit list — null is NOT included
   app.add_middleware(
       CORSMiddleware,
       allow_origins=[
           "https://app.yourdomain.com",
           "https://www.yourdomain.com",
       ],
       allow_credentials=True,
       allow_methods=["GET","POST","PUT","PATCH","DELETE"],
       allow_headers=["Content-Type","Authorization"],
       max_age=600,
   )
   # Note: FastAPI's CORSMiddleware does not accept "null" by default
   # unless you add it explicitly — don't.

4. 4

   Use exact-match comparison, NOT regex or endsWith

   Regex like /\.example\.com$/ is a constant source of CORS bugs. notexample.com matches. example.com.evil.com matches. Use exact-string allow-lists.

   Common bug: regex /\.example\.com$/.test(origin). Looks fine. Fails: 'notexample.com' (no leading dot in regex). 'example.com' on its own. Worse: regex /example\.com$/ matches 'example.com.evil.com' if you forgot the $. The fix is exact-string membership testing — Set.has() in JS, in operator in Python, ImmutableSet.contains in Java. No regex. No endsWith. No clever string operations.

   Express — wrong vs rightStep 4

   // VULNERABLE — regex bugs
   const ALLOWED = /\.yourdomain\.com$/;
   function isAllowed(origin) {
     return ALLOWED.test(origin);
     // Matches: app.yourdomain.com ✓
     // Matches: notyourdomain.com ✗ (no leading dot in regex)
     // Matches: yourdomain.com.evil.com ✗ ($ at end of "evil.com" not yourdomain.com)
   }
   
   // SECURE — exact-string allow-list
   const ALLOWED = new Set([
     'https://app.yourdomain.com',
     'https://www.yourdomain.com',
     'https://admin.yourdomain.com',
   ]);
   function isAllowed(origin) {
     return ALLOWED.has(origin); // exact match, no edge cases
   }

5. 5

   Always set Vary: Origin to prevent cache poisoning

   If your server returns different Allow-Origin values for different request origins, Vary: Origin tells caches not to confuse them.

   Without Vary: Origin, CDNs and proxies cache the response with the first request's Allow-Origin and serve it to other origins. CDN sees 'Allow-Origin: app.example.com' first, caches the response, serves it to a request from evil.com — the cached header now allows evil.com. Vary: Origin tells the cache 'response varies based on Origin header — separate cache entry per origin'. Most CORS middleware sets this automatically, but custom CORS code often forgets.

   nginxStep 5

   location /api/ {
       # Allow-list with map for clean syntax
       set $cors_origin "";
       if ($http_origin = "https://app.yourdomain.com") {
           set $cors_origin $http_origin;
       }
       if ($http_origin = "https://www.yourdomain.com") {
           set $cors_origin $http_origin;
       }
   
       # Set CORS headers ONLY if origin is in the allow-list
       add_header Access-Control-Allow-Origin $cors_origin always;
       add_header Access-Control-Allow-Credentials true always;
       add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE" always;
       add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
       # CRITICAL — prevents cache from confusing origins
       add_header Vary "Origin" always;
   
       proxy_pass http://backend;
   }

6. 6

   Add unit tests for CORS attack patterns

   Test that attacker-controlled origins, null origin, regex-confusion strings get NO CORS allow header.

   Test pattern: send OPTIONS preflight + GET requests with various Origin headers — your domain (allowed), random domain (rejected), null (rejected), notexample.com (rejected), yourdomain.com.evil.com (rejected). Assert Access-Control-Allow-Origin is either absent or matches the request origin only when allow-listed.

   Jest / supertestStep 6

   const ALLOWED = 'https://app.yourdomain.com';
   const ATTACKS = [
     'https://evil.com',
     'null',
     'https://notyourdomain.com',
     'https://yourdomain.com.evil.com',
     'https://yourdomain.evil.com',
     'http://app.yourdomain.com',  // http downgrade
     '',
   ];
   
   describe('CORS allow-list enforcement', () => {
     it('allows the legitimate origin', async () => {
       const res = await api.get('/api/me')
         .set('Origin', ALLOWED);
       expect(res.headers['access-control-allow-origin']).toBe(ALLOWED);
     });
   
     describe.each(ATTACKS)('rejects attack origin %s', (attackOrigin) => {
       it('does NOT echo the origin in Access-Control-Allow-Origin', async () => {
         const res = await api.get('/api/me')
           .set('Origin', attackOrigin);
         const acao = res.headers['access-control-allow-origin'];
         expect([undefined, ALLOWED, 'null'].includes(acao)).toBe(false);
         // i.e. the server didn't blindly echo the attacker origin
         if (acao) expect(acao).not.toBe(attackOrigin);
       });
     });
   });