Cross-Site Request Forgery (CSRF) Defense

Cross-site request forgery (CSRF) is a class of web application vulnerability in which an attacker tricks an authenticated user's browser into submitting unauthorized requests to a target application. The attack exploits the browser's automatic inclusion of session credentials — cookies, HTTP authentication headers — in outbound requests, regardless of the request's origin. CSRF is catalogued by OWASP as a persistent risk to state-changing endpoints and remains a concern across application security fundamentals and compliance-driven development practices.

Definition and scope

CSRF is defined by OWASP as an attack that forces an authenticated user to execute unwanted actions on a web application in which they are currently authenticated. The attack does not require the adversary to compromise any account credential directly — it hijacks the trust a server places in the user's browser.

Scope boundaries matter here. CSRF is a server-trust exploitation, not a client-side code injection. It differs from cross-site scripting (XSS) in a fundamental way: XSS exploits the user's trust in a site by injecting malicious scripts into page content, whereas CSRF exploits the server's trust in the user's browser by forging authenticated requests from an external origin. The two can be chained — XSS can be used to bypass CSRF defenses — but they are architecturally distinct vulnerability classes.

NIST SP 800-63B, which governs digital identity and authenticator management, underscores that session binding mechanisms must account for cross-origin request risks. PCI DSS Requirement 6.2.4 (v4.0) (PCI Security Standards Council) mandates that software development practices address all OWASP Top 10 vulnerabilities — CSRF is explicitly included in scope for payment application reviews under older PCI PA-DSS and in the current software security framework.

How it works

A CSRF attack follows a discrete sequence that depends on three conditions: the victim has an active authenticated session on the target site; the browser automatically attaches session credentials to requests; and the target application does not verify request origin or intent.

Attack sequence:

The victim authenticates to a target application (e.g., a banking portal), establishing a session cookie stored by the browser.
Without logging out, the victim visits a malicious page or clicks an attacker-controlled link.
The malicious page contains a hidden HTML form, an <img> tag, or a JavaScript fetch call that targets the victim's application — for example, a fund transfer endpoint.
The browser, following standard HTTP behavior, attaches the session cookie to the outgoing request automatically.
The target server receives the request as if it were legitimate, validates the session, and executes the state-changing action.

The attack exploits no browser vulnerability. It relies entirely on the HTTP specification's design, which allows cross-origin requests to carry ambient credentials unless the application enforces preventive controls.

SameSite cookie attribute is a modern browser-level mitigation. Setting SameSite=Strict or SameSite=Lax on session cookies instructs browsers to withhold cookies on cross-site requests. The Strict setting blocks the cookie on all cross-origin navigations; Lax permits cookies on top-level GET navigations but blocks POST requests from third-party contexts. Neither provides complete protection in isolation, since legacy browsers and misconfigured cookie scopes can weaken enforcement. Session management security covers cookie attribute configuration in broader context.

Common scenarios

CSRF vulnerabilities surface wherever authenticated, state-changing actions are accessible through predictable HTTP endpoints that do not validate request origin.

High-frequency attack surfaces include:

Financial transactions — fund transfers, bill payments, and account settings endpoints that accept POST requests with predictable parameters.
Account modification — email address changes, password resets initiated through authenticated sessions, and two-factor authentication enrollment endpoints.
Administrative actions — user privilege escalation, content publishing, or configuration changes in content management and enterprise admin panels.
API endpoints without token validation — REST APIs that rely solely on cookie-based sessions and do not require an explicit CSRF token in request headers or body. API security best practices addresses this as a distinct attack surface.
Single-page applications (SPAs) — SPAs using cookie-based authentication rather than bearer tokens in Authorization headers are susceptible; token-based flows using Authorization: Bearer headers are inherently resistant because browsers do not automatically send custom headers cross-origin.

CSRF severity scales with the privilege level of the targeted action. An attack forging a low-privilege comment submission carries minimal business impact. The same mechanism targeting a privileged administrative endpoint — disabling security controls, exfiltrating configuration data — is categorized as high or critical severity by CVSS v3.1 scoring metrics (FIRST.org).

Decision boundaries

Selecting and implementing CSRF defenses requires applying controls appropriate to the application's authentication architecture, framework capabilities, and risk profile.

Primary defense controls, in order of reliability:

Synchronizer token pattern (anti-CSRF token) — The server generates a unique, unpredictable token per session or per request, embeds it in forms and state-changing requests, and validates its presence and correctness on receipt. This is the defense recommended by OWASP's CSRF Prevention Cheat Sheet.
Double-submit cookie pattern — A CSRF token is both set as a cookie and submitted as a request parameter; the server validates that both match. Suitable when server-side session state is not available, but weaker if subdomains are not properly isolated.
Custom request headers (for AJAX/SPA) — Requiring a custom header such as X-Requested-With or X-CSRF-Token exploits CORS preflight restrictions; browsers block cross-origin requests with custom headers unless the server explicitly permits them via CORS policy.
SameSite cookie attribute — Applied as a defense-in-depth layer, not as a standalone control; browser support is broadly available as of Chrome 80 (2020) but legacy environments may not enforce it.
Origin and Referer header validation — Checking the Origin or Referer header against an allowlist of trusted origins provides secondary validation. Both headers can be absent in privacy-configured browsers, so this technique supplements but does not replace token-based defenses.

Control selection matrix:

Application Type	Recommended Primary Control	Secondary Layer
Server-rendered HTML forms	Synchronizer token (per-form)	SameSite=Lax cookie
REST API (cookie auth)	Custom header + CORS policy	Double-submit cookie
SPA with bearer token	Bearer token in Authorization header (inherently resistant)	SameSite=Strict cookie
Legacy app, no framework	Double-submit cookie	Origin header validation

Web application firewall configurations can detect and block CSRF patterns at the network layer, but WAF rules are not a substitute for application-level token controls — they provide supplementary detection for known attack signatures only.

Threat modeling for applications should include CSRF as an explicit abuse case during the design phase, particularly for authenticated state-changing operations. OWASP ASVS (Application Security Verification Standard) Level 2 requires verification that anti-CSRF controls are implemented for all state-changing requests (OWASP ASVS 4.0, §4.2.2).

Dynamic application security testing tools can automate CSRF detection by identifying state-changing requests that lack token validation, making CSRF testing an efficient component of automated security pipelines.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator