Cross-site request forgery (CSRF) is an attack that tricks a logged-in user’s browser into sending an unwanted request to a website, which the site then executes with the user’s privileges.
How CSRF works
Browsers automatically attach cookies to requests sent to a website, no matter which page started the request. Suppose you are logged in to your bank or router admin panel and visit a malicious page. That page can contain a hidden form or image that sends a request such as “change email address”, “transfer money” or “change DNS server” to the other site. The browser adds your session cookie, and if the site does not check where the request came from, it performs the action as if you had clicked the button yourself.
The weakness is catalogued as CWE-352. Unlike cross-site scripting, the attacker cannot read the response – the goal is to trigger a state-changing action. Exploit kits have used CSRF against home routers to silently change their DNS settings and redirect users to phishing sites.
Why CSRF matters
CSRF can change account email addresses and passwords (leading to account takeover), create admin users in content management systems, change device settings or make purchases. Combined with other bugs it becomes a step towards session hijacking or code execution. Admin interfaces of routers, NAS devices and WordPress plugins are frequent victims.
How to prevent CSRF
- Use anti-CSRF tokens: a random value tied to the session that must accompany every state-changing request.
- Set session cookies with the SameSite attribute (Lax or Strict); major browsers now default to Lax.
- Check the Origin or Referer header for sensitive requests.
- Require re-authentication for critical actions such as password or payment changes, and never change state with GET requests.
Like SQL injection and SSRF, CSRF is a classic web application flaw that framework defaults now largely prevent – if developers do not switch them off.
