← All articles

What Is CSRF (Cross-Site Request Forgery) and How Do You Prevent It?

7 September 2026

What Is CSRF (Cross-Site Request Forgery) and How Do You Prevent It?

Cross-Site Request Forgery (CSRF) makes a logged-in user unknowingly perform an action in their own name: changing a password, transferring money, updating an email address. The attacker does not steal the user’s session; they abuse the browser’s habit of automatically sending cookies.

How the attack works

Browsers automatically attach a site’s cookies to requests going to that site. CSRF exploits this:

  1. The user is logged into bank.example (session cookie in the browser).
  2. The user visits a page the attacker prepared.
  3. That page triggers a request to bank.example in the background — a hidden form auto-submits:
<form action="https://bank.example/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>
  1. The browser attaches the bank.example cookie automatically → the server thinks the request came from the legitimate user.

CSRF is dangerous on state-changing requests (POST/PUT/DELETE).

Modern defence: SameSite cookies

The first line of defence today is the SameSite attribute on the session cookie:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
  • SameSite=Lax (the modern default): the cookie is not sent on most cross-site requests (especially POST), cutting off classic CSRF.
  • SameSite=Strict: stricter; the cookie is never sent from another site.

CSRF tokens (synchronizer token pattern)

The classic, strong method: the server generates an unpredictable CSRF token, embeds it in the form, and validates it on submission. The attacker’s page cannot read the token (Same-Origin Policy), so the forged request lacks it and is rejected. The token must be random, tied to the session, and validated server-side.

Additional controls

  • Origin/Referer validation on state-changing requests.
  • Re-authentication for critical actions.
  • Never perform state-changing actions with GET — GET must be side-effect free.

Summary

CSRF abuses the browser’s automatic cookie sending. The modern, effective defence is layered: SameSite=Lax/Strict on the session cookie, plus a CSRF token on critical/state-changing actions. Together they close almost all classic CSRF scenarios.

Sources: OWASP CSRF Prevention Cheat Sheet, MDN: SameSite cookies.

CyberTestify’s scan checks your CSRF defences and cookie security flags — start a scan to see the gaps in your external surface.