DEV Community: Dipta

CSRF, and the cookie flag

Dipta — Sat, 30 May 2026 12:35:20 +0000

<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>

Five lines of HTML on a malicious page. When a user who's logged into bank.com in another tab visits this page, the browser auto-submits the form, attaches their session cookie, and ten thousand dollars leave their account.

They didn't click anything. The malicious site didn't see their password. There was no XSS, no breach, no leak in the traditional sense. The browser did exactly what it was designed to do.

That's CSRF — Cross-Site Request Forgery — and it's been the classic "confused deputy" attack on the web for two decades. Let's walk through what makes it work, why CORS doesn't help, and the one cookie flag that mostly killed it around 2020.

Why the browser attaches your cookie to that request

Cookies belong to a domain. When you log into bank.com, the bank sets a session cookie in your browser:

Set-Cookie: session=abc123; HttpOnly

From that point on, every single request your browser sends to bank.com carries that cookie. Every page load. Every API call. Every image fetch. The browser does it automatically, without asking, and regardless of who triggered the request.

That last word is the door CSRF walks through. The browser attaches the cookie based on where the request is going, not where it came from. So when evil.com triggers a POST to bank.com/transfer, the browser sees a request destined for bank.com, looks up the cookies for bank.com, and attaches them. As far as the bank's server can tell, the request looks exactly like one the user submitted from inside the bank's own page.

This is the "confused deputy" idea. Your browser is the deputy. It has authority on your behalf (your cookies). And it's been tricked into using that authority for someone else's benefit. The server has no way to tell the difference, because from its point of view, there isn't one.

Why CORS doesn't help

It's a fair guess that CORS would stop this. The request is cross-origin. CORS controls cross-origin behavior. So CORS should block it, right?

It doesn't.

CORS controls what JavaScript can read from a cross-origin response. It says nothing about whether the request gets sent. And in CSRF, the attacker doesn't care about reading anything back. The damage is done by the time the response comes back.

There's a second wrinkle that makes this worse. Plain form submissions and image loads — both of which can carry cookies — don't trigger a CORS preflight at all. The browser just sends them. So a <form method="POST"> posting from evil.com to bank.com is, from the browser's perspective, an ordinary cross-site form submission. There's nothing for CORS to check, and nothing for the server to refuse.

CORS protects what JavaScript can see. CSRF is about what the server is tricked into doing. Different attacks, different layers.

What actually stops it

So what does? Two defenses. One classic, one modern.

The CSRF token (classic). When bank.com renders the transfer page, the server embeds a random, unguessable token in the form:

<form action="/transfer" method="POST">
  <input name="to">
  <input name="amount">
  <input type="hidden" name="csrf_token" value="9f3e8a7b12...">
</form>

The server checks the token when the form comes back. If it matches the one issued to this session, the request is legitimate. If it doesn't, or it's missing, the request is rejected.

This works because evil.com has no way to learn the token. Same-origin policy stops it from reading bank.com's pages, which is where the token lives. The attacker can build a fake form, but they can't put a valid token in it. The request arrives at the server with no token, the check fails, and the request is dropped. This is what Django, Rails, and Laravel do by default.

SameSite cookies (modern). Set the cookie like this:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

SameSite=Lax tells the browser: don't attach this cookie to requests coming from a different site, except for top-level GET navigations (clicking a link still works). So when evil.com triggers a POST to bank.com, the browser sees a cross-site origin and drops the cookie from the request. The bank receives an unauthenticated request and rejects it. The whole attack collapses at the cookie layer, before the server has to think about it.

Chrome started treating unspecified cookies as SameSite=Lax by default in 2020. Firefox and Safari followed. A huge chunk of CSRF on the web was quietly killed by that one change. If you're shipping anything new, set SameSite=Lax (or Strict for high-sensitivity cookies) explicitly, and you're most of the way there.

The one thing these defenses don't help with

Neither of them helps against XSS. If an attacker can run JavaScript inside your own origin — say, a forgotten dangerouslySetInnerHTML, an unsanitized rich-text input, a compromised dependency — the cookie is "same site" to that script, and any CSRF token in the page is readable. Both defenses assume your origin is trustworthy. If it isn't, CSRF is the smallest of your problems.

