Cross Site Request ForgeryEdit
Cross Site Request Forgery (CSRF) is a web security vulnerability that exploits the trust a site has in a user's browser. In practical terms, it happens when an attacker tricks a user who is authenticated to one site into submitting a request to that site that performs an action the user did not intend. Because browsers automatically include credentials such as cookies with requests, the target site can be convinced that the forged request is legitimate. The result can be unintended money movements, changes to account settings, or other state-changing actions.
CSRF is not about breaking a login or stealing passwords by itself; it is about abusing a user's active session to perform actions on their behalf. The burden of defense often falls on the site or service being targeted, with mitigations designed to ensure requests actually originate from the legitimate user and not from a hostile third party. For developers and policymakers alike, CSRF is a reminder that security is not simply about keeping attackers out at the door but about designing systems that reason correctly about the context in which requests arrive. See SameSite and CSRF token for common defenses, and consider how modern browser and API practices shape what is feasible to defend.
Mechanisms and exploitation
How it happens. A user who is logged into a trusted site contains an active session, typically tracked via a session cookie. If the user visits a malicious page, that page can cause the user’s browser to submit a request to the trusted site—often a state-changing action such as transferring funds or changing an email address. The trusted site, seeing the user’s session cookie, processes the request as if the user themselves initiated it.
Why cookies matter. CSRF relies on the browser automatically sending credentials with cross-origin requests. If a user is authenticated, the browser will attach cookies to requests regardless of where the request originated. This is why many CSRF defenses focus on ensuring the request cannot be accepted as legitimate if it comes from an untrusted site.
Typical targets. Accounts with financial or administrative permissions, or any endpoint that changes state without re-authentication, are common targets. Banks, social networks, and e-commerce platforms have historically been susceptible when proper mitigations were not in place. See Web security and Session management for broader context.
Relationship to other attacks. Cross Site Scripting (XSS) and other injection flaws can enable an attacker to read or manipulate a page’s content and, in some cases, aid CSRF by enabling a more powerful foothold. Defenses against CSRF are often part of a larger secure-coding approach that includes input validation, output encoding, and defensive headers such as Content Security Policy Content Security Policy.
Defenses and mitigations
SameSite cookies. The SameSite attribute on cookies restricts whether cookies are included with cross-origin requests. Setting cookies with SameSite=Strict or SameSite=Lax can dramatically reduce CSRF risk by ensuring that cross-site requests do not automatically carry the user’s session. See SameSite.
Anti-CSRF tokens. Servers generate a unique, unpredictable token per user session and require that the token be included in sensitive requests, usually as a hidden form field or a custom header. The server validates the token before performing the requested action. See CSRF token.
Double submit cookies. A token is set as a cookie and also sent in a request parameter or header; the server verifies that both values match. This reduces reliance on cookie-only trust.
Re-authentication for sensitive actions. Requiring the user to re-enter a password or complete MFA for particular operations adds a second line of defense beyond a stolen or forged request. See Two-factor authentication.
Origin and Referer checks. Verifying the Origin or Referer header can help determine whether a request came from a legitimate page, though these headers are not guaranteed to be present or trustworthy in all environments. See HTTP Referer header and Origin header.
API and token-based approaches. For services that use cookies for authentication, CSRF remains a concern. When possible, using tokens sent in an Authorization header (and not cookies) for API requests reduces the risk of cross-origin forging. See OAuth 2.0 and REST API practices.
Defense-in-depth. CSRF defenses are most effective when combined with protections against XSS, proper input validation, and robust session management. A strong Content Security Policy can limit the ability of attackers to inject malicious scripts that might assist with CSRF. See Cross-Site Scripting and Content Security Policy.
Practical considerations and debates
Balancing security with usability and cost. Implementing CSRF defenses, especially in large or legacy systems, can introduce development overhead and potential breakages in legitimate workflows. The most durable approach favors layered security: cookies configured with SameSite, token-based protections for critical actions, re-authentication for high-risk operations, and careful API design. This aligns with a risk-management mindset common in many engineering organizations.
Impact on smaller platforms and innovation. While strong CSRF protections protect users, overly aggressive or poorly implemented controls can hamper legitimate integrations with third-party services, single sign-on ecosystems, or cross-domain workflows. Proponents of pragmatic security argue for standards-based, interoperable solutions that minimize friction while preserving safety. See Web security and OAuth 2.0 for broader discussions of interoperability and risk.
Browser standards and platform responsibility. Much of CSRF defense depends on browser behavior (cookies, headers) and platform conventions. When browsers introduce stricter defaults (for example, enforcing SameSite by default or deprecating certain cross-origin practices), the attack surface shifts and developers must adapt. This has driven ongoing debates about the right balance between security, privacy, and developer ergonomics. See Web browsers and SameSite.
Regulation, standards, and compliance. As web services handle more sensitive actions, there is increasing pressure to codify security expectations through standards and, in some cases, regulation. Critics worry that heavy-handed mandates can stifle innovation or impose costs on smaller players, while supporters argue that baseline protections are essential to protect consumers and financial systems. See Security standards and Regulation.
The root cause and ongoing work. CSRF highlights that many attacks exploit the trust model of the web—where credentials travel with requests. A comprehensive response combines secure coding practices, user education, improved API design, and browser-level protections. Emphasis on preventing XSS, secure session handling, and proper authorization boundaries remains central. See XSS and Session management.