How should security teams prevent CSRF on state-changing endpoints in web applications?

Why This Matters for Security Teams

CSRF is a session-trust problem: the browser will happily attach ambient credentials to a request unless the application proves that the action was intentionally initiated by the user. That is why every state-changing endpoint needs a request-specific check, not just a login session. The risk is greatest where teams rely on cookies alone, especially when workflows include profile changes, payment actions, permission updates, or API-driven admin functions.

Security teams also need to remember that CSRF is rarely isolated. If an application has weak origin checks, permissive CORS, or XSS anywhere in the same trust boundary, the anti-CSRF design can be bypassed or rendered meaningless. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the broader point: identity, session handling, and application controls need to work together, not as separate afterthoughts.

In practice, many teams discover CSRF only after a real account action has already been triggered through an unintended browser request, rather than through intentional review of their state-changing endpoints.

How It Works in Practice

The most reliable pattern is the synchronizer token: the server issues a cryptographically unpredictable token tied to the user session, and the application requires that token on every state-changing request. Stateless variants can also work, such as encrypted tokens or double-submit tokens, but they must be implemented carefully so the token cannot be guessed, replayed, or accepted cross-site without validation.

For modern web applications, the practical control set is usually layered:

• Require tokens on every POST, PUT, PATCH, DELETE, and any GET request that changes state should be redesigned.
• Validate the token server side on every request, not just at form render time.
• Check the Origin header, and use Referer validation only where it is operationally appropriate.
• Set cookies with Secure, HttpOnly, and SameSite attributes where compatibility allows.
• Prefer framework-native CSRF middleware over custom code, because edge cases are easy to miss.

Browser security still matters. HTTPS protects token transport, while XSS can defeat CSRF defenses by reading or replaying tokens from the page context. That is why CSRF controls should be treated as one layer inside a broader web application security program, not as a substitute for output encoding, content security policy, and input handling. Current guidance suggests that same-site cookie settings reduce risk, but there is no universal standard for this yet because older browsers, third-party login flows, and embedded applications complicate deployment. The OWASP OWASP Top 10 remains a useful anchor for understanding how CSRF fits alongside broader application weaknesses. For teams looking at identity and credential lifecycle risk more broadly, NHIMG’s The State of Non-Human Identity Security shows how often weak control coverage and poor visibility create avoidable exposure across digital trust boundaries.

These controls tend to break down when teams mix browser-based sessions with cross-domain embeds or legacy workflows that depend on silent POSTs, because token validation and origin checks become inconsistent across user agents and integrations.

Common Variations and Edge Cases

Tighter CSRF protection often increases implementation overhead, requiring organisations to balance protection against compatibility, especially in older browsers and complex single sign-on environments.

Some applications do not fit the standard browser-session pattern. Public APIs authenticated with bearer tokens are less exposed to classic CSRF, while hybrid apps that use cookies for browser users and tokens for API clients can create confusing boundary cases. In those environments, teams should separate browser-facing endpoints from machine-to-machine endpoints and apply controls according to the credential model in use.

There are also practical exceptions. Read-only endpoints should not be used for state change, even if they are easier to call. Idempotent actions still need CSRF protection if they alter server state. For embedded apps, cross-site iframes, and payment redirects, teams often need to combine tokens with strict origin checks and explicit allowlists. Best practice is evolving here, and there is no universal standard for every framework or browser behavior. Where older integrations cannot support token validation cleanly, the safer path is to redesign the workflow rather than weaken the control.

For deeper discussion of how identity-related failures persist after exposure, NHIMG’s ASP.NET machine keys RCE attack is a useful reminder that control failure often comes from trust assumptions that survive long after the original design decision.

Related resources from NHI Mgmt Group

• How should security teams prevent XSS in modern web applications?
• How should teams implement RBAC in React applications without letting frontend checks become the security boundary?
• How should security teams implement Postgres RLS in multi-tenant applications without relying on it as the only control?
• How should security teams prioritize hidden identity risks in applications that bypass central identity controls?