Csrf Token On State Changing Requests
Any request that changes server state — POST, PUT, PATCH, DELETE — must be authenticated with something an attacker cannot forge from another origin.…
$ prime install @security/rule-csrf-token-on-state-changing-requests Projection
Always in _index.xml · the agent never has to ask for this.
CsrfTokenOnStateChangingRequests [rule] v0.1.0
Any request that changes server state — POST, PUT, PATCH, DELETE — must be authenticated with something an attacker cannot forge from another origin. The standard control is a per-session anti-CSRF token validated server-side. SameSite=Lax cookies provide partial coverage; the token is the explicit defence.
Loaded when retrieval picks the atom as adjacent / supporting.
CsrfTokenOnStateChangingRequests [rule] v0.1.0
Any request that changes server state — POST, PUT, PATCH, DELETE — must be authenticated with something an attacker cannot forge from another origin. The standard control is a per-session anti-CSRF token validated server-side. SameSite=Lax cookies provide partial coverage; the token is the explicit defence.
Checks
- State-changing endpoints reject requests without a valid anti-CSRF token (or a verified Origin/Referer header for fetch APIs).
- Token is bound to the session and rotated on login; verified server-side via constant-time comparison.
- GET requests are side-effect-free — never used for state changes; if a GET would mutate, it's the wrong verb.
- JSON APIs require a custom request header (e.g.
X-Requested-With: XMLHttpRequest) that browsers will not auto-send cross-origin without CORS preflight, OR the same anti-CSRF token. - Session cookies use
SameSite=Laxminimum (seerule-session-cookie-secure-flags).
Label
Every state-changing request carries a CSRF token or equivalent
Loaded when retrieval picks the atom as a focal / direct hit.
CsrfTokenOnStateChangingRequests [rule] v0.1.0
Any request that changes server state — POST, PUT, PATCH, DELETE — must be authenticated with something an attacker cannot forge from another origin. The standard control is a per-session anti-CSRF token validated server-side. SameSite=Lax cookies provide partial coverage; the token is the explicit defence.
Checks
- State-changing endpoints reject requests without a valid anti-CSRF token (or a verified Origin/Referer header for fetch APIs).
- Token is bound to the session and rotated on login; verified server-side via constant-time comparison.
- GET requests are side-effect-free — never used for state changes; if a GET would mutate, it's the wrong verb.
- JSON APIs require a custom request header (e.g.
X-Requested-With: XMLHttpRequest) that browsers will not auto-send cross-origin without CORS preflight, OR the same anti-CSRF token. - Session cookies use
SameSite=Laxminimum (seerule-session-cookie-secure-flags).
Label
Every state-changing request carries a CSRF token or equivalent
Label
Every state-changing request carries a CSRF token or equivalent
Source
prime-system/examples/security-appsec/primes/compiled/@security/rule-csrf-token-on-state-changing-requests/atom.yaml