Overview
This lesson consolidates CSRF defenses into a layered strategy — anti-CSRF tokens, SameSite cookies, correct method usage, and supporting checks — and clarifies how they fit together. It is the CSRF defense checklist.
Learning objectives
- Summarize the layered CSRF defenses.
- Explain how the defenses complement each other.
- Apply a CSRF prevention checklist.
Core concept
CSRF is prevented with layered controls:
- Anti-CSRF tokens — require an unpredictable, session-bound token on state-changing requests (the classic, robust defense).
- SameSite cookies — set
SameSite=Lax/Strictso session cookies are not sent on cross-site state-changing requests. - Proper HTTP methods — use non-GET methods for state changes (never perform sensitive actions via GET).
- Supporting checks — for sensitive operations, re-authentication or confirmation adds assurance; framework CSRF protection should be enabled.
How it works
The layers reinforce one another: SameSite stops the cookie from riding cross-site requests in most cases, while anti-CSRF tokens ensure that even a request that does reach the server without proper cross-site restriction lacks the secret proof of intent. Correct methods ensure sensitive actions are not trivially forgeable via links/images and that protections apply cleanly. Together they close CSRF from multiple angles, so a gap in one (e.g. a SameSite exception) is covered by another (the token). Using the framework's built-in protection is strongly preferred over custom implementations.
Practical example
A well-defended app: session cookies are HttpOnly; Secure; SameSite=Lax; every state-changing endpoint (POST/PUT/DELETE) requires a valid anti-CSRF token validated server-side; sensitive actions (like changing email or password) additionally require re-entering the password. An attacker's forged cross-site request is blocked by SameSite (no cookie), and even in an edge case where a request slipped through, it would lack the token — and sensitive actions would still require the password. Multiple independent layers make CSRF impractical.
Cybersecurity relevance
A layered CSRF defense is the practical, recommended approach and is largely built into modern frameworks. The consistent guidance: enable framework CSRF protection (tokens), set appropriate SameSite values, use correct methods, and add re-authentication for the most sensitive actions. Assessments verify tokens are required and validated, SameSite is set, and state changes are not exposed via GET. This checklist synthesizes the module and reflects how CSRF is defended in real applications.
Common mistakes
- Relying on a single control (only SameSite, or only tokens) instead of layering them.
- Disabling or not enabling framework CSRF protection, then hand-rolling it incompletely.
- Leaving a state-changing endpoint on GET or without a required token.
Key takeaways
- Layer CSRF defenses: anti-CSRF tokens (required, validated per state-changing request), SameSite cookies, proper non-GET methods, and re-authentication for sensitive actions.
- The layers complement each other, so a gap in one (e.g. a SameSite edge case) is covered by another (the token).
- Enable the framework's built-in CSRF protection and verify tokens, SameSite, and method usage — the practical CSRF prevention checklist.
Check your understanding
- How do anti-CSRF tokens and SameSite cookies complement each other as layered defenses?
- Besides tokens and SameSite, name two additional measures that strengthen CSRF defense.