Cross-Site Request Forgery
Tricking a logged-in user's browser into sending a state-changing request to another site, which works because the browser attaches that site's cookies automatically.
Cross-site request forgery (CSRF) is an attack in which a page on one site causes the visitor's browser to send a request to another site where the visitor is logged in. The browser attaches the target site's cookies automatically, so the request arrives authenticated, and if it changes state (transfers money, changes an email address, deletes something) the server carries it out. The attacker never sees the response and doesn't need to. A hidden auto-submitting form is enough.
The Same-Origin Policy does not stop this. It stops the attacking page from reading responses, not from sending requests, and HTML forms have always been allowed to post anywhere. CORS does not stop it either: CORS relaxes the read restriction, while simple form-style requests are sent before any CORS check applies.
Defenses, roughly from newest to oldest:
SameSitecookies. A session cookie markedLaxorStrictis not sent on cross-site subrequests, which removes the attack's premise. Chrome and other Chromium browsers now default toLax, a large part of why CSRF is much rarer than it was.- Fetch metadata. Browsers send
Sec-Fetch-Site, so a server can refuse state-changing requests whose value iscross-site. - Origin checking. Compare the
Origin(orReferer) header to an allowlist of the site's own origins. - Synchronizer tokens. Embed an unguessable per-session token in every form and require it back. A cross-site page can't read it, so it can't include it.
The allowlist approach has an operational trap. An allowlist computed once at startup goes stale the moment the app creates new origins at runtime, as a multi-tenant app does when each new tenant gets its own subdomain. Requests from the new origin are rejected as forgeries until the process restarts. The symptom is a 401 or 403 that happens only for brand-new tenants, which looks like an authentication bug. A check that derives allowed origins from the same source of truth the router uses, at request time, avoids it.
Two boundaries are worth knowing. CSRF defenses assume no Cross-Site Scripting: script running on the site can read any token and send any request, so XSS defeats every CSRF defense. And APIs authenticated by a bearer token in a header, rather than a cookie, are immune by construction, because nothing is attached automatically. That is Least Privilege for credentials: send them only where they were explicitly meant to go.
See also5
Server-Side Request Forgery
Tricking a server into making requests on an attacker's behalf, reaching internal services and cloud credential endpoints that the attacker could never reach directly, behind some of the largest cloud breaches.
Web Platform14 connections
Session Management
How a website remembers that a visitor has signed in across otherwise unrelated requests, usually with a random identifier in a cookie, and the attacks that target that identifier.
Web Platform11 connections
Open Redirect
A page that forwards visitors to whatever address a URL parameter names, letting attackers borrow a trusted domain to launch phishing or steal sign-in tokens, and the narrow ways to fix it.
Web Platform15 connections
Referrer Policy
The rules for when a browser tells a site which page a visitor came from, a header misspelled in the 1990s that leaked private addresses for decades until browsers began trimming it by default.
Web Platform12 connections
Clickjacking
Tricking a user into clicking something on another site by loading it invisibly in a frame beneath a decoy, and the headers that stop a page from being framed.
Web Platform9 connections
Linked from11
- ClickjackingWeb Platform
Tricking a user into clicking something on another site by loading it invisibly in a frame beneath a decoy, and the headers that stop a page from being framed.
- Cross-Site ScriptingWeb Platform
Injecting attacker-controlled script into a page that a victim's browser then executes with the victim's own privileges.
- HTTP CookieWeb Platform
A small piece of state a server asks the browser to store and send back on later requests, governed by attributes that decide exactly where it goes.
- JSON Web TokenWeb Platform
A signed, self-contained token that carries claims a server can verify without a database lookup.
- LoopbackNetworks & Distribution
The network address a computer uses to talk to itself, where packets go out and come straight back without touching any hardware, the home of development servers and a recurring blind spot in security.
- MiddlewareWeb Platform
Functions that sit between an incoming web request and the code that answers it, each able to inspect, change, or end the request, chained in an order that quietly determines how the whole application behaves.
- Multi-TenancyData & Content
One deployment serving many isolated customers, with tenancy threaded through data, routing, and access.
- Referrer PolicyWeb Platform
The rules for when a browser tells a site which page a visitor came from, a header misspelled in the 1990s that leaked private addresses for decades until browsers began trimming it by default.
- Same-Origin PolicyWeb Platform
The browser rule isolating documents by scheme, host, and port, and the mechanisms for relaxing it.
- Server-Side Request ForgeryWeb Platform
Tricking a server into making requests on an attacker's behalf, reaching internal services and cloud credential endpoints that the attacker could never reach directly, behind some of the largest cloud breaches.
- Session ManagementWeb Platform
How a website remembers that a visitor has signed in across otherwise unrelated requests, usually with a random identifier in a cookie, and the attacks that target that identifier.