Antiforgery Tokens
Problem
- An ASP.NET Core app uses cookie-based login. A form lets a logged-in client transfer money.
- The browser attaches the login cookie automatically on every request to the site, including requests triggered by a page on some other, malicious site.
- That site submits the transfer form in the background from the victim's browser. The cookie rides along, and the server cannot tell it apart from a real click.
The cookie proves who is logged in, not that they meant to submit this form.
Solution
Antiforgery Tokens
- The server embeds a token tied to the user's session inside the real form.
- On submit, the request must carry that token back; the server validates it before acting.
- The malicious site can neither read nor forge the token, so its submission fails the check.
A cookie proves identity. The antiforgery token proves intent.
Analogy
Your bank teller knows your face, so identity is never in doubt. To withdraw money, you still fill and sign a withdrawal slip at the counter.
Someone who merely knows your face cannot withdraw a thing, because they cannot produce the slip signed in front of the teller.
The antiforgery token is that slip; the cookie is only the face.
