CSRF (Cross-Site Request Forgery), pronounced "sea-surf", is a web security vulnerability that tricks a user's browser into making an unwanted request to a site where they are authenticated. The server receives a legitimate-looking request and has no way to distinguish it from a genuine one.
How a CSRF Attack Works
- You are logged in to your bank's website in one browser tab.
- You visit a malicious website in another tab.
- The malicious page contains a hidden request to transfer money on your bank's site.
- Your browser sends this request automatically, including your bank's session cookie.
- Your bank processes the transfer as if you initiated it.
CSRF Protection: Anti-CSRF Tokens
The most effective defence is the synchroniser token pattern:
- The server generates a unique, random token for each session or request.
- The token is embedded in all HTML forms as a hidden field.
- The server verifies the token on every state-changing request (POST, PUT, DELETE).
- Since the attacker's site cannot read the token (blocked by Same-Origin Policy), forged requests fail.
Other CSRF Defences
- SameSite cookie attribute — Prevents cookies from being sent with cross-site requests.
SameSite=StrictorSameSite=Lax. - Origin/Referer header validation — Verify the request came from your own domain.
- Double submit cookie — A random value in both a cookie and a form field; the server verifies they match.
In ASP.NET Core, the @Html.AntiForgeryToken() helper and the [ValidateAntiForgeryToken] attribute implement anti-CSRF protection automatically.