Prevent cross-site request forgery by making every state-changing request carry a value the attacker cannot predict or reuse from another site. Verify the token server side, bind it to the user session, and reject requests that rely only on cookies. Also use same-site cookie settings where appropriate and require extra checks for sensitive actions.
How CSRF defenses actually work
Cross-site request forgery prevention depends on proving that the request was created by the site the user intended to use, not merely that the user has an active browser session. A good defense gives the server a request attribute an attacker cannot read or reuse from another origin, then checks that attribute before performing the action.
The token is the core control, but it works best when the application also treats cookies as an ambient credential that should not be enough on its own. That is why state-changing actions need server-side verification, session binding, and a refusal to accept requests that look legitimate only because the browser attached authentication cookies.
For broader context on the attack patterns behind this class of weakness, see the Web Application Attacks Guide, which covers CSRF alongside related request-tampering techniques.
Which controls matter most in practice?
Start with the controls that prevent a forged browser request from reaching a sensitive handler. That means per-request or per-session anti-CSRF tokens, server-side token validation, and a clear separation between safe read-only requests and state-changing operations. If the request changes data, transfers value, alters access, or changes credentials, it deserves a stronger check than a simple cookie-based session.
Same-site cookie settings help reduce opportunistic cross-site submission, but they are a supporting control rather than a complete answer. They are most useful when paired with token validation and request-origin checks, because different browsers, legacy endpoints, and embedded flows can produce edge cases that do not disappear just by setting a cookie attribute.
For teams that want a practical application-security baseline, the OWASP Cheat Sheet Series is a useful companion for implementation details across authentication, session handling, and request validation.
Where CSRF defenses fail most often
Weak CSRF defenses usually fail because the application assumes browser state alone proves intent. That assumption breaks when a malicious site can induce a victim’s browser to submit a request, especially if the application relies on cookies without a separate anti-forgery check. It also fails when token validation is inconsistent across routes, methods, or older endpoints that never received the same protection.
Sensitive actions deserve extra scrutiny because their impact is outsized even when the request looks routine. Password changes, privilege changes, email updates, payment actions, API key creation, and account-linking flows should require stronger confirmation, not just a valid session. For related anti-patterns in other web abuse paths, the Cross-Site Scripting (XSS) Prevention Guide is a useful reference for understanding how client-side compromise can undermine request trust boundaries.
Risk and Threat Considerations
CSRF is dangerous because it turns a logged-in browser into an unwitting actor. If the application accepts state-changing requests without a verifiable anti-forgery check, an attacker can trigger actions the user never intended, including account changes, transactions, or privilege modifications.
Failure mechanism: The application trusts browser-attached cookies or session state as proof of user intent, so a cross-site request can reach a sensitive endpoint with valid authentication but no genuine authorization signal.
Impact: The result can be unauthorized state change, account manipulation, fraudulent action, or a wider compromise chain if the forged request alters recovery options, access rights, or trusted contact details.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | CSRF defenses often depend on browser session and redirect-flow protections. |
| V7 — Session Management | CSRF prevention relies on binding requests to a valid user session safely. | |
| V8 — Authorization | CSRF can trigger unauthorized state changes unless sensitive actions are rechecked. | |
| Recommendation — Validate anti-forgery checks in OAuth and OIDC flows before accepting state changes. Bind state-changing requests to robust session handling and reject cookie-only trust. Revalidate authorization on sensitive actions before processing a state change. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Anti-CSRF tokens and session-bound secrets need lifecycle management and protection. |
| AC-6 — Least Privilege | CSRF impact is reduced when sensitive actions are constrained by minimal privilege. | |
| Recommendation — Protect and rotate request tokens and related authenticators as controlled secrets. Limit who can perform high-impact actions to reduce forged-request blast radius. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | CSRF token generation and protection benefit from strong cryptographic handling. |
| Recommendation — Use strong token generation and protection practices for anti-forgery values. | ||
Practitioner Guidance
What to verify: Confirm that every state-changing endpoint rejects requests without a server-validated anti-CSRF value, and that the validation logic is enforced uniformly across primary app routes, legacy handlers, and API-adjacent endpoints.
Common mistake: Do not treat SameSite cookies as a substitute for token validation. They reduce attack surface, but they do not reliably protect every browser flow, embedded context, or edge-case request path.
Decision rule: If the action can alter account state, access, credentials, or financial outcome, require explicit anti-forgery validation and an additional step-up check where the blast radius is high.
Practitioner takeaway: CSRF prevention is strongest when the server can prove request intent independently of the browser session, because authentication without intent is exactly what this attack exploits.
Related resources from NHI Mgmt Group
- Cross-Site Request Forgery Prevention
- Why do unauthenticated local AI agents create a bigger risk than a normal cross-site request forgery issue?
- What is the difference between cross-site scripting and cross-site request forgery in JavaScript applications?
- What happens when cross-site request forgery is present in a system that already has weak input handling?
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 October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org