OriginOrRefererValidated [check] v0.1.0

Label

State-changing requests verify Origin or Referer matches the app

Assertion

For state-changing endpoints, the server inspects the Origin header (preferred) or falls back to Referer, and rejects requests where the value is absent or does not match an allow-listed origin (the application's own origin and any explicitly trusted partners).

Evidence

• Server middleware extracts Origin (or Referer if absent) on POST/PUT/PATCH/DELETE requests.
• Allow-list of accepted origins is explicit and short; CORS policy mirrors it.
• Requests with neither header (rare, but possible from old user agents or stripped by intermediaries) are rejected for state-changing routes.
• Denials are logged with origin, route, and user for later review.

Failure Mode

If only the CSRF token is checked and the token is leaked (XSS, log file, browser extension), an attacker can still forge requests. Origin check makes the same exploit need an additional bypass.

OriginOrRefererValidated [check] v0.1.0

Label

State-changing requests verify Origin or Referer matches the app

Assertion

For state-changing endpoints, the server inspects the Origin header (preferred) or falls back to Referer, and rejects requests where the value is absent or does not match an allow-listed origin (the application's own origin and any explicitly trusted partners).

Evidence

• Server middleware extracts Origin (or Referer if absent) on POST/PUT/PATCH/DELETE requests.
• Allow-list of accepted origins is explicit and short; CORS policy mirrors it.
• Requests with neither header (rare, but possible from old user agents or stripped by intermediaries) are rejected for state-changing routes.
• Denials are logged with origin, route, and user for later review.

Failure Mode

If only the CSRF token is checked and the token is leaked (XSS, log file, browser extension), an attacker can still forge requests. Origin check makes the same exploit need an additional bypass.

Rationale

Origin/Referer checks are a cheap second layer alongside CSRF tokens. The browser sets Origin on cross-origin POSTs and on some same-origin POSTs; it cannot be set by attacker JS via a fetch from a victim browser. Combined with a CSRF token, an attacker has to break both.

Label

State-changing requests verify Origin or Referer matches the app

Assertion

For state-changing endpoints, the server inspects the Origin header (preferred) or falls back to Referer, and rejects requests where the value is absent or does not match an allow-listed origin (the application's own origin and any explicitly trusted partners).

Evidence

• Server middleware extracts Origin (or Referer if absent) on POST/PUT/PATCH/DELETE requests.
• Allow-list of accepted origins is explicit and short; CORS policy mirrors it.
• Requests with neither header (rare, but possible from old user agents or stripped by intermediaries) are rejected for state-changing routes.
• Denials are logged with origin, route, and user for later review.

Failure Mode

If only the CSRF token is checked and the token is leaked (XSS, log file, browser extension), an attacker can still forge requests. Origin check makes the same exploit need an additional bypass.