Cross-site request forgery (CSRF) tricks a signed-in user’s browser into sending a request that performs an action the user did not intend. A malicious link can arrive with the user’s cookies attached, so the site treats it as that user’s request. The result can range from unwanted social-media posts to account deletion, payments, or disclosure of personal information. section 2.14 section 6.8
The central risk is confusing a request’s authentication with its intent. Browsers commonly send cookies automatically, while a user may only have clicked a disguised link or followed a redirect. CSRF is therefore an attack on users through the browser rather than a direct attempt to access the server. section 2.14 section 6.0
A comment form that becomes a worm
A comment form using GET can put the comment text in its URL. An attacker can hide that URL behind an innocent-looking link; each victim who follows it posts the attacker’s comment, which can prompt more people to follow the same link. This self-replicating comment is a worm. section 6.8
<form action="/comment/new" method="get">
<textarea name="comment"
placeholder="What's going on?"></textarea>
<button type="submit">Submit</button>
</form>
This form uses GET for an action that creates a comment, making its effect reproducible through a crafted URL. section 6.8
Reduce CSRF exposure by making request semantics and cookie rules work together:
- Keep GET requests free of side effects. State-changing actions should use methods such as POST, PUT, or DELETE rather than GET. section 2.14 section 6.18
- Use antiforgery tokens for CSRF protection. section 6.18
- Set SameSite on sensitive cookies. SameSite=Strict prevents cookies on cross-site requests; SameSite=Lax allows them on cross-site GET requests but not POST, PUT, or DELETE. section 2.14
- Explicitly send the SameSite header even though modern browsers default unspecified cookies to Lax, because older browsers may not. section 2.14
