Author: Kateryna Ivanenko, Invicti Brand Manager
What CSRF is — briefly
CSRF, or Cross-Site Request Forgery, is a type of web security attack that tricks an authenticated user’s browser into performing an unwanted action on a trusted site. It works by exploiting a user’s authenticated session, causing the browser to send a malicious request to a website where the user is already logged in, which can lead to unauthorized actions like changing account settings or transferring funds without the user’s consent.
You can read more about the difference between CSRF and XSS (cross-site scripting) on this page.
Root causes of CSRF
1) Relying solely on cookies to identify the user
If an application authorizes actions only because a valid session cookie is present, any cross-site request that the browser makes with those cookies attached can execute. Browsers attach such cookies automatically, regardless of the page that initiated the request, which is the foundational precondition for CSRF.
2) Missing or ineffective anti-CSRF tokens
The most robust defense is to require a per-request token that an attacker’s site cannot read or guess. Where they are absent, predictable, reused, or not bound to the user/session, CSRF becomes feasible. OWASP explicitly recommends token-based defenses as primary mitigation.
3) Unsafe use of HTTP methods
If sensitive actions are permitted via GET — or if the server does not distinguish read vs. write semantics — attackers can trigger them with an <img>, <link>, or simple navigation. State-changing actions via GET should be prohibited.
4) Weak request-origin validation
If a website does not verify where requests come from (using the Origin or Referer headers), it cannot tell whether a user action was made on its own site. Attackers can then trick the browser into sending unauthorized requests. Properly checking the Origin header and keeping a strict list of allowed sources helps prevent this.
5) Misconfigured SameSite cookies
SameSite helps — but is not a silver bullet. Apps that rely only on this practice remain vulnerable.
6) CORS (Cross-Origin Resource Sharing) misconfigurations
If a web application lets browsers send login cookies or tokens (Access-Control-Allow-Credentials: true) and simultaneously accepts requests from any site, then a hacker’s website could send them as the user and possibly even see the response. In short — allowing all origins while trusting credentials opens the door to CSRF attacks.
7) OAuth/OIDC flows without a proper state parameter
Login flows are a special CSRF case: if the client app does not bind the authorization response to the initiating browser session using a cryptographically strong state value (and validate it on return), attackers can swap or inject authorization codes/tokens. The OAuth specs and major identity providers call out state as a required CSRF control.
8) Overly long-lived sessions or excessive privileges
When sessions never expire, or include powerful privileges, any CSRF succeeds with greater impact. While not a direct cause, it makes the consequences worse.
Quick cheat sheet for mitigation of CSRF
- Require anti-CSRF tokens on state-changing requests; bind to user/session. You can find more info about the usage of anti-CSRF tokens in this article.
- Treat GET as read-only; enforce method checks server-side.
- Check where the request comes from: use the Origin header, and if it is missing, rely only on a carefully checked Referer header.
- Configure cookies deliberately: set SameSite thoughtfully; combine with tokens rather than relying on SameSite alone. Use Secure and HttpOnly flags where applicable.
- Strengthen CORS: do not use Access-Control-Allow-Credentials: true unless you really need it, and never combine it with * or a copied Origin value.
- For OAuth/OIDC: generate a cryptographically strong state, bind it to the user session, and verify it on the redirect.
- Session configurations: shorter lifetimes, limited privileges, and additional auth for critical operations.
How to detect CSRF vulnerability in web applications
The only way to detect CSRF is website security testing. Various scanners can be used for this purpose, for example:
- DAST (black-box): imitation of hacker’s actions that uncovers vulnerabilities during runtime.
- SAST (white-box): searching for defects directly in application’s code, similar to finding mistakes in text.
The best practice is to combine both methods, since dynamic testing helps to discover runtime-specific vulnerabilities, but cannot scan the whole codebase like static analysis. Both can be implemented in CI/CD, with SAST being integrated at earlier stages.
If you want to test such solutions for free, it can be DAST from Invicti (based on Acunetix and Netsparker) or SAST, SCA, Container Security product like Mend.io. For that, please leave your contact details below:
Request for free Invicti/Mend.io Trial
Leave your contact details and we will get in touch with you
