What Is CSRF - How Cross-Site Request Forgery Works and How to Prevent It

What Is CSRF (Cross-Site Request Forgery)

CSRF (Cross-Site Request Forgery) is an attack technique that causes a user's browser to send unintended requests to a web site where the user is already authenticated. The attacker prepares a trap web page or email, and the moment the victim views it, a malicious request is automatically sent from the victim's browser to the target site.

Because browsers automatically attach cookies to requests for the same domain, if the victim is logged in, the attacker's request is processed as authenticated. Operations that change state - such as password changes, money transfers, email address changes, and purchases - become targets of the attack.

How the Attack Works with Examples

A CSRF attack is executed in the following flow.

The victim logs into the target site (e.g., online banking), and a session cookie is stored in the browser
The victim views a trap page prepared by the attacker (via an email link, forum post, etc.)
HTML or JavaScript embedded in the trap page sends a request from the victim's browser to the target site
The browser automatically attaches the session cookie, so the target site processes it as a legitimate request

For example, if a transfer function works via a request like POST /transfer?to=attacker&amount=100000, the attacker only needs to embed an auto-submitting form in the trap page to execute a transfer from the victim's account.

While often confused with XSS, CSRF is fundamentally different in that it forges legitimate requests from the victim's browser rather than executing the attacker's script in the victim's browser.

Implementing Defenses

The core of CSRF defense is implementing mechanisms that verify whether a request is based on the legitimate user's intent.

CSRF Tokens

The server generates a random token when displaying a form and embeds it in a hidden field. When the form is submitted, the server verifies the token matches, rejecting forged requests from external sites. The token is unique per session, and the attacker cannot know the victim's token.

SameSite Cookie Attribute

Setting the SameSite attribute on cookies controls whether cookies are attached to cross-site requests.

SameSite=Strict: Does not attach cookies to any requests from external sites. Most secure, but login state is not maintained when accessing via external links
SameSite=Lax: Attaches cookies only to GET requests from top-level navigation (link clicks). Since cookies are not attached to POST requests, most CSRF attacks are prevented
SameSite=None: Attaches cookies to cross-site requests as well. Must be used with the Secure attribute

Other Countermeasures

Origin / Referer header verification: Confirm that the request origin is your own site. However, the Referer may not be sent due to privacy settings or proxies
Requiring custom headers: Require custom headers like X-Requested-With. Due to the browser's same-origin policy, adding custom headers to cross-site requests requires a CORS preflight, which prevents CSRF
Proper security header configuration: Strengthens the overall security posture

CSRF Protection in Modern Frameworks

Many modern web frameworks provide built-in CSRF protection.

Django: Automatically embeds tokens with the {% csrf_token %} template tag and verifies them via middleware
Ruby on Rails: Automatically generates and verifies CSRF tokens with protect_from_forgery
Spring Security: CSRF protection is enabled by default. Automatically inserts CsrfToken into forms
Next.js / SPA: For API routes, combine SameSite cookies with Origin header verification. Consider additional protection with a WAF

If you disable a framework's CSRF protection, verify that alternative countermeasures are reliably implemented. When excluding CSRF protection for API endpoints, the prerequisite is switching to Bearer Token authentication and not using cookie-based authentication.

To learn more about this topic, see HTTP Security Headers: 5 Essential Headers to Protect Your Website.

Common Misconceptions

CSRF cannot occur with GET requests: If state-changing operations (deletion, settings changes, etc.) are implemented via GET requests, they become CSRF targets. A GET request can be sent simply by setting a URL in an img tag's src attribute, so state changes should always be implemented with POST/PUT/DELETE.
Using HTTPS prevents CSRF: HTTPS provides communication encryption and tamper prevention but is unrelated to CSRF. CSRF sends legitimate requests from the legitimate user's browser, so the attack succeeds even when communication is encrypted.

CSRF (Cross-Site Request Forgery)