Cross-site request forgery, commonly abbreviated CSRF, remains a persistent web application vulnerability, despite being a well-documented, long-understood attack technique. Understanding why CSRF continues succeeding against real applications helps explain why this vulnerability class still deserves serious security attention in 2026.
How CSRF Attacks Work
CSRF attacks exploit the fact that browsers automatically include a user’s existing authentication cookies with requests to a site. That means an attacker can trick a victim’s browser into submitting a malicious request to a legitimate site the victim is currently authenticated to. The victim’s own browser automatically attaches valid authentication credentials the attacker never needed to obtain directly. A classic example: a victim logged into their bank visits an unrelated malicious page containing a hidden form that auto-submits a funds transfer request to the bank’s own transfer endpoint. The browser happily attaches the victim’s session cookie, and the bank’s server has no way to tell the request did not originate from the bank’s own transfer page.
Why This Attack Technique Continues Working Today
CSRF continues working because it exploits a fundamental characteristic of how browser cookie-based authentication works by design – not a specific, isolated software bug that can simply be patched once. Applications need deliberate CSRF-specific protection built in. General security hygiene alone will not automatically address this distinct vulnerability category.
The Role of Anti-CSRF Tokens in Prevention
Effective CSRF prevention uses anti-CSRF tokens – unique, unpredictable values included in legitimate forms and verified server-side on submission. These tokens ensure a request genuinely originated from the legitimate application itself, and not from a forged request that tricked a victim’s browser into submitting without their informed consent. The synchronizer token pattern – where the server generates a token tied to the user’s session and rejects any state-changing request missing a matching token – remains the most reliable implementation, even though it requires threading the token through every form and AJAX call.
Why SameSite Cookie Attributes Provide an Additional Defense Layer
Modern browsers support SameSite cookie attributes that can prevent cookies from being automatically included in cross-site requests. Setting SameSite=Strict or SameSite=Lax provides a meaningful additional defense layer against CSRF beyond anti-CSRF tokens alone, and most major browsers now default new cookies to SameSite=Lax if the attribute is not explicitly set. That default has quietly closed off a fair amount of CSRF exposure sitewide over the past few years. Applications should still implement anti-CSRF tokens as a second layer, though, instead of relying purely on cookie attributes. Older clients, some mobile webviews, and misconfigured proxies do not always honor SameSite consistently.
Why Some Applications Still Remain Vulnerable Despite Awareness
Despite CSRF being well understood, applications continue being vulnerable due to inconsistent protection implementation across an application’s many endpoints, legacy code predating current security awareness, and sometimes incorrect assumptions that other security measures – a captcha on the login form, say – already adequately address CSRF risk when they do not touch it at all.
The API-Specific CSRF Considerations Modern Applications Must Address
Modern applications using API-driven architecture need particular CSRF consideration. API endpoints accepting cookie-based authentication remain just as vulnerable to CSRF as traditional web form submissions – a risk some development teams overlook, mistakenly assuming CSRF is purely a concern for traditional web forms. APIs that switch to a bearer token stored outside cookies – in memory or local storage, instead of a cookie the browser attaches automatically – sidestep CSRF by design. That trade-off is not a free win, though: it introduces its own token storage and XSS exposure considerations worth weighing carefully.
Why Testing for CSRF Requires Deliberate, Dedicated Attention
Organizations should include dedicated CSRF testing as part of standard application security testing. This means verifying that anti-CSRF protection exists and functions correctly across every state-changing endpoint – not just the login and payment forms that get the most scrutiny by default. Protection implemented once for one part of an application does not automatically extend to every other part.
A Note on GET Requests and State Changes
One CSRF-adjacent mistake that keeps recurring in code review is using GET requests to trigger state changes – an account deletion or an unsubscribe link, for instance, wired up as a plain hyperlink instead of a form submission. A GET request loaded via an image tag, a prefetch, or simply a link preview generated by a chat app or email client can trigger the action with zero user interaction, often without any token check at all. Developers frequently forget to apply the same CSRF protections to GET routes that they remembered to apply to POST forms. The fix is straightforward: state-changing actions belong behind POST, PUT, or DELETE with proper token validation, never behind a plain GET link. This specific mistake shows up often enough in real audits that it is worth calling out on its own.
Building Consistent CSRF Protection Across Applications
Organizations should build consistent CSRF protection into standard application development frameworks and practice. Every new endpoint should inherit appropriate CSRF protection by default through the framework’s middleware. That beats requiring developers to remember to add CSRF protection manually to each new endpoint they build – a step that reliably gets forgotten under deadline pressure if it is not automatic.