This is the boring lesson that keeps showing up across web security: each defense covers one layer, and stacking them is what keeps you safe. SameSite for CSRF. HttpOnly for cookie theft. CSP for XSS. None of them alone is enough. Together they cover most real cases.

What's actually going on with CORS, under the hood

Dipta — Sat, 23 May 2026 16:29:46 +0000

CORS is one of those things every web developer runs into sooner or later. Most of us know how to fix it — add a header, change a config, ask the backend person to "do something about CORS." But how many of us actually understand what the browser is doing in the background, and why it's doing it?

Let's go through it today, slowly, with a simple example.

What's an "origin"?

Before we get into CORS, there's one word we need to pin down: origin. An origin is three things put together — the scheme, the host, and the port of a URL.

So https://example.com and http://example.com are different origins because the scheme is different (https vs http). https://example.com and https://api.example.com are different because the host is different. And https://example.com and https://example.com:8080 are different because the port is different. If any one of those three pieces changes, the browser treats it as a separate origin.

This matters because the browser treats every origin as its own little sandbox. Whatever happens inside one origin is supposed to stay inside that origin.

The browser's default rule

By default, JavaScript running on one origin is not allowed to read data from another origin. This rule has a name: same-origin policy. Every modern browser ships with it built in, and it's the foundation that everything else here is built on.

Without it, the web would be terrifying. Imagine you're logged into your bank in one tab. In another tab, you visit some random site. If same-origin policy didn't exist, that random site could just do this in the background:

fetch('https://yourbank.com/api/balance')
  .then(res => res.json())
  .then(data => sendToAttacker(data))

