Cross-site request forgery (CSRF)

What is cross-site request forgery?

Cross-site request forgery (CSRF) is an attack that makes a logged-in user’s browser send a request the user never intended, by exploiting the fact that browsers automatically attach cookies to requests going to a site, regardless of which page triggered them. If a victim who is authenticated to bank.example visits a malicious page, that page can submit a hidden form to bank.example/transfer, and the browser will helpfully include the victim’s session cookie. The server sees a valid, authenticated request. CSRF targets state-changing actions (transfers, password and email changes, deletions, privilege grants); it cannot read responses, only cause effects.

How it shows up in real code

The vulnerable pattern is a state-changing endpoint whose only protection is the session cookie:

<form action="https://app.example/settings/email" method="POST">
  <input type="hidden" name="email" value="[email protected]">
</form>
<script>document.forms[0].submit()</script>

Common variants an audit finds: actions performed via GET (image tags can trigger those), APIs that accept application/x-www-form-urlencoded when the app only ever sends JSON, and a global CSRF middleware with an ever-growing exemption list “for the mobile app”.

The fix

Two defenses, ideally layered. First, anti-CSRF tokens: the server embeds an unpredictable per-session value in each form or header and rejects state-changing requests that lack it, since a foreign page cannot read the token. Most frameworks (Django, Rails, Laravel, Spring) ship this; the audit question is whether it is enabled everywhere. Second, the SameSite cookie attribute (Lax or Strict) tells browsers not to attach the session cookie to cross-site requests at all. Requiring a custom header on JSON APIs adds a further check, because cross-origin pages cannot set one without passing CORS.

Why it matters in a code audit

CSRF protection tends to erode rather than be absent: it launched enabled, then endpoint by endpoint got exempted to unblock an integration. Auditors therefore enumerate every state-changing route and check each one, paying attention to cookie flags and CORS configuration together, since the pieces interact. Note that XSS on the same site defeats token defenses entirely, so the two are assessed as a pair, and endpoints missing per-object access checks often also exhibit IDOR. See the top vulnerabilities code audits catch for the broader list.

A free code audit checks whether your state-changing endpoints are actually covered, not just your framework defaults.