Category: Attack Techniques
Cross-Site Request Forgery
Also known as: CSRF, XSRF, Sea Surf, One-Click Attack, Session Riding
Simply put
Cross-Site Request Forgery is an attack that tricks an authenticated user into unknowingly submitting a malicious request to a web application where they are already logged in. The attacker exploits the trust the application has in the user's browser, causing actions to be performed on the victim's behalf without their knowledge or consent. This typically results in unwanted state-changing operations such as fund transfers, email changes, or account modifications.
Formal definition
CSRF is a web security vulnerability in which an attacker induces an authenticated end user's browser to send a forged HTTP request, including the user's session credentials, to a target web application. Because the application cannot distinguish the forged request from a legitimate one based on session state alone, it executes the requested action under the victim's identity. The attack is effective when the target application relies solely on cookie-based authentication or other credentials automatically included by the browser, and does not implement origin-verification controls such as anti-CSRF tokens, the SameSite cookie attribute, or custom request headers. CSRF exploits the application's trust in the authenticated user rather than the user's trust in the application, making it distinct from cross-site scripting. Successful exploitation requires the victim to be authenticated and to interact with attacker-controlled content, typically via a crafted link or page, during an active session.
Why it matters
CSRF represents a fundamental class of web application vulnerability because it subverts the trust model that underlies authenticated sessions. Web applications typically grant elevated permissions to requests that arrive with valid session credentials. When an attacker can forge such requests, any state-changing operation available to the victim, including fund transfers, password changes, email updates, and administrative actions, may be executed without the victim's awareness. The attack requires no compromise of credentials and leaves minimal forensic evidence, since the malicious request is indistinguishable from a legitimate one at the session layer alone.
Who it's relevant to
Web Application Developers
Developers building any application that relies on cookie-based authentication must implement CSRF mitigations for all state-changing endpoints. This typically includes deploying synchronization tokens (anti-CSRF tokens), setting the SameSite attribute on session cookies, or validating custom request headers. Applications that accept only JSON via explicit content-type enforcement may reduce exposure for some attack paths, but developers should not rely on a single control in isolation.
Security Engineers and Penetration Testers
Security engineers assessing web applications are responsible for verifying that CSRF protections are present and correctly implemented on all state-changing operations, including those protected by multi-step workflows. Automated scanners may detect missing anti-CSRF tokens in static analysis or passive scanning, but confirming exploitability and testing for token-reuse or token-fixation weaknesses typically requires manual verification or active testing with runtime context.
Application Security Architects
Architects designing authentication and session management systems must account for CSRF when selecting credential transport mechanisms. Cookie-based session management introduces CSRF risk by default, while token-based approaches using Authorization headers are generally not vulnerable because browsers do not automatically attach such headers to cross-origin requests. Architectural decisions about cookie scope, SameSite policy, and API design directly affect the CSRF attack surface across an application.
End Users
Authenticated users of web applications are the proximate victims of CSRF attacks. The attack is transparent to the user, who may never be aware that a malicious action was performed on their behalf. Practical user-level mitigations are limited, though logging out of sensitive applications when not in use and exercising caution with untrusted links during active sessions may reduce exposure. The primary responsibility for prevention rests with the application, not the user.
Inside CSRF
Forged Request
An HTTP request crafted by an attacker and submitted on behalf of an authenticated victim, carrying the victim's session credentials without their knowledge or intent.
Session Credential Abuse
The mechanism by which CSRF exploits browser behavior that automatically attaches cookies or other ambient credentials to requests made to a target origin, regardless of which site initiated the request.
Attacker-Controlled Trigger
The delivery vehicle for the forged request, typically an HTML element such as an image tag, form, or script hosted on a malicious or compromised site that the victim visits while authenticated elsewhere.
CSRF Token
A secret, unpredictable value tied to a user session and embedded in forms or request headers, which the server validates to confirm that the request originated from the legitimate application interface rather than a third-party site.
SameSite Cookie Attribute
A browser-enforced cookie attribute that restricts when cookies are sent with cross-site requests, providing a defense-in-depth layer against CSRF when set to Strict or Lax modes.
State-Changing Request
The category of HTTP requests that CSRF typically targets, including POST, PUT, PATCH, and DELETE operations that modify server-side data or application state, as opposed to read-only GET requests.
Origin and Referer Header Validation
A server-side defense technique that inspects the Origin or Referer HTTP headers to verify that a request originates from the expected application domain, used as a supplementary control alongside token-based defenses.
Common questions
Answers to the questions practitioners most commonly ask about CSRF.
Does using HTTPS protect my application from CSRF attacks?
No. HTTPS encrypts data in transit and authenticates the server to the client, but it does not prevent a browser from automatically including cookies with cross-origin requests. A CSRF attack exploits the browser's cookie-handling behavior, which operates independently of whether the connection is encrypted. HTTPS and CSRF protection address different threat categories and both are typically required.
If my API only accepts JSON, am I protected from CSRF?
Not necessarily. While older browsers enforced strict content-type restrictions that made JSON-body CSRF more difficult, modern fetch APIs and certain server misconfigurations may allow cross-origin requests with JSON payloads in some cases. Relying solely on content-type as a CSRF defense is not considered a robust or standalone control. Explicit CSRF tokens or strict origin validation are more reliable mitigations.
Where should I store and validate the CSRF token in a traditional server-rendered application?
The token is typically generated server-side per session (or per request for higher-security contexts), stored in the session on the server, and embedded in HTML forms as a hidden input field. On form submission, the server compares the submitted token against the session-stored value. The token must not be transmitted in cookies, as that would replicate the vulnerability it is meant to prevent.
How does the SameSite cookie attribute help with CSRF, and what are its limitations?
Setting the SameSite attribute to 'Strict' or 'Lax' on session cookies instructs the browser to withhold those cookies on cross-site requests, which prevents CSRF in most cases for browsers that honor the attribute. The limitation is that SameSite enforcement depends on browser support and correct configuration. 'Lax' mode still permits cookies on top-level navigation GET requests, so state-changing GET endpoints remain at risk. SameSite is best used as a defense-in-depth measure alongside explicit token validation rather than as a sole control.
How should CSRF protection be implemented in single-page applications that use token-based authentication?
SPAs that store authentication tokens (such as JWTs) in JavaScript-accessible storage and transmit them via Authorization headers rather than cookies are generally not vulnerable to classic CSRF, because browsers do not automatically attach custom headers to cross-origin requests. However, if the SPA also uses cookie-based session mechanisms, CSRF protection must still be applied to those cookie-authenticated endpoints. The choice of authentication transport directly determines whether CSRF controls are required.
Is validating the Origin or Referer header a sufficient CSRF defense on its own?
Origin and Referer header validation can serve as a useful supplementary control and is recommended as part of a layered defense. However, relying on it alone has limitations: the Referer header may be suppressed by privacy settings or browser extensions, and certain proxy configurations may strip or alter these headers. Origin header validation is generally more reliable than Referer, but neither provides the same guarantee as a properly implemented synchronizer token pattern. These checks are typically recommended in addition to token-based controls rather than as replacements.
Common misconceptions
Using HTTPS protects an application against CSRF attacks.
HTTPS encrypts data in transit and authenticates the server to the client, but it does not prevent a browser from automatically including cookies in cross-site requests. CSRF exploits the browser's credential-forwarding behavior, which operates independently of the transport layer, so TLS alone provides no CSRF mitigation.
Requiring authentication or checking that a user is logged in is sufficient to prevent CSRF.
CSRF attacks succeed precisely because the victim is already authenticated. The forged request carries valid session credentials automatically supplied by the browser, so authentication checks confirm the user's identity but cannot distinguish a legitimate request from a forged one without an additional unpredictable token or same-site enforcement mechanism.
APIs that accept JSON instead of HTML form submissions are inherently immune to CSRF.
While some browser restrictions on cross-origin requests with non-simple content types provide partial protection in certain configurations, this is not a reliable or complete defense. Depending on the server's CORS configuration and the specific request structure, JSON-based endpoints may still be reachable from cross-origin contexts, and relying on content type alone without explicit CSRF controls is not considered sufficient mitigation.
Best practices
Implement server-side CSRF token validation for all state-changing requests, generating tokens that are cryptographically unpredictable, tied to the user session, and verified on every submission rather than only at login.
Set the SameSite attribute on session cookies to Strict or Lax as a defense-in-depth measure, recognizing that this provides meaningful protection in modern browsers but should not replace token-based validation given inconsistent support across older clients.
Validate the Origin or Referer header on the server for state-changing requests as a supplementary control, rejecting requests where the header is present but does not match the expected application origin, while accounting for cases where the header may be absent.
Avoid using GET requests or other safe HTTP methods to perform state-changing operations, ensuring that actions with side effects require methods that are not automatically triggered by passive page elements such as image tags or link prefetching.
Review CORS policy configurations to ensure that credentialed cross-origin requests are permitted only from explicitly trusted origins, as overly permissive CORS settings can undermine CSRF defenses by allowing attacker-controlled origins to make authenticated requests.
Include CSRF protection requirements in secure development standards and code review checklists, and use static analysis tooling to flag endpoints that accept state-changing requests without apparent token validation, while confirming findings with dynamic testing since static analysis cannot fully verify runtime enforcement.