CORS vs CSRF: two confusingly-similar risks, explained

Few pairs of security terms get confused as often as these two. They look alike, they both involve requests between different origins, and people routinely reach for one when they mean the other. But they are not two versions of the same thing. One is a browser permission system you configure; the other is an attack you have to defend against. Getting them straight is the first step to handling both correctly.

CORS: a permission system

Cross-Origin Resource Sharing is a rule the browser enforces about which other origins are allowed to read responses from your API. By default the browser stops a page on one origin from reading responses from another, and CORS is how your server grants exceptions, for example letting your own frontend on one domain call your API on another. It is a setting. The danger is setting it too wide, like a wildcard origin with credentials, which lets any site read your API as your user. Details in CORS misconfiguration.

CSRF: an attack

Cross-Site Request Forgery is not a setting; it is a thing an attacker does. Another site causes a logged-in user's browser to send a request to your app, and because the browser attaches the session cookie automatically, your server treats it as legitimate and acts on it, changing an email, making a transfer. You defend against it with sameSite cookies and a CSRF token. Details in the broader picture and specifically in what CSRF is.

The trap: CORS does not stop CSRF

Here is the misunderstanding that causes real bugs. People assume a strict CORS policy protects them from CSRF. It does not. CORS controls whether a script can read your response. A CSRF attack does not care about reading the response; it only needs the request to happen and have an effect. The browser still sends it, your server still acts on it, and the attacker never needed to read anything. So you cannot rely on CORS for CSRF protection; they solve different problems.

What each one needs

• CORS: allowlist the specific origins your own frontend uses; never pair a wildcard origin with credentials. Fix for a CORS wildcard.
• CSRF: if you use cookie-based auth, set sameSite and require a CSRF token on state-changing requests. Fix for missing CSRF protection.

CORS configuration — correct vs dangerous

// Express — correct: allowlist your own origins only
const cors = require('cors');
app.use(cors({
  origin: ['https://yourapp.com', 'https://www.yourapp.com'],
  credentials: true, // only if you need cookies cross-origin
}));

// DANGEROUS: wildcard with credentials lets any site read your API as the user
app.use(cors({
  origin: '*',       // never pair this with...
  credentials: true, // ...this — browsers block it, but the intent is wrong
}));

// Next.js route handler — CORS headers
export async function GET() {
  return new Response(JSON.stringify(data), {
    headers: {
      'Access-Control-Allow-Origin': 'https://yourapp.com', // not '*'
      'Content-Type': 'application/json',
    },
  });
}

CSRF protection — sameSite cookies and tokens

// Set-Cookie with sameSite — prevents the browser sending the cookie cross-origin
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

// Express with csurf (or csrf package) — token on every state-changing route
const csrf = require('csrf');
const tokens = new csrf();

app.post('/change-email', (req, res) => {
  // Verify the CSRF token from the request header or body
  if (!tokens.verify(req.session.csrfSecret, req.body._csrf)) {
    return res.status(403).send('Bad token');
  }
  // safe to proceed
});

// Next.js App Router — Edge Middleware checking the Origin header
export function middleware(req) {
  const origin = req.headers.get('origin');
  const allowed = ['https://yourapp.com'];
  if (req.method !== 'GET' && !allowed.includes(origin)) {
    return new Response('Forbidden', { status: 403 });
  }
}

“Blocked by CORS policy” — what the browser error means

When you see Access to fetch at 'https://api.example.com/' from origin 'https://app.example.com' has been blocked by CORS policy, the browser is stopping your frontend from reading a response from a different origin because the server did not send an Access-Control-Allow-Origin header that permits it. This is not an attack — it is a missing permission. The fix is always server-side: add the right header or configure CORS middleware. Never disable CORS checking in the browser to work around it; that removes the protection entirely.

Frequently asked questions

Check both in your app

A scan flags a permissive CORS policy in what your app serves, and reviewing for CSRF is part of securing a cookie-authenticated app. Run a free scan and see how your app handles cross-origin access.