The browser would happily send the request, attach your bank cookies (because the cookies belong to the bank's domain), and the bank would return your balance to whoever asked. The random site's JavaScript would then read the response and send it anywhere it wanted. Every site you visit would be able to scrape every site you're logged into.

Same-origin policy stops that. The browser still sends the request, but it refuses to let the random site's JavaScript read the response. The request happens; the response gets blocked from reaching the calling code.

So what is CORS?

CORS stands for Cross-Origin Resource Sharing, and it's the mechanism a server uses to say "actually, it's fine, this other origin is allowed to read my response." It's an opt-in to relax same-origin policy in cases where cross-origin access is legitimate.

The most common case is your own setup. Your frontend lives at app.example.com, your API lives at api.example.com. Different origins, so same-origin policy would block the frontend's calls by default. CORS is how your API tells the browser "yes, app.example.com is allowed."

How does the API tell the browser that? Through a response header:

Access-Control-Allow-Origin: https://app.example.com

When the browser sees this header on the response, it lets your JavaScript read it. Without it, the response is blocked and you see a CORS error in the console.

One thing worth noticing here, because it confuses a lot of people: if your frontend and API are on the same origin during development — say both on localhost:3000 behind a Next.js rewrite — CORS doesn't kick in at all. The browser doesn't even check the headers, because nothing cross-origin is happening. CORS issues often only show up in production, when frontend and API are on different domains.

A simple example, end to end

Let's walk through one fetch from start to finish.

Your frontend at https://app.example.com does:

fetch('https://api.example.com/users')

Here's what actually happens:

The browser builds the request. It automatically adds a header: Origin: https://app.example.com. This is the browser telling the server "this request is coming from app.example.com."
The browser sends the request to api.example.com. The server receives it like any other request and processes it. It can read the database, run business logic, return data — whatever. From the server's point of view, this is a normal request.
The server sends a response back, say with the user list as JSON.
The browser receives the response and checks the headers. Specifically, it looks at Access-Control-Allow-Origin. If that header is missing, or if its value doesn't match https://app.example.com (or *), the browser blocks the response. The JavaScript that called fetch sees a CORS error, and the response body is never delivered to your code.
If the header is present and matches, the browser hands the response to the JavaScript, and your code continues normally.

This is the part that most explanations of CORS skip over: the server doesn't refuse the request. The browser does. The server returned a perfectly fine response. The browser refused to hand it to the JavaScript because the server didn't include the right header saying "this origin is allowed."

That's also why you can hit the same API from curl, from Postman, or from a server-to-server call and it just works. CORS only exists in browsers. Other clients don't enforce same-origin policy, so there's nothing to block.

What about complex requests? Preflight

For "simple" requests — basically GETs and a few POSTs with safe content types — the browser sends the actual request directly and checks the response headers afterwards.

But for anything more involved — a PUT, a DELETE, a request with a custom header like Authorization, or a JSON-typed POST — the browser does an extra step first. It sends a preflight request.

A preflight is an OPTIONS request to the same URL, sent before the real one. It looks like:

OPTIONS /users HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization, Content-Type

The browser is essentially asking the server: "I'm about to send a DELETE with these headers. Are you okay with that?"

The server responds with what it allows:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type

If the browser is happy with the preflight response, it then sends the real request. If the preflight fails, the real request never goes out at all.

This is why you sometimes see two requests in the network tab for what looks like a single fetch. The first is the preflight; the second is the actual call.

The credentials catch

There's one extra rule worth knowing, because it catches a lot of people off guard. If your frontend sends credentials with the request — cookies, an Authorization header, anything that identifies the user — like this:

fetch('https://api.example.com/me', {
  credentials: 'include',
})

Then a wildcard Access-Control-Allow-Origin: * is no longer enough. The browser refuses to deliver the response. The server has to name the specific origin it trusts, and add one more header:

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

The reason is security. If * worked alongside credentials, any malicious site could fire authenticated requests to your API. The browser would attach the user's cookies (because cookies belong to the API's domain, not the calling page's). The server would see "any origin is allowed" and respond. The malicious site's JavaScript would then read the response — and every authenticated API on the web would be one fetch away from being scraped.

So the rule is: * is fine for genuinely public APIs that don't care who's calling. As soon as authentication enters the picture, the server has to be explicit about which origins it trusts.

Wrapping up

Here's the whole picture in one line: the browser blocks cross-origin reads by default (same-origin policy), and CORS is the mechanism a server uses to opt in to allowing them, through response headers like Access-Control-Allow-Origin.

A few things worth remembering when you next see a CORS error in the console.

The browser is the one doing the blocking, not the server. The server happily sends the response either way; the browser decides whether your JavaScript gets to see it. That's why CORS errors only happen in the browser, never in curl or server-to-server calls.

For non-simple requests, the browser sends an OPTIONS preflight first to ask the server what's allowed. Two network requests for one fetch — that's why.

And if credentials are involved, the wildcard stops working. The server has to name the origin explicitly and add Access-Control-Allow-Credentials: true.

CORS isn't there to annoy developers. It's a security feature that protects users from sites that would otherwise be able to read their data from other sites. Once you see what it's protecting, the error messages start making more sense — and the fix usually comes down to figuring out exactly which header the browser wants to see, and making sure your server is sending it.

When dev and prod disagree about your CSS

Dipta — Fri, 15 May 2026 15:45:36 +0000

This started right after we shipped a production release of our feature. One of our engineers was running through the change to confirm everything looked right, and the issue caught his eye — since it's a UI thing, it was easy to spot. The CSS width of some components was broken. In the development environment everything had been fine, working perfectly. But in production it wasn't. He reported it. So I started digging.

The first instinct was the wrong one. I dropped an !important on the rule, the width snapped back to what it should be, and I almost called it a day. Then I realized I'd just patched a symptom without understanding the cause — and a bug that behaves differently between dev and prod is exactly the kind of bug that comes back six months later in a different file. So I rolled the !important back out and tried to actually figure out what was happening.

What was colliding

The element in question was a form label. It was being styled by two CSS Module rules at the same time:

/* shared component — shared.module.css */
.label { width: 20.75rem; }

/* my page(comsumer) — mypage.module.css */
.fieldLabel { width: 11rem; }

The shared component does this internally:

/* styles.label is the shared component's own class from its CSS module. 
 * labelClassName is whatever class the caller passed in. 
 * mergeClassNames is just a helper that glues class strings together — same idea as clsx. 
 * The element ends up with both classes on it.
 */ 
<label className={mergeClassNames(styles.label, labelClassName)} >My Label</label>

So both classes were ending up on the same element. The browser now has to decide which width wins. Two rules, both at specificity (0,1,0) — one class each. A clean tie. And on a tie, CSS falls back to source order: whichever rule appears later in the final stylesheet wins.

In dev mine appeared later, so 11rem won. In production the shared rule appeared later, so 20.75rem won. Same code. Different outcomes.

The build had flipped the order on me.

How I confirmed it

I built and grepped the output to make sure I was right about which rule was winning:

npm run build
grep -E "11rem|20.75rem" out/_next/static/chunks/<the-file>.css

Sure enough, both rules were sitting inside the same CSS chunk file. Mine came first, theirs came second. The tie-breaker said "later wins." Mine was "earlier." Mine lost.

DevTools confirmed it too. Inspect the element in production, open the Styles panel, my rule was struck through. Hovering it, Chrome politely informed me it had been overridden by a rule with equivalent specificity that appeared later in the stylesheet.
The browser was doing exactly what it was supposed to. I just hadn't been paying attention to which rule it considered "

Why dev and prod differ

This part was the most interesting thing I learned from the whole bug.

In development, Next.js doesn't bundle CSS. Each .module.css is injected at runtime as its own <style> tag, in the order JavaScript imports it. JavaScript imports go depth-first — so the children module's CSS ends up later in the DOM. Your override CSS, sitting at the leaf, naturally wins ties. It feels intuitive. It also lies, because nothing about that ordering is guaranteed.

In production, next build runs Turbopack. It uses Lightning CSS to extract CSS Modules into chunk files in out/_next/static/chunks/. Turbopack tries to follow JS import order when ordering CSS rules, but when a shared CSS module is reachable through multiple import paths (different pages, different parents), Turbopack has to pick one — and the chosen order may not match what dev's runtime-injected <style> tags produce.

For JavaScript that's fine — every module is independently identified and execution order is mostly its own concern. For CSS it's hostile. CSS rule order is part of the semantics. The bundler had just told me that part of the semantics wasn't mine to control.

The fix

I'd seen people fix this kind of thing with !important or with .root .fieldLabel to bump specificity. Both work and both leave a mess — every future override has to fight the same fight. The cleaner fix turned out to be one CSS function I'd never used before: :where().

I changed the shared component's rule to:

:where(.label) {
    width: 20.75rem;
    padding-top: 0.5rem;
}

:where(...) takes whatever selector you put inside and forces its specificity to zero. The shared component's default is now the weakest rule in the entire cascade. Anyone overriding it from the outside with even a single plain class wins automatically:

Shared default: 0,0,0
My override: 0,1,0 ← always wins

No source-order dependency. No tie to break. No reliance on whichever heuristic webpack happened to use this build.

This is, in retrospect, what :where() is for. It's the CSS equivalent of a default prop value — present if no one says otherwise, replaced freely the moment anyone does. If you maintain a shared UI component, every "default" style it ships should be wrapped this way. It costs you two extra characters and it saves every downstream caller from ever needing !important.

A second knob, for defense

I also turned on experimental.cssChunking: 'strict' in next.config.ts:

experimental: {
    cssChunking: 'strict',
}

This doesn't help the within-chunk race we just fixed — order inside a chunk is webpack's call regardless. But it does help with a separate, related issue: when Next.js merges CSS files imported in different orders across modules, 'strict' tells it to stop. It's Next.js's official "stop reordering my CSS" option. Worth turning on if you've hit any version of this bug once.

What I took away from it

A bug that behaves differently in dev and prod is almost always a sign that something you thought was deterministic isn't. In this case it was source order — something I'd been quietly relying on for years without noticing.

The way out, if there's a general lesson here, is to never write a fight between two equally-specific selectors. Pick a winner, on purpose. Either give your selector specificity that earns the win, or wrap the other one in :where() to demote it. Letting the cascade decide for you by accident is fine until the day a bundler version changes and it's not.

Two characters of :where() would have saved me an afternoon.