Cross-site request forgery (CSRF) tricks a victim's browser into sending a request the victim never intended, using session cookies or credentials the browser automatically attaches to any outbound call. If a bank's /transfer endpoint accepts a GET or unprotected POST with amount and to_account parameters, an attacker only needs the logged-in victim to load a page containing an auto-submitting form or <img> tag pointing at that URL. The browser sends the victim's real session cookie along with it, and the server processes the transfer as if the victim clicked "confirm" themselves. No malware, no phishing credentials, no XSS payload — just a forged request riding on an authenticated session. CSRF has been implicated in real account takeovers against Netflix, uTorrent, and home routers, and it's still routinely found in internal admin panels, IoT device dashboards, and legacy APIs that predate modern cookie defaults. Understanding exactly how the forgery works is the first step to closing it off.
What is CSRF and how does an attack actually work?
CSRF works by abusing the browser's default behavior of attaching cookies to every request sent to a domain, regardless of which page initiated that request. The attack has three ingredients: a victim with an active authenticated session on a target site, a state-changing endpoint that trusts cookies alone for authentication, and a way to get the victim's browser to fire a request at that endpoint — usually a malicious page hosting an auto-submitting HTML form, a crafted <img src="https://target.com/action?param=value"> tag for GET-based endpoints, or JavaScript using fetch() with credentials: "include". Because the request originates from the victim's own browser with the victim's own cookies, it looks completely legitimate to a server that never checks where the request came from. Classic targets are password-change forms, email-address updates, fund transfers, and privilege changes — anything that alters state without re-verifying the requester's intent.
How is CSRF different from XSS and clickjacking?
CSRF forges a request using the victim's existing session, while XSS injects attacker-controlled code that runs inside the victim's browser session directly — they're often confused because both abuse trust in a logged-in session, but XSS gives an attacker arbitrary script execution and CSRF only gives them one forged, one-way request. A 2005 MySpace incident (the Samy worm) is XSS, not CSRF: Samy Kamkar's script executed inside other users' sessions and self-propagated by rewriting profiles. Clickjacking, by contrast, doesn't forge a request payload at all — it overlays an invisible iframe of the real target site over a decoy page so the victim's genuine click lands on a hidden "delete account" or "authorize" button. All three techniques exploit the same underlying assumption (a cookie proves intent), which is why defenses like X-Frame-Options, Content Security Policy, and anti-CSRF tokens are usually deployed together rather than as substitutes for one another.
What real-world incidents illustrate CSRF's impact?
CSRF has caused account takeovers and unauthorized actions at major platforms, not just in theoretical writeups. In 2006, researcher Jeremiah Grossman publicly documented a CSRF flaw in Netflix that let an attacker-controlled page silently add DVDs to a victim's rental queue and change their shipping address, simply by getting the logged-in victim to visit a booby-trapped page. In February 2015, Google Project Zero's Tavis Ormandy disclosed a CSRF vulnerability in uTorrent's Web UI that went further than data tampering — it let an attacker's page issue unauthenticated requests to the locally-bound WebUI API to download and execute arbitrary files, turning a forged HTTP request into remote code execution. Earlier still, in 2008, researchers Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson published "drive-by pharming," showing that a single malicious web page could use CSRF to log into a victim's home router with its default admin credentials and silently rewrite its DNS settings, redirecting all future traffic to attacker-controlled servers. None of these required stealing a password — they only required a live session and a trusting endpoint.
Is CSRF still a risk in 2026 now that SameSite cookies are the default?
CSRF is reduced but far from eliminated, because browser-level protections only cover cross-site cookie behavior, not every path an application exposes. Chrome 80, released February 4, 2020, began defaulting cookies without an explicit SameSite attribute to SameSite=Lax, which blocks cookies from being sent on most cross-site subrequests and closed off the "classic" <img>-tag CSRF pattern for a large share of the web almost overnight; Firefox and Edge followed with similar defaults. This is also why CSRF was a standalone OWASP Top 10 category from 2007 through 2013 (A5 in 2010, A8 in 2013) but was dropped as its own entry in the 2017 revision, after OWASP's testing data showed average incidence below 5% across the applications it sampled, largely because frameworks like Django, Rails, and ASP.NET Core had started shipping anti-CSRF tokens by default. But SameSite=Lax still allows top-level GET navigations, subdomains sharing a parent domain can still forge requests against each other, and any endpoint using non-cookie auth mechanisms handled sloppily (like accepting a bearer token from a query string) sidesteps the browser protection entirely. CSRF still shows up regularly in bug bounty reports against admin consoles, self-hosted tools, and API gateways that were built before these defaults existed or that explicitly set SameSite=None to support cross-site embedding.
How do you find and fix CSRF vulnerabilities before attackers do?
You find CSRF by testing every state-changing endpoint for a request that succeeds without a valid, per-session anti-CSRF token, and you fix it by requiring one. Manual testing means capturing a legitimate authenticated request in a proxy like Burp Suite, stripping or altering the CSRF token, and replaying it — if the server still processes the action, the endpoint is vulnerable. Automated scanning tools (OWASP ZAP, Burp's active scanner) flag missing or predictable tokens across an entire site map in minutes rather than hours of manual replay. On the fix side, the OWASP-recommended synchronizer token pattern issues a unique, unpredictable token per session (or per request) that must be present in every state-changing form submission and is validated server-side before the action executes; frameworks generate these with cryptographically secure randomness, typically 128 bits or more, so brute-forcing a valid token is computationally infeasible. Pair that with SameSite=Strict or Lax on session cookies, and require re-authentication (a password or step-up MFA prompt) for high-value actions like changing an account's email or payment details — defense in depth matters because any single control can be misconfigured or bypassed on a specific route.
How Safeguard Helps
Safeguard's reachability analysis flags which CSRF-vulnerable endpoints are actually exposed to authenticated, cross-origin traffic in your deployed environment, rather than treating every missing token check as equally urgent across a codebase with thousands of routes. Griffin AI reviews the surrounding controller and middleware logic to confirm whether a token check, SameSite cookie setting, or origin-verification middleware is genuinely present and correctly wired — not just imported and unused — cutting down the false positives that plague pattern-matching scanners. SBOM generation and ingest give you visibility into which framework versions your services run, since older versions of popular web frameworks shipped without CSRF protection enabled by default, making version drift itself a source of risk. When Griffin AI confirms a real gap, Safeguard opens an auto-fix pull request that adds the token middleware and cookie attribute changes directly in context, so the fix ships in the same PR review cycle instead of sitting in a backlog.