Cross-Site Request Forgery (CSRF)

Why it matters

A successful CSRF changes data or runs an action as the victim: a changed e-mail or password can lead to account takeover, and money or settings can move without consent. The user did nothing wrong and sees nothing, which makes it hard to detect after the fact.

These defects pass every functional test, because the normal journey works. They surface only in tests written for them, and those tests are cheap: a captured request, a test account and a tool to replay it. Catching a missing or unchecked token before release closes a route to account takeover that users cannot protect themselves against.

How a forged request works

A CSRF needs three things to line up. First, a relevant action that changes state, such as changing an e-mail, transferring money or deleting data. Second, session handling that rides on credentials the browser sends by itself, so the attacker's page does not need to know them. Third, request parameters the attacker can predict: if every value in the request is guessable, the page can build it in advance.

The attacker does not break into the session and never sees the response. A page the victim visits — an advert, a forum post, an e-mail with remote content — tells the victim's browser to issue the request to the target application. The browser, following its normal rules, attaches the cookies for that site. The server receives a well-formed, authenticated request and, unless it demands more than the cookie, carries it out. This is why a page on another site, which cannot read anything from the target, can still cause an action there.

• A hidden form that auto-submits a POST is the classic carrier; an <img> or a link can carry a GET.
• The attacker needs no XSS and no script on the target: CSRF rides the browser's own behaviour, which is what makes it different from the cross-site scripting in the previous lesson.
• Because the attacker cannot read the response, CSRF is about forcing an action, not stealing data — that distinction shapes every test.

The three defences: tokens, SameSite and Origin

The classic primary defence is an anti-CSRF token: an unpredictable value the server binds to the user's session and places in each page's forms. A genuine form sends it back; a cross-site page cannot read it, so it cannot include it. The synchronizer token pattern keeps the expected value server-side; the double-submit pattern sends it in both a cookie and the request and compares them, which needs no server state but should use a value the server signs and ties to the session, so an attacker who manages to plant a cookie still cannot make a matching pair. Either way the server must reject the request when the token is missing or wrong — a token that is present but never checked defends nothing.

SameSite on the session cookie is the second layer. Strict or Lax stops the browser from attaching the cookie to most requests that start on another site, which blocks the plain forged form. Treat it as defence in depth, not a replacement for tokens: Lax still sends the cookie on top-level GET navigations from another site, and defaults differ between browsers, which is why the lesson on cookies and sessions over HTTP expects the attribute to be set explicitly.

The third layer is the Origin header, with Referer as a fallback: on a state-changing request the server confirms the origin is its own. Browsers add Origin to cross-origin requests and a page cannot change it, so a mismatch is a strong reason to reject; the header can still be missing or null, so the server must also decide what happens then. The OWASP Cross-Site Request Forgery Prevention Cheat Sheet lists this check, like SameSite, as defence in depth. Current browsers also send Sec-Fetch-Site (for example cross-site), which OWASP accepts as a main check for modern browsers when Origin serves as the fallback. None of this is CORS, which governs what a page may read: a plain cross-site form post reaches the server whatever the CORS headers say, which is why the lesson on CORS said CORS is not a CSRF defence.

Try it: Cookie Analyzer

Worked example: testing a change-e-mail action

Take a sandbox application you own or have written permission to test. Sign in with a test account and capture the request that changes the account e-mail, with an intercepting proxy as in the lesson on intercepting proxies, or from the browser's developer tools. The captured request below carries a session cookie and a token.

Now replay it with one thing changed at a time, using the proxy's replay feature or by rebuilding it in the REST API Tester or as a cURL command, and watch the response and the stored e-mail. Each replay is a test case with a clear expected result. A replay tests what the server checks; it cannot show what a browser would send, which is why SameSite is checked separately on the Set-Cookie header.

• Remove X-CSRF-Token and replay: expect a rejection (for example 403) and the e-mail unchanged. If it succeeds, the action has no token check.
• Replace the token with a valid one from a second test account's session and replay: expect rejection. If it succeeds, the token is not tied to the session.
• Keep the valid token, change Origin to another site and replay: a rejection shows the server checks the origin as well; acceptance means the token is the only layer, which you record as an observation, not a failure.
• Paste the login Set-Cookie into the Cookie Analyzer and confirm the session cookie sets SameSite explicitly.
• Look for any action reachable by GET that changes state: that is a defect on its own, because even SameSite=Lax sends the cookie on a followed link.

POST /account/email HTTP/1.1
Host: app.example
Origin: https://app.example
Cookie: sid=9f8aUq0Zr8Ty2Nc6
X-CSRF-Token: 7bQ2mK9rLp4XwZ1
Content-Type: application/x-www-form-urlencoded

email=sara%40app.example

Try it: REST API Tester Try it: cURL Generator Try it: Request Header Inspector

A repeatable CSRF test for every release

Scale the worked example into a checklist. List every state-changing request the feature makes; for each, record whether a token is required, whether it is unpredictable and session-bound, whether the server checks it, and whether Origin or Referer are validated. The token must travel in the body or a header, never the query string, where it leaks through the Referer header, server logs and browser history.

Watch for checks that run only in the page's own JavaScript, which a forged request never passes through, tokens that are reflected but never verified, and GET endpoints that quietly change state. RFC 9110 defines GET as a safe method, one whose semantics are essentially read-only, so a state change behind GET is a defect even before CSRF is considered. Record the exact request, what you changed and the response, so a developer can reproduce the finding in one step.

Try it: HTTP Headers Parser

Frequently asked questions

References

• OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP FoundationCSRF defences: synchronizer tokens, SameSite cookies and origin checks.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)Cookie lifetime, scope, the Secure/HttpOnly/SameSite attributes and their security implications.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.