What Is Cross-Site Request Forgery (CSRF)?

TL;DR: Cross-site request forgery (CSRF, also written as XSRF) is an attack that tricks an authenticated user's browser into sending unauthorized requests to a web application on their behalf. The attacker doesn't need to steal credentials — they exploit the fact that the victim's browser automatically includes session cookies with every request, making a forged request appear legitimate. The result is that the attacker can perform actions in the application as if they were the victim: changing a password, transferring funds, updating account settings, or any other state-changing operation the victim is authorized to perform.

How a CSRF Attack Works

CSRF works because browsers automatically attach cookies to requests made to a domain, regardless of which website initiated the request. If a user is logged in to their banking application and visits a malicious page, that page can cause the user's browser to silently send a request to the banking application, complete with the user's valid session cookie.

A concrete example:

<!-- Attacker's malicious page -->
<!-- Automatically submits when the page loads, no user interaction needed -->
<form id="csrf-attack" action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="10000">
  <input type="hidden" name="to_account" value="attacker-account-number">
</form>

<script>
  document.getElementById('csrf-attack').submit();
</script>

When a logged-in bank user visits the attacker's page, the form submits automatically. The browser includes the user's session cookie with the POST request to bank.com. The bank receives a valid authenticated request for a $10,000 transfer and processes it, because it cannot distinguish this forged request from a legitimate one initiated by the user.

The attack chain step by step:

1. The victim logs in to a target application (bank, email, admin panel) and their browser stores a session cookie.
2. The attacker tricks the victim into visiting a malicious page — through a phishing link, a compromised ad, or an injected link on another site.
3. The malicious page automatically triggers a request to the target application using JavaScript, an auto-submitting form, or an image tag.
4. The victim's browser attaches the session cookie to the request and sends it to the target application.
5. The target application receives a valid authenticated request and processes it — without knowing the user didn't initiate it.

CSRF attacks only affect state-changing operations — actions that modify data or trigger side effects (transfers, password changes, email updates, account deletions). Read-only requests that return data don't cause direct harm through CSRF, since the attacker can't read the response.

CSRF vs. XSS

CSRF and XSS (cross-site scripting) are frequently confused because both are "cross-site" attacks against web applications, but they exploit fundamentally different trust relationships:

The key distinction: CSRF forges a request from the user to the server. XSS injects malicious code into the application that runs in the user's browser. An XSS vulnerability can actually be used to bypass CSRF protections if an attacker can execute JavaScript in the application's context, they can read CSRF tokens and include them in forged requests.

How to Prevent CSRF

Synchronizer Token Pattern (CSRF tokens). The most widely used defense. The server generates a secret, unpredictable token and includes it as a hidden field in every form or as a custom HTTP header for API requests. When a form is submitted, the server validates that the token matches the one issued to the session. An attacker's forged request from a different origin cannot include the correct token it's not accessible to cross-origin scripts.

<!-- Server-side generated CSRF token in a form -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="8f3a2b9c4d1e7f6a5b8c2d0e3f1a4b7c">
  <input type="text" name="amount">
  <button type="submit">Transfer</button>
</form>

The server validates the token on every state-changing request. Requests without a valid matching token are rejected.

SameSite cookie attribute. Setting the SameSite attribute on session cookies instructs the browser not to send the cookie with cross-site requests. SameSite=Strict prevents cookies from being sent with any cross-site request. SameSite=Lax (the browser default in modern browsers) prevents cookies on cross-site POST requests but allows them for top-level navigations (links). SameSite is now the most effective first-line defense in modern browsers, but relying on it alone isn't sufficient for applications that need broad compatibility.

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

Double Submit Cookie. An alternative token approach that doesn't require server-side token storage the server sends a random token as both a cookie and a request parameter, and validates that both values match. Cross-origin requests can't read cookies to forge the matching parameter.

Custom request headers. API endpoints can require a custom HTTP header (e.g., X-Requested-With: XMLHttpRequest) that browsers enforce the Same-Origin Policy on. A cross-origin form submission or image tag cannot include custom headers only JavaScript can, and JavaScript is subject to CORS restrictions for cross-origin requests.

Verify the Origin and Referer headers. Checking that requests originate from the expected domain provides a secondary layer of validation, though both headers can be absent in some configurations and shouldn't be relied upon as a sole defense.

How to Test for CSRF

CSRF testing follows the OWASP testing methodology and centers on verifying whether state-changing operations can be triggered without a valid, server-validated token:

1. Identify state-changing endpoints. Map all POST, PUT, PATCH, and DELETE requests in the application — these are the candidates for CSRF testing.
2. Intercept and inspect requests. Using a proxy tool (Burp Suite), capture authenticated requests to state-changing endpoints and examine whether they include a CSRF token or custom header.
3. Test token absence. Remove the CSRF token from a captured request and replay it. If the request succeeds, the endpoint lacks token validation.
4. Test token reuse. Check whether a token from one session is accepted in another, or whether used tokens are invalidated.
5. Build a proof of concept. Construct an auto-submitting HTML form that replays the forged request and confirm it executes the action cross-origin.
6. Check SameSite enforcement. Verify whether session cookies have the SameSite attribute set, and whether the application depends on it as its primary defense.

In bug bounty contexts, a CSRF proof of concept is the minimum expected evidence for a valid report — a demonstration that the forged request actually triggers the intended action on the target application, not just that a token is absent.

Conclusion

CSRF is one of the more counterintuitive vulnerability classes the attack doesn't require stealing credentials, exploiting complex logic, or running code on the target server. It exploits something browsers do by design: attach session cookies to every matching request. The defenses are well understood and effective when correctly implemented, but they require consistent application across every state-changing endpoint a gap any inconsistency creates. In bug bounty programs, CSRF findings in sensitive account or financial functions remain consistently high-value precisely because the impact of a forged request in the right place can be severe.