CSRF (Cross-Site Request Forgery): What It Is and How to Prevent It

Cross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user's browser into making unintended requests to a web application. The attacker crafts a malicious page that, when visited by the victim, submits a request to the target site using the victim's existing session cookies.

Mapped to CWE-352 and historically part of the OWASP Top 10, CSRF exploits the browser's automatic inclusion of cookies with every request to a domain. If a user is logged into their bank and visits a malicious page, that page can submit a transfer request to the bank—and the bank sees it as a legitimate authenticated request.

CSRF targets state-changing actions: money transfers, email address changes, password updates, and account deletions. It cannot steal data directly, but the consequences of unauthorized actions can be severe.

A CSRF attack requires three conditions:

• The victim is authenticated to the target application (has a valid session cookie)
• The target application relies solely on cookies for session identification
• There are no unpredictable parameters in the request that the attacker cannot determine

The attacker creates a page containing a hidden form or image tag that submits a request:

<!-- Hidden form that auto-submits -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker-account" />
  <input type="hidden" name="amount" value="10000" />
</form>
<script>document.forms[0].submit();</script>

When the victim visits this page, the browser automatically includes the bank's session cookie with the POST request. The bank's server sees a valid session and processes the transfer.

Defense Mechanisms

CSRF tokens: A unique, unpredictable value generated per session or request, included as a hidden form field. The server validates the token before processing. Attackers cannot read the token from another origin due to same-origin policy.

SameSite cookies: The SameSite=Lax or SameSite=Strict cookie attribute prevents browsers from sending cookies with cross-site requests, neutralizing CSRF at the browser level.

• Netflix (2006): CSRF vulnerability allowed attackers to change user account details, add DVDs to queues, and modify shipping addresses by tricking users into visiting a malicious page.
• Gmail (2007): A CSRF attack could modify email filters, forwarding all incoming mail to an attacker-controlled address without the victim's knowledge.
• ING Direct (2008): CSRF allowed attackers to transfer funds from authenticated user accounts.

While modern browsers' default SameSite=Lax cookie behavior has reduced CSRF risk, applications that explicitly set SameSite=None or use older cookie configurations remain vulnerable.

CodeSlick identifies missing CSRF protections in web application code across JavaScript, TypeScript, and Python frameworks:

• Missing CSRF token validation in form-handling routes
• Cookie configurations without SameSite attributes
• Framework CSRF middleware that has been disabled or misconfigured

Findings are mapped to CWE-352 with OWASP classification. CodeSlick's AI-powered fixes suggest framework-appropriate CSRF protection patterns for Express, Django, Flask, and Spring applications.