CSRF (Cross-Site Request Forgery) is an attack where a malicious site causes an authenticated user's browser to send an unwanted state-changing request to another site — for example transferring funds, changing an email address, or creating an admin account. It works because browsers automatically attach session cookies to requests, so the target site cannot tell the request did not originate from a real user action.
Why it matters
CSRF can perform any action the logged-in victim is allowed to perform, silently and without their knowledge. Unlike xss, the attacker never sees the response — they just trigger a side effect. Common targets are admin dashboards, banking flows, account-settings endpoints, and password-change forms. A single missing token on a sensitive POST endpoint can be enough to enable mass account takeover.
How to defend against it
- Use anti-CSRF tokens — unique, unpredictable, per-session (or per-request) values embedded in forms and validated server-side on every state-changing request.
- Set session cookies with
SameSite=Lax(default in modern browsers) orSameSite=Strictto block cross-origin cookie attachment for top-level navigations and sub-requests respectively. - Validate the
Originheader (and fall back toReferer) on all POST/PUT/DELETE endpoints as a secondary check. - Require re-authentication or a one-time code for high-impact actions like password and email changes.
- Configure cors carefully — overly permissive CORS can undermine SameSite protections.
- Enforce https and hsts so cookies cannot be downgraded over plaintext, and apply a strong csp to limit what attacker-controlled markup can reach.