Cross-Site Request Forgery (CSRF) Defense

Cross-Site Request Forgery (CSRF) is a class of web application attack in which an authenticated user's browser is manipulated into submitting unauthorized requests to a trusted application without the user's knowledge. This page describes the attack mechanism, the principal vulnerability scenarios across web application contexts, the technical controls used to defend against it, and the decision criteria practitioners use when selecting and implementing those controls. CSRF defenses appear in authoritative frameworks including OWASP, NIST SP 800-53, and PCI DSS, making this a compliance-relevant subject as well as a technical one.

Definition and scope

CSRF exploits the trust a web application places in authenticated session credentials — specifically, cookies and HTTP authentication headers that browsers attach automatically to every qualifying request. An attacker does not need access to those credentials directly; the browser's own behavior becomes the attack vector. The attacker crafts a request that the victim's browser sends, using the victim's active session, to perform an action the victim did not initiate.

CSRF is formally classified in the OWASP Top 10 historical list and is covered in depth by the OWASP Web Security Testing Guide (WSTG), section WSTG-SESS-05. NIST SP 800-53 Rev. 5 addresses CSRF indirectly under Control SI-10 (Information Input Validation) and SC-8 (Transmission Confidentiality and Integrity) for federal and FedRAMP-authorized systems. PCI DSS Requirement 6.2.4 requires that all web-facing applications protect against injection and request forgery attack classes, applying to any entity processing cardholder data.

The scope of CSRF risk is bounded by two preconditions: the application must rely on automatic credential transmission (cookies, HTTP Basic/Digest authentication), and the targeted action must have state-changing effects. Read-only endpoints that do not modify server-side state present no meaningful CSRF surface. This distinction — state-changing versus read-only — defines the practical scope boundary for CSRF defense implementation and is addressed further in the Application Security Providers reference covering appsec control categories.

How it works

A CSRF attack follows a discrete sequence of stages:

1. Session establishment. The victim authenticates to a legitimate application. The application issues a session cookie that the browser stores and attaches to all subsequent same-domain requests.
2. Malicious payload delivery. The attacker delivers a crafted page, email, or embedded resource to the victim. This content contains a request targeting the legitimate application — for example, an <img> tag, auto-submitting HTML form, or JavaScript fetch() call.
3. Involuntary request transmission. The victim's browser, following standard HTTP behavior, attaches the session cookie and dispatches the request to the application server.
4. Server-side execution. The application, which has no mechanism to distinguish the forged request from a legitimate one, processes the action under the victim's authenticated identity.
5. Impact realization. The attacker achieves the intended effect — funds transfer, email change, privilege escalation, data deletion — without requiring any credential access.

The attack exploits no vulnerability in the browser itself. It exploits the absence of origin verification on the server. The server receives a syntactically valid, credentialed request and cannot distinguish its origin without an explicit anti-forgery mechanism.

Two structural variants exist and carry different severity profiles:

• Classic CSRF (form-based): Relies on HTML form submission or image-tag GET requests. Blocked by same-site cookie policies and CSRF tokens. Historically the dominant variant.
• Login CSRF: Targets the authentication flow itself, forging the login action to bind the victim's session to an attacker-controlled account. Distinct from post-authentication CSRF in that the victim need not be authenticated at attack time. OWASP WSTG-SESS-09 addresses this variant specifically.

Common scenarios

CSRF vulnerabilities surface most frequently in four application contexts:

Financial transaction endpoints. Wire transfers, payment method changes, and account balance modifications triggered by POST requests with insufficient origin validation represent the highest-impact scenario. Banking applications subject to FFIEC guidance and payment processors under PCI DSS Requirement 6.2.4 are explicitly required to address this surface.

Account management functions. Email address, password, and multi-factor authentication changes are frequent targets. A successful CSRF attack against an email-change endpoint produces account takeover without credential theft, which evades most authentication monitoring controls.

Administrative interfaces. Content management systems and application administration panels that use cookie-based sessions are susceptible when deployed without CSRF tokens. A single successful forgery against an administrator session can result in system-wide configuration changes.

API endpoints accepting application/x-www-form-urlencoded or multipart/form-data. REST APIs that accept these content types without token validation share the same CSRF surface as traditional form-based applications. APIs that exclusively accept application/json with strict content-type enforcement have a reduced but not eliminated surface, depending on browser CORS preflight behavior. This intersection between CSRF and API authentication design is part of the broader controls landscape described in the reference.

Decision boundaries

Practitioners selecting CSRF defenses apply a tiered decision framework based on application architecture:

Synchronizer Token Pattern (STP): The canonical defense for traditional server-rendered applications. A unique, cryptographically random token is embedded in each state-changing form and validated server-side on submission. OWASP recommends a minimum of 128 bits of entropy for CSRF tokens (OWASP CSRF Prevention Cheat Sheet). STP is appropriate for monolithic applications with server-managed session state.

Double Submit Cookie: The token is sent in both a cookie and a request parameter; the server verifies they match. This is stateless on the server side and suitable for distributed or horizontally scaled architectures. It is weaker than STP if the attacker can influence cookie values through subdomain compromise.

SameSite Cookie Attribute: Available in all major browsers. Setting cookies to SameSite=Strict or SameSite=Lax prevents them from being sent with cross-origin requests. Strict blocks all cross-origin requests; Lax permits top-level navigation GET requests but blocks cross-origin POST. SameSite=Lax is the browser default in Chrome as of version 80 (released February 2020). This attribute functions as a first-layer control, not a complete replacement for token-based validation in high-assurance applications.

Custom Request Headers: For AJAX-based and SPA architectures, requiring a custom header (e.g., X-Requested-With) leverages CORS preflight enforcement to block cross-origin forgery. This defense depends entirely on proper CORS policy configuration and breaks down if CORS is misconfigured to allow arbitrary origins.

Verification via Origin and Referer Headers: Server-side validation of the Origin or Referer HTTP header against an allowlist of trusted origins provides defense-in-depth. Treated as a supplementary control by OWASP, not a standalone defense, because header suppression and proxy stripping can create false negatives.

The decision between STP and SameSite cookie enforcement is not an either/or choice in regulated environments. Applications subject to NIST SP 800-53 or PCI DSS 6.2.4 typically implement both controls in combination. The How to Use This Application Security Resource reference page covers how control categories like CSRF defense map to practitioner qualification and service selection within this network.