Application Security · Learn

What is CSRF?

Cross-Site Request Forgery tricks a logged-in user’s browser into sending an unwanted request to a site they are authenticated to, performing actions without their consent. Here is what CSRF is and how anti-CSRF tokens stop it.

Application Security · LearnApplication Penetration Testing
TL;DR

CSRF (Cross-Site Request Forgery) is a vulnerability where an attacker tricks a victim’s browser into sending a state-changing request to a site the victim is logged into. The action runs with the victim’s session without their intent: changing a password, transferring funds, or updating an email. It works because browsers automatically attach cookies. The standard fix is an anti-CSRF token the attacker cannot guess, reinforced by SameSite cookies.

By Shubham Khandare, Delivery Manager, SecureLayer7Updated

What CSRF is

When a user is logged into a site, their browser automatically sends the session cookie with every request to that site, including requests triggered by another site. That automatic attachment is the root of CSRF.

An attacker builds a page that quietly submits a request to the target site (a form post, an image tag, JavaScript). When the logged-in victim visits it, their browser sends the request with their cookies, and the target site, seeing a valid session, performs the action as if the user meant it.

How it works and example

The attacker hosts a page that auto-submits a request to the target:

  • A hidden auto-submitting form posts to https://bank.example/transfer with the attacker’s account as the recipient.
  • An <img src="https://app.example/account/delete"> fires a GET-based state change.
  • When the authenticated victim loads the attacker’s page, the request runs as them.

CSRF needs the action to rely on cookies alone and to lack an unpredictable token. It does not let the attacker read the response, only cause the action. Examples shown for defensive context.

How to fix it

  • Use anti-CSRF tokens on every state-changing request (synchronizer token or double-submit), validated server-side.
  • Set `SameSite=Lax` or `Strict` on session cookies so they are not sent on cross-site requests.
  • Require re-authentication or a token for sensitive actions.
  • Do not make GET requests state-changing.
  • Check Origin/Referer as a supporting control, and test forms for missing token validation.

References

  1. [1]OWASP: CSRF Prevention(OWASP)
  2. [2]MITRE CWE-352: Cross-Site Request Forgery(MITRE CWE)
  3. [3]OWASP Top 10(OWASP)
Related terms

Common questions

CSRF, asked often

Want your application tested for this?

Scope an engagement

Test your application for CSRF and 30+ other classes.

Our application penetration test is manual, evidence-led, and built so your developers can reproduce and fix every finding. Each engagement ships with proof-of-exploit and a free re-test.

See the methodology30-min scoping call, fixed-price proposal in 48 hours.