Cross-Site Request Forgery (CSRF)
detect, understand, remediate
CSRF tricks authenticated users into submitting unintended requests, allowing attackers to change account settings, transfer funds, or modify data without the user's knowledge.
No credit card required. Free plan available forever.
What is cross-site request forgery (CSRF)?
Cross-site request forgery (CSRF) is an attack that forces authenticated users to execute unintended actions on a web application. When a user is logged into a site, their browser automatically attaches session cookies to every request sent to that domain. CSRF exploits this behaviour by tricking the browser into sending a forged request (such as changing an email address, transferring funds, or modifying account settings) without the user's knowledge or consent.
Unlike cross-site scripting (XSS), which exploits the trust a user has in a website, CSRF exploits the trust a website has in the user's browser. The server receives a perfectly valid request with legitimate session cookies and has no way to distinguish it from a request the user intentionally made. This makes CSRF particularly dangerous for state-changing operations like password changes, administrative actions, and financial transactions.
CSRF attacks are often invisible to the victim. The malicious request can be triggered by an image tag, a hidden form on an attacker-controlled page, or even a link in an email. While modern browsers and frameworks have introduced protections such as SameSite cookies, many applications still lack adequate CSRF defences, especially on legacy endpoints and APIs that predate these protections.
How it works
Victim is authenticated
The victim is logged into the target application (e.g. a banking site or admin panel) and has an active session cookie stored in their browser.
Attacker crafts malicious page
The attacker creates a web page containing a hidden form or request that targets a state-changing endpoint on the victim's application.
Victim visits attacker page
Through social engineering, a forum post, or a phishing email, the victim is lured to the attacker's page while still authenticated to the target site.
Forged request executes
The victim's browser automatically attaches session cookies and sends the forged request. The server processes it as a legitimate action from the authenticated user.
Common causes
Missing anti-CSRF tokens
State-changing endpoints that do not require a unique, unpredictable token to verify the request originated from the application's own forms.
SameSite cookie attribute not set
Session cookies without the SameSite attribute (or set to None) are sent with cross-origin requests, enabling CSRF from any domain.
Relying solely on cookies for authentication
When session cookies are the only authentication mechanism, any cross-origin request with valid cookies is treated as authenticated.
No Origin or Referer header validation
Failing to verify that incoming requests originate from the application's own domain by checking the Origin or Referer headers.
How to detect it
Automated detection
- SecPortal's authenticated scanner checks for the presence and validation of anti-CSRF tokens on all state-changing forms and endpoints
- SecPortal's domain scanner analyses Set-Cookie headers for SameSite attribute configuration and flags cookies set to None or missing the attribute
- Code scanning detects forms and API routes that handle POST/PUT/DELETE requests without CSRF middleware or token verification
Manual testing
- Submit state-changing requests (password change, email update, settings modification) without CSRF tokens and verify whether the server rejects them
- Craft a simple HTML page with a hidden form targeting a sensitive endpoint and test whether it executes when loaded from a different origin
- Test token reuse, empty tokens, and tokens from other sessions to verify the server-side validation logic is robust
How to fix it
Implement anti-CSRF tokens
Include a unique, unpredictable token in every state-changing form and verify it server-side. Use your framework's built-in CSRF protection (e.g. Next.js Server Actions, Django CSRF middleware, Rails authenticity token).
Set SameSite cookie attribute to Strict or Lax
Configure session cookies with SameSite=Strict (blocks all cross-origin requests) or SameSite=Lax (allows safe top-level navigations). This prevents browsers from attaching cookies to cross-origin POST requests.
Verify Origin and Referer headers
Check the Origin header (or Referer as fallback) on every state-changing request to confirm it matches your application's domain. Reject requests with missing or mismatched origin headers.
Require re-authentication for sensitive actions
For high-impact operations like password changes, email updates, and financial transactions, require the user to re-enter their password or complete a second authentication factor.
Compliance impact
Test for CSRF automatically
SecPortal's authenticated scanner checks for missing CSRF tokens, SameSite cookie issues, and token validation bypasses. Start free.
No credit card required. Free plan available forever.