Cross Site Request Forgery: Making Your Browser Act Against You

You are logged in to your bank in one browser tab. In another, you are half watching a video and scrolling through a page a friend linked you. The page looks like nothing special, a few cat photos, maybe a meme. But hidden inside it is a tiny instruction that, the moment the page loads, quietly tells your browser to send a request to your bank. Your browser, ever helpful, attaches your bank login to that request automatically, because that is simply what browsers do. The bank sees a properly authenticated instruction from you and carries it out. You scrolled past a cat. Your money moved.

That is Cross Site Request Forgery, usually written CSRF and often said out loud as "sea surf". It is a sneaky one because the victim's browser does all the work, using their real, logged in session, without them ever knowing. The attacker never steals a password. They never steal a cookie. They simply get your browser to make a request you did not mean to make, and let your existing login do the rest. This is how it works and how it is prevented.

The core idea: browsers send cookies automatically

To understand CSRF you only need to understand one habit of web browsers, and it is a habit built for convenience.

When you log in to a site, the site hands your browser a session cookie. A cookie is just a small piece of data the browser stores, and a session cookie is the one that says "this browser is signed in as this user". From that point on, the browser automatically attaches that cookie to every single request it sends to that site, no matter what caused the request. It does not ask why the request is happening or where it came from. If the request is going to bank.com, the bank.com cookie goes with it. Full stop.

That automatic attachment is what makes the web pleasant to use. You do not have to log in again for every click. But it is also the entire weakness. The browser attaches your credentials based purely on the destination, never on who or what actually triggered the request.

So if an attacker can get your browser to fire off a request to a site where you are already logged in, the browser will faithfully include your session cookie, and the site will treat the whole thing as a genuine action taken by you.

1. You are logged in to bank.com in one tab.
2. You visit the attacker's page in another tab.
3. That page silently triggers a request to bank.com.
4. Your browser attaches your bank.com cookie automatically.
5. bank.com sees a valid, authenticated request and acts on it.

Think of the session cookie like a hotel wristband that opens your room. The door does not care who is wearing the band or why they are standing there, it only checks the band. CSRF is a stranger arranging things so that your own hand, still wearing the band, presses against the reader.

What it looks like

Imagine a bank that processes a money transfer with a straightforward request: hit a particular address with an amount and a recipient. The attacker builds a page containing a hidden form that submits itself the instant the page loads, no click required.

A hidden form on evil.com posts to:
   bank.com/transfer   amount=5000   to=attacker
Your browser submits it with your bank cookie attached.

You saw a cat picture. Your browser quietly moved money. That is CSRF in one line: a forged request, riding on your existing authentication. The form did not need to know your password or read your cookie, and the attacker never saw either. They only needed to know the shape of the request the bank expects, and to get your logged in browser to send it.

Why the attacker cannot just read the reply

A natural question: if the browser sends the request with your cookie, does the attacker get to read the bank's response too? Usually not. Browsers enforce a rule that stops a page on evil.com from reading responses that come back from bank.com. That rule is why CSRF is mostly a "fire and forget" attack. The attacker cannot see the confirmation page, so classic CSRF is about causing an action (transfer money, change an email, delete an account) rather than stealing data back out. That still does plenty of harm, because the damaging action itself is what the attacker was after.

Stopping it

Every defence comes down to one question: can the server tell that a request genuinely came from its own pages, and not from somewhere else riding on your cookie? If the server can prove that, the forgery falls apart.

1. Anti CSRF tokens. The server generates a secret, unpredictable value, a token, and embeds it inside its own forms and pages. When a form is submitted, the server checks that the right token came back with it. The attacker's page, sitting on another domain, has no way to know this secret value (that same browser rule that stops cross site reading also stops them fishing it out), so a forged request arrives without the token and is rejected. This is the classic, robust fix and it works even where nothing else does.
2. SameSite cookies. A cookie can be marked SameSite, which instructs the browser not to attach it to requests that originate from other sites. Modern browsers now default session cookies to SameSite=Lax, which quietly blocks the most common form of CSRF for everyone, automatically. This has hugely reduced CSRF across the web. It is not a reason to skip tokens, though. Treat it as a strong default and use tokens for anything sensitive, so you are covered even in the edge cases where SameSite protection does not fully apply.
3. Check the Origin or Referer. Every cross site request carries a header naming the page it came from. The server can inspect that header and refuse any request that does not claim to come from its own domain. It is a useful supporting check, though it should back up tokens rather than stand alone, since headers can occasionally be missing.
4. Re authenticate for sensitive actions. For the truly critical steps, moving money, changing a password, deleting an account, ask the user to prove themselves again with their password or a second factor. A forged request cannot supply a fresh password or a one time code, so this closes the loop on the actions that matter most, even if every other layer somehow failed.

The takeaway

CSRF abuses one simple fact: browsers attach your cookies to requests automatically, even to requests triggered from another site entirely. That lets an attacker forge authenticated actions in your name without ever seeing your password or your cookie. The cure is to make legitimate requests provable. Anti CSRF tokens and SameSite cookies are the core defences, backed by origin checks and by re authentication for anything that really matters.

It is the mirror image of XSS: there, the site is tricked into running the attacker's code; here, the attacker borrows the site's trust in your browser. And like SQL injection, it thrives wherever a system trusts input it should have questioned. Once you can see that pattern, misplaced trust, you have the thread that ties all three together.