Cross-Site Request Forgery (CSRF) Protection

How CSRF Protection Works

CSRF protection is not a single control, but a set of checks that make state-changing requests prove they were initiated by the intended application flow. The practical idea is simple: if a browser will automatically send a user’s cookies, the server must add an independent signal that an action came from the right page, not from a third-party site.

In most applications that signal is a per-request token. The server issues a value tied to the user session and expects it back on forms or API calls that change state. When the token is missing, wrong, or reused in an unexpected context, the request should be rejected even if the user is otherwise authenticated.

Why CSRF Is Dangerous

CSRF is dangerous because it exploits trust in the browser, not weakness in the password. An attacker does not need to steal a session token if they can cause the victim’s browser to submit a legitimate-looking request while the session is still active. That can trigger account changes, purchases, profile updates, permission changes, or other state transitions the user never intended.

Defences are strongest when they combine more than one signal. SameSite cookie settings reduce when cookies are attached, origin or referer validation helps confirm where the request came from, and request tokens protect the action itself. Relying on only one of these mechanisms can leave gaps when browser behaviour, legacy clients, or framework defaults are not what the team expects.

Common Deployment Patterns and Failure Modes

CSRF protection is usually built into frameworks, but the defaults vary and can be misapplied. A common failure mode is exempting entire routes for convenience, then forgetting that a login, password reset, settings update, or privileged action still changes state and still needs protection.

Another common problem is inconsistent coverage. Teams often protect traditional form posts but miss JSON endpoints, logout flows, GraphQL mutations, webhook-like admin actions, or API handlers called from browser sessions. CSRF protection only works when the same policy is applied to every state-changing path that accepts browser credentials.

• Token checks must be enforced on the server, not only in client code.
• SameSite cookies help, but they are a browser control, not a full substitute for server-side validation.
• Origin and referer checks are useful backstops, but they should be treated as validation signals, not as the only defence.

What Good CSRF Defences Look Like in Practice

Good CSRF defence starts with identifying every authenticated action that changes server state, then applying a consistent validation pattern across those actions. That means using framework-supported anti-forgery features where possible, checking that protected routes actually reject cross-site submissions, and verifying that exemptions are intentional rather than accidental.

Because modern browser security controls keep evolving, teams should also test their assumptions after framework upgrades, proxy changes, or cookie policy changes. A CSRF defence that works in one browser or deployment model may weaken when cookie scope, header handling, or session architecture changes.

For implementation detail and rollout patterns, see the CSRF Prevention Guide and the Fetch Metadata and Resource Isolation Policy Guide. For broader attack context, the Web Application Attacks Guide shows how CSRF fits alongside other browser-based attack classes.

Risk and Threat Considerations

CSRF matters most where a browser session carries real authority, because the attack abuses ambient authentication. If an application allows high-value actions through cookie-authenticated requests without a second check, a hostile site can induce those actions without ever learning the user’s password or session value.

Failure mechanism: The attacker relies on the browser automatically attaching session cookies to a forged cross-site request, then targets any endpoint that accepts state changes without a token or equivalent origin check.

Impact: The result can be unauthorized account changes, transaction abuse, privilege changes, or session-affecting actions that appear to come from the legitimate user, making detection and user attribution harder.

Related resources from NHI Mgmt Group

• Cross-Site Request Forgery
• Request Forgery Protection
• Request Forgery
• Forgery