What is CSRF?
You're logged into your banking app. You visit a random forum. That forum has a hidden form that silently submits a POST request to your bank's transfer endpoint. Your browser attaches your session cookie automatically. The bank sees a valid, authenticated request and processes the transfer. You never clicked anything.
CSRF works because browsers automatically include cookies with every request to a domain, regardless of where the request originated. If your app relies solely on cookies for authentication and doesn't verify where the request came from, any website can forge requests on behalf of your logged-in users.
Modern frameworks have mitigations — SameSite cookies, CSRF tokens, origin header checks — but AI-generated code frequently skips all of them. The code works in testing because the developer is making legitimate requests. The vulnerability only shows up when the request comes from somewhere else.
How does CSRF work?
A CSRF attack requires three things: the victim is logged in (has a valid session cookie), the target endpoint performs a state-changing action based only on that cookie, and the attacker can predict all the request parameters.
Here's a typical vulnerable API route that changes a user's email with no CSRF protection:
// app/api/account/email/route.ts
export async function POST(req) {
// Auth relies entirely on the session cookie.
// Any site can trigger this request.
const session = await getSessionFromCookie(req);
const { newEmail } = await req.json();
await db.user.update({
where: { id: session.userId },
data: { email: newEmail },
});
return Response.json({ success: true });
}// app/api/account/email/route.ts
import { validateCsrfToken } from '@/lib/csrf';
export async function POST(req) {
const session = await getSessionFromCookie(req);
// Verify the request includes a valid CSRF token
// that matches the one stored in the session.
const csrfToken = req.headers.get('x-csrf-token');
if (!validateCsrfToken(csrfToken, session)) {
return Response.json(
{ error: "Invalid CSRF token" },
{ status: 403 },
);
}
const { newEmail } = await req.json();
await db.user.update({
where: { id: session.userId },
data: { email: newEmail },
});
return Response.json({ success: true });
}
// Also: set cookies with SameSite=Lax or Strict
// Set-Cookie: session=abc; SameSite=Lax; Secure; HttpOnlyWhy do AI tools generate CSRF vulnerabilities?
AI tools generate API routes that handle the happy path: receive a request, check the cookie, do the thing. CSRF protection is a second layer of defense that only matters when the request comes from a malicious origin — a scenario that never occurs during normal development and testing.
- CSRF tokens add complexity with no visible benefit. The app works perfectly without them during development. The AI optimizes for working code, and CSRF tokens are invisible plumbing that only matters under attack.
- Cookie auth feels complete. The model generates a session check — "is the user logged in?" — and that feels like enough. The distinction between "authenticated" and "intentionally initiated" isn't something the model reasons about.
- SameSite cookie defaults vary by framework. Some frameworks default to SameSite=Lax (partial protection), others don't set it at all. AI-generated code rarely sets cookie attributes explicitly, leaving you with whatever the default happens to be.
CSRF might sound like a relic from 2010, but it's still actively exploited. SameSite cookies help, but they don't cover every case — especially with cross-subdomain setups, older browsers, or APIs that accept both cookie and token auth.
Common CSRF patterns
State-changing GET requests
Actions like /api/account/delete?confirm=true triggered via GET — trivially exploitable with an img tag.
Missing SameSite cookie attribute
Session cookies without SameSite=Lax or Strict, allowing cross-origin requests to include them.
No origin or referer validation
Server accepts POST requests from any origin without checking the Origin or Referer header.
CORS misconfigured with credentials
Access-Control-Allow-Origin set to a wildcard or reflected origin with Access-Control-Allow-Credentials: true.
How Flowpatrol detects CSRF
Flowpatrol tests your state-changing endpoints for CSRF protection the way a real attacker would — by simulating cross-origin requests:
- 1Maps state-changing endpoints by identifying POST, PUT, PATCH, and DELETE routes that modify data.
- 2Tests cross-origin requests — sends requests without CSRF tokens and with forged Origin headers to see if they succeed.
- 3Inspects cookie attributes to check whether session cookies have SameSite, Secure, and HttpOnly flags set correctly.
- 4Reports exploitable endpoints with the exact request that bypassed protection, so you know what to fix first.
CSRF is one of those vulnerabilities that's invisible in normal testing but trivial to exploit. Flowpatrol catches it before someone else does.
Related terms
Check your app for CSRF.
Flowpatrol tests your endpoints for missing CSRF protection and weak cookie settings. Paste your URL and see what comes back.
Try it free