State-changing requests need separate anti-forgery checks because browsers automatically attach ambient credentials such as cookies, so a malicious site can trigger an authenticated action without reading the response. An origin check, CSRF token, or same-site cookie control verifies the request came from the intended application, not just from an authenticated browser session.
Why anti-forgery checks are separate from login checks
Authentication answers “who is the browser session acting for?”, but anti-forgery checks answer “did this request originate from the site the user intended to use?” That separation matters because a valid session cookie can be replayed by the browser on a cross-site request. The control is therefore about request origin and intent, not about re-authenticating the user.
For state-changing actions, the server needs a second signal that is harder for another site to forge. A CSRF token, origin validation, or SameSite cookie policy gives the application a way to distinguish an intentional form submission or API call from an ambient browser request that happened to carry credentials.
That is also why safe state-changing design usually distinguishes read-only traffic from actions that alter data, permissions, or money movement. The action boundary is where browser convenience becomes a security risk, so the application must verify more than “the user is signed in.”
What these checks verify in practice
A robust anti-forgery control checks that the request was generated by your application flow, not merely delivered by an authenticated browser. In common web stacks, that means comparing a server-issued token, validating the request origin or referer where appropriate, and using cookie settings that reduce cross-site credential attachment. The exact combination depends on the framework and browser behavior.
The important operational point is that the check belongs on the action itself. If a request creates, deletes, transfers, approves, or changes something material, the application should require a state-changing proof at the same trust boundary as the action, not rely on the user having previously logged in.
This is easiest to see in workflows that already rely on browser sessions. CSRF Prevention Guide covers the main defensive patterns, including synchroniser and signed double-submit tokens, Fetch Metadata, origin checks, and SameSite cookie settings.
For teams that want the broader web-app context, Web Application Attacks Guide places CSRF alongside related request-manipulation issues such as request smuggling and missing origin validation, which helps teams avoid treating anti-forgery as a one-off feature.
Where state-changing requests fail when anti-forgery is missing
The failure mode is not usually response theft. The attacker often does not need to read anything back. Instead, the browser silently sends authenticated cookies, and the victim’s session becomes a transport layer for an unwanted action. That is enough to change an email address, alter an approval, submit a payment, or enable an account setting.
Risk rises when the action has no secondary confirmation, when it is reachable through a simple POST or GET, or when the application accepts browser credentials without checking origin or token state. In those cases, the attacker only needs the victim to visit a hostile page while logged in to the target site.
Cross-site request forgery is part of the same attack family that includes browser-driven action abuse more broadly. The usual defensive pattern is to make the request self-authenticating in a way the attacker cannot reproduce from another origin.
For application teams looking at adjacent abuse paths, Fetch Metadata and Resource Isolation Policy Guide shows how request headers can be used to reject cross-site traffic before it reaches sensitive handlers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service Security | State-changing web requests need anti-forgery checks at the request boundary. |
| V7 — Session Management | CSRF works because browsers send ambient session credentials automatically. | |
| V8 — Authorization | A forged request can still execute an authorized action if origin is not checked. | |
| Recommendation — Require request-origin and anti-forgery checks on state-changing endpoints. Bind session handling to defenses that prevent ambient credential abuse. Enforce server-side action checks before allowing state changes. | ||
Practitioner Guidance
What to verify: Confirm that every state-changing route, including “small” profile updates and preference changes, is protected by an application-level anti-forgery check. If a route changes server state but only relies on the login cookie, treat that as a design defect rather than a missing hardening step.
Decision rule: If the endpoint performs an action that should only happen through your own UI flow, require a token or equivalent origin proof even when the user is already authenticated. If the route is truly read-only, anti-forgery is usually unnecessary.
Common mistake: Teams often protect the most obvious form submissions and miss JSON endpoints, mobile-backend endpoints, and “convenience” actions such as toggles, invites, and preference updates. Those are frequent blind spots because they look operationally minor but still change state.
Practitioner takeaway: Session authentication proves the user is signed in; anti-forgery proves the request was intentionally generated by your application, and both checks are needed when the browser can carry ambient credentials.
Related resources from NHI Mgmt Group
- What breaks when state-changing actions are allowed through GET requests?
- Why do state-changing requests in Rust web apps create CSRF risk for authenticated users?
- What breaks when anti-CSRF validation is removed from a state-changing endpoint?
- Why do state-changing browser requests create CSRF exposure in session-based applications?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org