CSRF
An attack that makes your browser send a request you never meant to send, as you.
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.
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.