What Is CSRF? Cross-Site Request Forgery Explained

Cross-Site Request Forgery (CSRF) is an attack that tricks a user's browser into sending an authenticated HTTP request to a website without the user's knowledge. Because the browser automatically includes session cookies with every request to a site, the target application cannot distinguish a legitimate user action from a forged one.

A successful CSRF attack can change account settings, transfer money, post content, or perform any action the victim is authorised to do — silently, in the background, while they browse a malicious website.

How CSRF Works

1. Alice is logged into her bank at bank.example.com. Her session-how-the-world-wide-web-works) cookie is stored in the browser.
2. Without logging out, Alice visits a malicious site controlled by an attacker.
3. The malicious page contains a hidden form:

<form action="https://bank.example.com/transfer" method="POST" id="csrf">
  <input type="hidden" name="to" value="attacker-account" />
  <input type="hidden" name="amount" value="5000" />
</form>

1. The browser automatically submits the form to the bank — including Alice's session-how-the-world-wide-web-works) cookie.
2. The bank sees a valid authenticated request and processes the transfer.

Alice never clicked anything. The attack exploited the browser's default behaviour of attaching cookies to every request.

CSRF vs XSS

| | CSRF | XSS | |---|---|---| | What it does | Forges a request using the victim's session-how-the-world-wide-web-works) | Injects and runs code in the victim's browser | | Victim must | Visit a page with the CSRF payload | Load a page that reflects/stores the attacker's script | | Executes | On the target server (using victim's credentials) | In the victim's browser | | Defence | CSRF tokens, SameSite cookies | output encoding-cross-site-scripting-explained), CSP |

What Actions Are Vulnerable?

CSRF affects state-changing requests — actions that modify data or perform transactions. Examples:

• Changing email address or password
• Deleting an account
• Making a purchase or transfer
• Posting a message or comment
• Adding an administrator account
• Changing privacy or security settings

Read-only requests (fetching data) are generally not useful CSRF targets because the attacker cannot read the response from a cross-origin page (blocked by the Same-Origin Policy).

How to Prevent CSRF

1. CSRF Tokens (Synchroniser Token Pattern)

The most widely used defence. The server generates a random, secret token and embeds it in every form. When the form is submitted, the server validates that the token matches. An attacker cannot forge the token because they cannot read the victim's page content (blocked by the Same-Origin Policy).

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="a8f3d2b19e7c4f6a" />
  <input type="text" name="amount" />
  <button type="submit">Transfer</button>
</form>

Most web frameworks generate and validate CSRF tokens automatically (Django, Rails, Laravel, Spring Security).

2. SameSite Cookie Attribute

The SameSite attribute tells browsers when to include cookies in cross-site requests:

| Value | Behaviour | |---|---| | Strict | cookie-how-the-world-wide-web-works) only sent for same-site requests. Most secure; may break OAuth-explained) flows | | Lax | cookie-how-the-world-wide-web-works) sent on same-site requests and top-level navigation GET requests. Default in modern browsers | | None | cookie-how-the-world-wide-web-works) always sent (requires Secure flag). Used for legitimate third-party integrations |

Setting SameSite=Lax or SameSite=Strict on session-how-the-world-wide-web-works) cookies blocks most CSRF attacks without requiring additional token management.

Set-Cookie: sessionid=abc123; SameSite=Lax; Secure; HttpOnly

3. Double-Submit Cookie Pattern

An alternative to server-side token storage. The server sets a random value as both a cookie-how-the-world-wide-web-works) and expects it in a request parameter. Since attackers cannot read the cookie (blocked by Same-Origin Policy), they cannot replicate it in a forged request.

4. Check the Origin and Referer Headers

The server can validate that the request came from the same origin by inspecting the Origin or Referer HTTP headers. Not fully reliable on its own (headers can be absent or spoofed in some configurations) but useful as an additional check.

5. Use Custom Request Headers for APIs

Browsers enforce the Same-Origin Policy on custom HTTP headers. If your API requires a non-standard header (like X-Requested-With: XMLHttpRequest), a cross-origin form submission cannot include it — providing implicit CSRF protection for AJAX-based APIs.

Modern Browser Protections

Most modern browsers now default to SameSite=Lax for cookies that do not explicitly set the attribute. This significantly reduces CSRF risk for applications that have not yet implemented explicit protections — but explicit SameSite and CSRF token controls should still be in place.

Testing for CSRF

1. Identify state-changing endpoints (POST, PUT, DELETE requests)
2. Check whether the request includes a CSRF token
3. Remove or modify the token and resubmit — if it succeeds, the endpoint is vulnerable
4. Check whether the SameSite cookie-how-the-world-wide-web-works) attribute is set

Automated tools: Burp Suite (CSRF PoC generator), OWASP-web-application-attacks-explained) ZAP.

Key Takeaways

• CSRF tricks a victim's browser into sending a forged authenticated request to a trusted site
• It exploits the browser's automatic cookie-how-the-world-wide-web-works) behaviour, not a flaw in the victim's browser
• Affects state-changing actions; read-only operations are not useful CSRF targets
• Primary defences: CSRF tokens (synchroniser pattern) and SameSite=Lax/Strict cookies
• Most modern frameworks include built-in CSRF protection — ensure it is enabled