CSRF & Mitigations — Explain CSRF conceptually and mitigations (tokens/same-site) (conceptual)

Historical Context & Motivation

Web applications emerged in the mid-1990s as thin clients that relied on the stateless HTTP protocol, which by design attaches no persistent identity to a request. To bridge this gap, cookies were introduced by Netscape in 1994, allowing servers to associate state with a browser session. This convenience, however, created a fundamental assumption: any request arriving with valid cookies must have been intentionally issued by the authenticated user. Attackers quickly realized they could abuse this assumption by tricking a victim's browser into sending requests the victim never intended to make. The class of attacks that exploits this trust became known as Cross-Site Request Forgery, or CSRF (sometimes pronounced "sea-surf"). Understanding CSRF requires recognizing that the browser, not the user, is the entity that attaches credentials to outgoing HTTP requests — and the browser cannot distinguish a legitimate click from a forged one embedded on a malicious page.

The central question CSRF addresses is deceptively simple: how can a server verify that a state-changing request genuinely reflects the user's intent rather than an attacker's manipulation? This question has driven decades of research into token-based defenses, origin-checking heuristics, and browser-level protections that continue to evolve today.

Core Principles & Definitions

To understand CSRF deeply, several foundational concepts must be established. The attack and its mitigations revolve around the interplay between the browser's credential-management policies, the same-origin policy, and the distinction between reading data and triggering side effects. CSRF is categorized as a confused deputy attack — the browser (the deputy) is tricked into using its authority (the user's cookies) on behalf of a malicious principal (the attacker's page).

Anatomy of a CSRF Attack

The following diagram illustrates the sequence of events in a typical CSRF attack. The victim is authenticated to a legitimate banking application and, in a separate browser tab, visits a malicious website controlled by the attacker. The malicious page contains a hidden form or image tag that causes the browser to issue a forged request to the bank, complete with the victim's session cookie.

Notice that the attacker never needs to steal the victim's cookie. The attack works precisely because the attacker does not need to read the server's response — the same-origin policy blocks that. CSRF only requires that the browser sends the request with attached credentials, which the browser does automatically. This is the crucial distinction between CSRF and cross-site scripting (XSS): XSS steals data by reading it, while CSRF takes actions by writing to the server without ever seeing the response.

How CSRF Attacks Are Delivered

Attack Vectors

CSRF attacks can be delivered through several mechanisms, each exploiting the browser's willingness to issue cross-origin requests. The simplest vector is an image tag: an attacker embeds <img src="https://bank.com/transfer?to=attacker&amount=5000"> on their page, which causes the browser to issue a GET request to the bank's endpoint. If the bank processes state-changing operations on GET (a violation of HTTP semantics), the transfer executes silently. More sophisticated attacks use hidden forms with JavaScript auto-submission. The attacker crafts a <form> element with method="POST" and action="https://bank.com/transfer", populates hidden fields with the desired parameters, and calls form.submit() via JavaScript the moment the page loads.

Why the Same-Origin Policy Doesn't Help

Students often assume the same-origin policy prevents CSRF, but this is a common misconception. The SOP governs what a script on one origin can read from another origin, not what it can send. Cross-origin form submissions, image loads, script includes, and certain fetch() requests with simple content types are all permitted by browsers without CORS preflight checks. The attacker does not need to read the bank's response — they only need the server to process the request. The SOP thus provides confidentiality (the attacker cannot read the response) but not integrity (the attacker can still trigger side effects).

Formal Characterization of the Vulnerability

A CSRF vulnerability exists when three conditions are simultaneously met. First, the application performs a state-changing action that an attacker wants to trigger (e.g., transfer funds, change email). Second, the application relies solely on ambient credentials (cookies or HTTP authentication) to authorize the request, with no additional unpredictable parameter. Third, the parameters of the request are fully predictable — the attacker can construct the exact request body or query string without knowing any secret value unique to the user's session.

• Condition 1: A relevant state-changing action exists (e.g., POST /changePassword)
• Condition 2: Authorization relies only on cookies — no additional secret token is required
• Condition 3: All request parameters are predictable by the attacker

CSRF Mitigation Strategies

Mitigating CSRF involves breaking at least one of the three conditions identified in the previous section. The most widely deployed defenses fall into two categories: token-based defenses that make request parameters unpredictable, and browser-level defenses that restrict when cookies are attached to cross-site requests. A robust application typically layers both approaches as defense in depth.

Token-Based Defenses

The Synchronizer Token Pattern is the most established defense. When a user requests a form, the server generates a cryptographically random token, stores it in the user's session, and embeds it as a hidden field. When the form is submitted, the server compares the submitted token against the stored value. Because the attacker cannot read cross-origin responses, they cannot extract the token from the form's HTML. A variation called the Double-Submit Cookie pattern avoids server-side session storage: the server sets a random value in a cookie and also requires the same value in a request header or body parameter. Since an attacker can cause the browser to send cookies but cannot read or set cookies for another domain (absent other vulnerabilities), they cannot replicate the value in the request body.

SameSite Cookie Attribute

The SameSite cookie attribute instructs the browser to restrict when a cookie is sent along with cross-site requests. It accepts three values: Strict, Lax, and None. With Strict, the browser never sends the cookie on any cross-site request, including top-level navigations — meaning that if a user clicks a link on evil.com to bank.com, they arrive unauthenticated. With Lax, cookies are sent on top-level GET navigations (so link clicks work) but withheld from cross-site POST requests and subresource loads (images, iframes). Since most CSRF attacks require POST, Lax provides strong default protection. None disables the restriction entirely and requires the Secure flag, sending the cookie on all requests as in the pre-SameSite era.

Origin and Referer Header Checking

An alternative or supplementary defense is to inspect the Origin or Referer HTTP headers on incoming requests. A legitimate request to bank.com should carry Origin: https://bank.com; a forged request from evil.com carries Origin: https://evil.com. While conceptually simple, this approach has reliability concerns: some browsers, proxies, or privacy extensions may strip these headers, and misconfigured servers that accept requests without an Origin header create exploitable gaps. It is therefore typically used as a defense-in-depth measure rather than a sole mitigation.

Worked Example: Identifying and Mitigating a CSRF Vulnerability

Consider a social media application where authenticated users can change their email address by submitting a POST request to /account/email with the parameter new_email. The application authenticates users via a session cookie named sid and does not include any CSRF token. We will walk through identifying the vulnerability, crafting a proof-of-concept exploit, and implementing a mitigation.

Comparing CSRF Mitigation Approaches

No single CSRF mitigation is perfect for every scenario. Token-based approaches require careful implementation on every state-changing endpoint, while browser-level defenses depend on client adoption and can break legitimate cross-site workflows. The table below compares the major approaches across several dimensions that practitioners must weigh when designing a defense strategy.

Connection to Advanced Web Security

CSRF does not exist in isolation — it interacts with and is sometimes amplified by other web vulnerabilities. A Cross-Site Scripting (XSS) vulnerability on the target site completely defeats token-based CSRF defenses because the attacker's injected script runs in the same origin and can read the CSRF token from the DOM. This is why OWASP ranks XSS and CSRF as complementary threats: eliminating CSRF without also preventing XSS leaves the application vulnerable, since XSS provides a bypass for most CSRF mitigations. Advanced defensive architectures move toward capability-based authorization, where each request carries an unforgeable bearer token (such as a JWT in an Authorization header) rather than relying on ambient cookies. This fundamentally eliminates CSRF because the attacker's page cannot programmatically access or attach the bearer token from another origin's JavaScript context.

Looking ahead, proposals like the Fetch Metadata request headers (Sec-Fetch-Site, Sec-Fetch-Mode) give servers fine-grained visibility into the context of each request, enabling resource isolation policies that reject cross-site requests at the application edge. Combined with the ongoing evolution of the SameSite attribute and emerging standards like CHIPS (Cookies Having Independent Partitioned State), the web platform is steadily moving toward a model where cross-site credential leakage becomes structurally impossible rather than merely mitigated.

Practice Problems

Summary & Key Concepts