Cross-Site Request Forgery (CSRF) is an attack that tricks a logged-in victim's browser into submitting a request the victim never intended, by exploiting the fact that browsers automatically attach a site's session cookie to every request sent to that site, no matter which page triggered it. The term itself was coined in a public Bugtraq post by researcher Peter Watkins in 2001, though the underlying weakness — a state-changing endpoint that trusts a cookie as proof of intent — predates the name by years. A single forged HTML form, an <img> tag pointing at a GET endpoint, or a line of auto-submitting JavaScript is enough to fire a funds transfer, a password reset, or an admin action on a victim's behalf while the server sees nothing but a normal, cookie-authenticated request. CSRF was a standalone entry on the OWASP Top 10 in 2010 and again in 2013 before falling out of the standalone rankings — but it still surfaces routinely in bug bounty reports against admin panels, IoT dashboards, and internal tools built without modern cookie defaults.
What is CSRF, exactly?
CSRF is a confused-deputy attack: the server ends up trusting a request because it carries a valid session cookie, without verifying that the page which generated the request was actually one the site itself served. Three conditions have to line up for it to work — a victim with an active, authenticated session on the target site; a state-changing endpoint (a form submission, an API call, a GET-based action link) that authenticates purely on cookies; and a way to get the victim's browser to fire a request at that endpoint, typically by luring them to an attacker-controlled page. Because the browser, not the user, decides whether to attach cookies to a request, the server has no built-in way to tell a request that originated from its own <form> apart from one triggered by a hidden form on evil-example.com. That gap is the entire vulnerability — everything else is just variations on how the forged request gets sent.
How does a CSRF attack actually happen, step by step?
A CSRF attack happens in four steps: the victim logs into a target site and receives a session cookie, the victim then visits a page controlled by the attacker (via a phishing link, a malicious ad, or a compromised forum post), that page auto-fires a request at the target site's vulnerable endpoint, and the browser attaches the victim's valid session cookie to that request without asking permission. For a GET-based endpoint like https://bank.example.com/transfer?to=attacker&amount=5000, the attacker only needs an <img src="..."> tag — the browser tries to load it as an image, the request still goes out with cookies attached, and the transfer executes even though the "image" never renders. For POST-based endpoints, the attacker uses a hidden HTML form with autocomplete fields matching the target's parameter names and a script that calls .submit() the instant the page loads, so the victim sees nothing but a blank or decoy page for the split second the forged request completes. In both cases the attacker never touches the victim's credentials or session token directly — they just borrow the browser that's already holding them.
What's a real example of a CSRF vulnerability?
Two of the most cited real-world CSRF disclosures both landed in 2007 and 2008, against Gmail and YouTube. In January 2007, researcher Petko D. Petkov (GNUCITIZEN) disclosed a CSRF flaw in Gmail's settings that let a malicious page silently inject a new mail filter into a logged-in victim's account — a filter that could forward every incoming email to an attacker-controlled address, turning one forged request into ongoing, invisible surveillance of the victim's inbox. In 2008, the same research group documented a CSRF weakness in YouTube that let a forged request add videos to a victim's favorites, flag videos as inappropriate, post comments, or add unwanted subscriptions, all without the victim clicking anything on YouTube itself. Neither incident required stealing a password or running injected script in the victim's browser; both relied entirely on the victim simply loading an attacker's page while an active session cookie sat in their browser.
How is CSRF different from XSS?
CSRF forges a single request using a session the victim already has, while XSS runs attacker-controlled JavaScript directly inside that session, which is a meaningfully bigger blast radius. An XSS payload can read the page's DOM, exfiltrate data, chain into further requests, or even generate a valid CSRF token itself and use it — which is why a site with an XSS bug is effectively CSRF-vulnerable too, no matter how strong its tokens are. CSRF, on the other hand, is a one-shot, blind attack: the attacker can make the victim's browser send a request, but can't read the response, can't see the page, and can't adapt if the first attempt fails. That constraint is also why CSRF defenses (anti-CSRF tokens, SameSite cookies) and XSS defenses (output encoding, Content Security Policy) are different control families that get deployed side by side rather than as substitutes for each other.
How do developers actually prevent CSRF?
Developers prevent CSRF primarily with the synchronizer token pattern: the server generates a unique, unpredictable token per session (or per form), embeds it in every state-changing form as a hidden field, and rejects any submission that doesn't include a matching token. Django, Ruby on Rails, and ASP.NET Core have all shipped this protection on by default since roughly the early-to-mid 2010s, which is a major reason CSRF's raw incidence dropped enough for OWASP to fold it out of its standalone Top 10 category in the 2017 revision. A second, complementary layer is the SameSite cookie attribute: setting SameSite=Lax or Strict on a session cookie tells the browser not to attach it to most cross-site requests in the first place, and Chrome made Lax the default for cookies without an explicit SameSite value starting with Chrome 80 on February 4, 2020, with Firefox and Edge following soon after. Neither layer alone is sufficient — a token check that's present but never validated server-side, or a cookie explicitly set to SameSite=None to support a legitimate cross-site embed, reopens the exact gap both controls exist to close.
Is CSRF still a real risk in 2026?
Yes — CSRF is reduced by default browser behavior but not eliminated, because SameSite=Lax still permits top-level GET navigations and does nothing for endpoints that authenticate with something other than cookies. An endpoint that reads a bearer token from a query string, a subdomain that shares cookies with a sibling subdomain it doesn't fully trust, or a self-hosted admin tool built years before modern cookie defaults existed can all still be forged today exactly as they could in 2008. CSRF also remains common in mobile app WebViews and embedded browser components, which don't always inherit the same-origin and SameSite protections that mainstream desktop browsers ship, and in APIs that were designed for server-to-server calls and never expected a browser-based attacker in the first place. Bug bounty platforms continue to pay out for CSRF reports against admin consoles and internal dashboards years after the "SameSite by default" milestone, which is the clearest evidence that the vulnerability class is contained, not closed.
How Safeguard Helps
Safeguard's reachability analysis identifies which CSRF-vulnerable endpoints in your codebase are actually reachable from authenticated, cross-origin browser traffic in your deployed environment, so a missing token check on a dead internal route doesn't get the same urgency as one on a live account-settings form. Griffin AI reads the surrounding controller, middleware, and cookie-configuration code to confirm whether a CSRF token check or SameSite attribute is genuinely enforced — not merely imported — which filters out the false positives that plague scanners that only look for the presence of a library. Safeguard's SBOM generation and ingest track which framework versions your services run, since older releases of common web frameworks shipped without CSRF protection enabled by default, making unpatched version drift a CSRF risk in its own right. When Griffin AI confirms a real, reachable gap, Safeguard opens an auto-fix pull request that wires in the token middleware or corrects the cookie attribute directly in context, so the fix lands in the next review cycle instead of a backlog.