Origin Or Referer Validated
@security/check-origin-or-referer-validated
$ prime install @security/check-origin-or-referer-validated Projection
Always in _index.xml · the agent never has to ask for this.
OriginOrRefererValidated [check] v0.1.0
Loaded when retrieval picks the atom as adjacent / supporting.
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(orRefererif 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.
Loaded when retrieval picks the atom as a focal / direct hit.
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(orRefererif 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(orRefererif 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.
Source
prime-system/examples/security-appsec/primes/compiled/@security/check-origin-or-referer-validated/atom.yaml