# CSRF

> An attack that makes your browser send a request you never meant to send, as you.

- Level: Advanced
- Topics: Security
- URL: https://tidbit.legios.com.ar/csrf/
- In Spanish: [CSRF](https://tidbit.legios.com.ar/es/csrf/)

**CSRF** stands for cross-site request forgery. It abuses a habit of every web browser: when a page sends a request to a site, the browser attaches that site's cookies automatically, including the session cookie that says you are logged in. So if you are logged in to your bank in one tab and open a malicious page in another, that page can quietly submit a form to the bank, and the bank sees a perfectly normal request coming from you.

A classic example: the evil page contains a hidden form pointing at `https://bank.example/transfer` with the attacker's account as the destination, plus a line of JavaScript that submits it on load. You see nothing. The attacker never sees your password or your cookie, and cannot read the bank's answer; the attack works blind. That is the difference with cross-site scripting, where the attacker gets code running inside the site itself. CSRF only needs the target action to be predictable: change the email, change the password, make a payment.

The standard defenses are layered. Sites put a secret, random **CSRF token** in each form and reject requests that do not carry it, which a foreign page cannot guess. Cookies can be marked `SameSite=Lax` or `Strict` so the browser does not send them on requests started by other sites, and modern browsers already default to something close to that. Servers can also check the `Origin` header and ask for the password again before sensitive changes. Most web frameworks include CSRF protection out of the box; the bugs usually appear when someone switches it off or performs an important action with a simple `GET` link.

## An analogy

Someone slips a pre-filled, pre-signed withdrawal slip into the pile you are carrying to the bank teller. The teller knows your face and processes it, because it came from you.

## Keep in mind

- Exploits the browser sending cookies automatically to the site they belong to.
- The attacker triggers actions as you but cannot read the responses.
- Defenses: CSRF tokens, SameSite cookies, Origin checks, re-authentication.
- Never let a plain GET request change data.

## Go deeper

- [Cross-site request forgery on Wikipedia](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
- [CSRF (MDN Web Docs)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF)
- [CSRF Prevention Cheat Sheet (OWASP)](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

## Related terms

- [Web browser](https://tidbit.legios.com.ar/web-browser/): The app that fetches web pages from the internet and draws them on your screen.
- [Cookies](https://tidbit.legios.com.ar/cookies/): Small notes a website asks your browser to keep, so it can recognize you later.
- [JavaScript](https://tidbit.legios.com.ar/javascript/): The programming language that runs inside web pages and makes them interactive.
- [Cross-site scripting](https://tidbit.legios.com.ar/cross-site-scripting/): Sneaking code into a website so it runs in other visitors' browsers.
- [Server](https://tidbit.legios.com.ar/server/): A computer whose job is to answer requests from other computers, all day, every day.
- [Framework](https://tidbit.legios.com.ar/framework/): A ready-made skeleton for an app: it sets the structure and calls your code.
- [Bug](https://tidbit.legios.com.ar/bug/): A mistake in software that makes it behave differently from what was intended.