Skip to content
>_ITDITDWeb Security Platform

Glossary

#CSRF#vulnerability#web

What is CSRF (Cross-Site Request Forgery) — making a logged-in user act without meaning to

CSRF (Cross-Site Request Forgery) uses a logged-in user's browser to send a request they never intended (a transfer, a settings change) via another site. How it works, and the real defense (CSRF tokens, SameSite cookies, Origin checks) — explained defensively, without attack steps.

Published 2026-06-08 Updated 2026-06-08 3 min read

"Just opening another site while still logged in triggers a transfer or settings change without you knowing" — that's CSRF. Here's how it works and how to reliably prevent it (no attack steps).

Why it works (the mechanism)

A browser automatically attaches a site's cookies to requests for that site. So if a user is logged into their bank, a request to the bank triggered from a malicious page still carries "the user's cookies." To the server, it's indistinguishable from a legitimate action.

① The user is logged into the target site (holds a cookie)
↓ they open another page
② A malicious page triggers a request to the target site
↓ the browser auto-attaches the target's cookie
③ The server runs it as 'the user's action' (transfer, settings…)
Because the browser auto-sends cookies, a request 'via another site' passes as the user's own action.

Where XSS "runs code in the victim's browser," CSRF "borrows the victim's logged-in state" (→ What is XSS).

Defense

1

Require a CSRF token

On state-changing actions (form submits, APIs), require an unguessable one-time token issued by the server; reject requests without it. Most frameworks ship this.

2

Set SameSite cookies

Mark session cookies SameSite=Lax (or Strict) so cookies aren't attached to cross-site-originated requests. Lax is the modern default and helps a lot on its own.

3

Don't use GET for state changes

GET (viewing) must have no side effects. Make changes POST/PUT/DELETE and run them through token validation.

4

Check Origin / Referer

For sensitive actions, verify the request's Origin is your own site and reject external origins.

ITD's view: mostly 'solved', but don't get complacent

Framework CSRF tokens plus the browser's SameSite=Lax default have hugely reduced classic CSRF. Still, it bites in custom APIs, legacy setups, and admin panels that skipped the token. Even if you "leave it to the framework," verify once yourself that state-changing paths actually run token validation.

Common gaps

Even when you know the mechanism, implementations tend to slip in two places.

  • GET with side effects: if a viewing GET changes state, an image tag or a plain link is enough for CSRF. Make state changes POST/PUT/DELETE and run them through token validation.
  • Forgetting token validation on some paths: APIs and admin features added later often skip the token. Don't assume "the framework has it" — inventory every state-changing path once.

FAQ

QHow is CSRF different from XSS?
A

XSS runs a script in the victim's browser; CSRF uses the victim's logged-in state to send an unintended request. CSRF works even without running any script — just from the browser auto-sending cookies.

QWhat's the top defense against CSRF?
A

Require a CSRF token on state-changing requests (POST, etc.), and set SameSite (Lax/Strict) on session cookies. Most frameworks ship the token by default. Also: never use GET for state changes.

QIs SameSite alone enough?
A

It helps a lot but isn't a silver bullet. Gaps remain on older browsers, certain navigations, and some subdomain setups — so pair it with CSRF tokens for defense in depth.