On this page
What Is CSRF (Cross-Site Request Forgery)?
CSRF tricks a logged-in user's browser into making requests they didn't intend. Learn how it works, why AI tools skip it, and how to prevent it.
Quick answer
- CSRF makes a victim’s browser send a request the victim didn’t intend, riding on their logged-in session.
- The classic example: a malicious page silently submits a form that transfers money from the victim’s bank account.
- Defenses include CSRF tokens and SameSite cookies, which frameworks don’t always enable by default.
What is CSRF?
Cross-site request forgery is an attack that forces an authenticated user’s browser to make an unwanted request to a site where they’re logged in. Because the browser automatically includes the user’s cookies, the target site sees a legitimate, authenticated request — even though the user never chose to make it. The attack exploits the browser’s trust in the user’s session rather than the application’s trust in the browser.
How it works
Imagine you’re logged into your bank. You visit an attacker’s page that contains a hidden form:
<form action="https://bank.example.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="1000">
</form>A script auto-submits it. Your browser sends the request with your bank cookies, and the bank performs a transfer you never authorized. The attack works because state-changing requests often rely on cookies alone for authentication.
How to prevent it
The standard defense is a CSRF token: a random, per-session value the server embeds in forms and requires back with each state-changing request. An attacker’s page can’t read or guess it, so forged requests fail. SameSite cookies add a second layer by restricting when cookies are sent cross-site. Modern frameworks often provide both, but they’re frequently not enabled by default — a known gap in AI-generated apps.
Where this bites vibecoders
Independent testing has found that AI coding tools frequently fail to implement CSRF protection by default — the generated login and form handling works, but the token is missing. Because the app functions perfectly in normal use, the gap only shows up in an attack. The habit is to confirm your framework’s CSRF protection is actually on, not assumed.
Where AI coding assistants get this wrong
- Building forms and state-changing endpoints with no CSRF token.
- Not enabling the framework’s CSRF middleware that already exists.
- Setting permissive SameSite cookie policies without understanding the trade-off.
- Protecting some forms but not API endpoints that also change state.
Checklist
- Enable CSRF protection on all state-changing requests.
- Use the framework’s built-in CSRF middleware rather than hand-rolling tokens.
- Set SameSite cookies to Lax or Strict as appropriate.
- Verify a forged cross-site request actually fails.
- Cover APIs that rely on cookies, not just HTML forms.
FAQ
What is the difference between CSRF and SSRF?
CSRF tricks a user’s browser into making a request to your site. SSRF tricks your server into making a request to another system. The attacker targets the victim in CSRF and your backend in SSRF. See What Is SSRF?.
Does SameSite=Lax replace CSRF tokens?
For many cases SameSite=Lax blocks cross-site POSTs, which mitigates classic CSRF. But it’s not a complete replacement in every scenario (older browsers, subdomain attacks), so defense in depth — tokens plus SameSite — remains the recommendation.
Do APIs need CSRF protection?
APIs authenticated with cookies do, because the browser sends those cookies automatically. APIs that use an Authorization header (which the attacker’s page can’t set) are generally not vulnerable to classic CSRF, but the safest posture is to protect any state-changing endpoint that trusts ambient credentials.