new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

csrf/fetch_metadata

9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Fetch Metadata headers for CSRF protection

Fetch Metadata request headers provide context about HTTP requests. The primary headers for CSRF protection are: Sec-Fetch-Site (indicates relationship between request initiator's origin and target's origin: same-origin, same-site, cross-site, or none), Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-User (provide additional context about request mode, destination type, or user-triggered navigation). Servers can use these headers as a lightweight method to block cross-site requests. Legacy browser fallback to standard origin verification is mandatory since some older browsers do not send Sec-Fetch-* headers.

Sec-Fetch-Site values and meanings

Sec-Fetch-Site header values: same-origin (request from same origin), same-site (request from same registrable domain but different origin/subdomain), cross-site (request from different registrable domain), none (user-driven navigation like bookmarks or typed URLs). The primary signal for CSRF protection is blocking non-safe methods (POST/PUT/PATCH/DELETE) when Sec-Fetch-Site is cross-site.

Fetch Metadata CSRF protection policy - safe methods check

Fetch Metadata CSRF policy implementation: If Sec-Fetch-Site is present and equals 'cross-site', reject non-safe methods by default. JavaScript code: const SAFE_METHODS = new Set(['GET','HEAD','OPTIONS']); const site = req.get('Sec-Fetch-Site'); if (site === 'cross-site' && !SAFE_METHODS.has(req.method)) { return false; } // forbid this request

Fetch Metadata CSRF protection for sensitive endpoints using safe methods

If application uses safe HTTP methods (GET, HEAD, OPTIONS) for state-changing actions, explicitly block cross-site requests to those endpoints. JavaScript code: const SAFE_METHODS = new Set(['GET','HEAD','OPTIONS']); const SENSITIVE_ENDPOINTS = new Set(['/user/profile', '/account/details']); const site = req.get('Sec-Fetch-Site'); const path = req.path; if (site === 'cross-site' && (!SAFE_METHODS.has(req.method) || SENSITIVE_ENDPOINTS.has(path))) { return false; } // forbid this request

Fetch Metadata handling of same-origin and same-site

For Fetch Metadata CSRF policy: Allow same-origin requests. For same-site requests, treat conservatively based on threat model - only allow if you trust all sibling subdomains. JavaScript code: const trustSameSite = false; if (site === 'same-origin') { return true; } else if (site === 'same-site') { if (!trustSameSite && !SAFE_METHODS.has(req.method)) { return false; } return true; }

Fetch Metadata allowing top-level navigation

To allow legitimate cross-site top-level navigation (e.g., links from other sites), use: if (req.get('Sec-Fetch-Mode') === 'navigate' && req.method === 'GET' && req.get('Sec-Fetch-Dest') !== 'object' && req.get('Sec-Fetch-Dest') !== 'embed') { return true; } // Allow this request

Fetch Metadata fallback requirement for legacy browsers

For legacy browsers that do not send Sec-Fetch-* headers, Fetch Metadata implementation must include a fallback strategy: either fail-safe (recommended for sensitive endpoints - treat absence as unknown and block), or fail-open (compatibility-first - fallback to standard origin verification, CSRF tokens, and/or additional validation).

Fetch Metadata requirements for deployment

Fetch Metadata CSRF protection requires: (1) Application must be served over trustworthy URLs (https, wss, file, localhost including 127.0.0.0/8 and ::1/128); (2) HTTPS must be enforced across entire application; (3) HTTP Strict Transport Security (HSTS) should be enabled to upgrade HTTP requests to HTTPS; (4) Safe HTTP methods (GET, HEAD, OPTIONS) should not be used for state-changing requests.

Vary header for Fetch Metadata responses

Include Vary header in responses to ensure caches handle them appropriately when using Fetch Metadata CSRF protection. Example: Vary: Sec-Fetch-Site, Origin. This is a response header applied after the server makes allow/deny decision, so it does not impact CSRF defense itself but serves operational purposes. Without Vary header, CDNs or proxies may reuse a response generated for a different context, causing broken behavior or cache-poisoning scenarios.

Give your agent this brain