Short definition
Cross-site request forgery, or CSRF attack, is an attack that tricks an authenticated user’s browser into sending an unwanted request to a web application on the attacker’s behalf. The server processes the request because it appears to come from a trusted, logged-in user. The user never knowingly initiates the action.
Extended definition
CSRF attack exploits the trust a web application places in a user’s authenticated session. When a user logs into a site, the server issues a session cookie that is automatically attached to every subsequent browser request. An attacker who can craft a request to that site can embed it in a malicious page, email, or image tag. When the victim visits or loads that content, the browser fires the request with the victim’s active session attached.
The attack is particularly dangerous for state-changing operations: fund transfers, password changes, email updates, administrative actions, and API calls that modify data. Because the server sees a valid session cookie, it cannot distinguish the forged request from a legitimate one without additional verification.
CSRF attack is listed in the OWASP Top 10 and remains a common vulnerability in applications that rely solely on cookie-based authentication without implementing origin validation or anti-CSRF tokens. Modern same-site cookie attributes have reduced exposure, but incomplete implementations and legacy applications continue to present real risk. APIs that accept cookie-based auth and lack CORS restrictions are especially vulnerable.
Effective defense requires a layered approach: CSRF tokens, same-site cookie flags, origin and referer header validation, and user re-authentication for sensitive actions. None of these controls alone is sufficient for high-risk endpoints.
Deep technical explanation
How a CSRF attack is constructed
An attacker identifies a state-changing endpoint on a target application, for example a POST request to /account/transfer. They craft an HTML page containing a form or image tag that targets this endpoint with attacker-controlled parameters. When a victim who is authenticated to the target site visits the attacker’s page, the browser automatically includes the session cookie in the outbound request. The server validates the session, finds it active, and processes the transfer.
GET-based state changes are the easiest to exploit since an image tag with a crafted src attribute is sufficient. POST-based attacks require a hidden auto-submitting form, which is still straightforward to deliver via phishing or a compromised third-party resource.
Anti-CSRF token pattern
The synchronizer token pattern is the most widely implemented defense. The server generates a cryptographically random token tied to the user’s session and embeds it in each form or exposes it via a custom HTTP header for JavaScript clients. On every state-changing request, the server validates that the submitted token matches the session-bound value. Because the attacker’s page runs in a different origin, the Same-Origin Policy prevents it from reading the token, so the forged request fails validation.
Same-site cookie attribute
The SameSite cookie attribute instructs browsers not to send the cookie on cross-site requests. Setting SameSite=Strict blocks the cookie on all cross-origin navigations. SameSite=Lax permits the cookie on top-level GET navigations but blocks it on cross-origin POST requests, which mitigates most CSRF attack vectors. However, SameSite alone is not a complete defense: subdomains within the same registrable domain are treated as same-site, so a compromised subdomain can still forge requests.
Origin and referer header validation
Servers can inspect the Origin or Referer header to confirm the request originates from the expected domain. This is a useful secondary check but is not reliable as a sole control: some browsers omit the Referer header for privacy, proxy configurations can strip or alter headers, and certain redirect chains can obscure the true origin.
Edge cases and failure modes
CSRF tokens stored in cookies rather than server-side sessions create a double-submit cookie pattern that is weaker: a subdomain compromise can overwrite the cookie. Applications that mix same-site and cross-site resource loading must audit every endpoint. OAuth callback flows require a state parameter to prevent forged authorization responses. APIs consumed by mobile clients and browser-based single-page applications often skip traditional CSRF tokens and rely on custom headers, which is effective only when the CORS policy is correctly restricted.
Practical examples
A fintech platform processed fund transfers via a POST endpoint protected only by session cookies. An attacker embedded a hidden form on a phishing page. Victims who clicked the link while logged in inadvertently authorized transfers. Adding synchronizer tokens and SameSite=Strict cookies stopped the attack vector entirely.
An internal admin panel accepted GET requests to deactivate user accounts. A single malicious link shared in a Slack channel was enough to trigger the action when an admin clicked it while authenticated. Converting the action to a POST endpoint with a CSRF token and re-authentication requirement eliminated the risk.
A SaaS product’s API accepted cookie-based auth with an overly permissive CORS policy. Attackers could forge requests from any origin. Restricting CORS to specific trusted domains and enforcing a custom X-Requested-By header resolved the exposure.
During an OAuth integration, a developer omitted the state parameter on the authorization redirect. This allowed an attacker to initiate an authorization flow and then trick the victim into completing it, linking the attacker’s account to the victim’s identity. Adding a cryptographically random state parameter validated server-side closed the gap.
Why it matters
- CSRF attack can cause real financial and data damage by executing privileged actions without user knowledge or consent.
- Session cookies alone do not prove that the user intentionally submitted a request, so additional token-based verification is required.
- Modern frameworks include CSRF protection by default, but custom APIs, legacy endpoints, and microservices often lack it.
- SOC 2, ISO 27001, and NIS2 controls require that web application attacks be identified and mitigated as part of a documented security program.
- Incomplete SameSite cookie configurations and permissive CORS policies leave CSRF exposure even in otherwise modern stacks.
- Identifying CSRF vulnerabilities requires both static code review and active testing, as automated scanners frequently miss context-dependent token logic.