CSRF

SecurityMidsecurity

The Question

What is CSRF and how do you prevent it?

What a Strong Answer Covers

• browser sends cookies automatically
• "CSRF token
• "SameSite cookie

Senior-Level Answer

Cross-Site Request Forgery (CSRF) is an attack where a malicious site causes an authenticated user's browser to send a forged request to a target site. Because browsers automatically attach cookies to same-origin requests, the target server cannot distinguish a legitimate request from a forged one based on cookies alone.

The attack works as follows: a victim is logged into bank.com, which sets a session cookie. The attacker lures them to evil.com, which contains an image tag or hidden form that fires a POST to bank.com/transfer. The browser sends the request with the victim's cookie, and the server processes it as legitimate.

Primary defenses:

**Synchronizer Token Pattern (Anti-CSRF Token):** The server generates a unique, unpredictable token per session (or per form), embeds it in the HTML form or JavaScript-accessible meta tag, and validates it on every state-changing request. The attacker cannot read the token due to the same-origin policy, so they cannot forge a valid request. This is the gold standard. Frameworks like Django, Rails, and Spring include this by default.

**SameSite Cookie Attribute:** Setting `SameSite=Strict` or `SameSite=Lax` on session cookies instructs the browser not to send them on cross-site requests. `Strict` blocks all cross-site sends; `Lax` blocks POST but allows safe top-level navigations. This is now the browser default for cookies without an explicit attribute in modern browsers. It is a strong second layer but not a complete replacement for token-based protection in all legacy environments.

**Double Submit Cookie:** The server sets a random value as both a cookie and requires it as a request parameter. Since the attacker cannot read cookies cross-origin, they cannot replicate the value in the parameter. Useful for stateless architectures.

**Origin / Referer Header Validation:** Check that the `Origin` or `Referer` header matches the expected domain. Less reliable as headers can be absent (Referer is blocked by some privacy settings), so this should be a secondary check.

**Custom Request Header:** APIs that require a custom header (e.g., `X-Requested-With: XMLHttpRequest`) exploit the fact that simple cross-site requests cannot set arbitrary headers. SPAs using JSON APIs with custom headers are naturally protected. However, this only works when the server enforces the header check.

In modern stack terms: Django's `CsrfViewMiddleware` handles token injection and validation. For REST APIs consumed by SPAs, `SameSite=Lax` plus CORS restrictions usually suffices. Always combine layers.

What Separates a 2/3 from a 3/3

Common Mistakes

• Conflating CSRF with XSS — they are distinct attack classes with different threat models
• Claiming HTTPS alone prevents CSRF — it does not; the attack works over HTTPS
• Overlooking that GET requests should never cause side effects — CSRF exploits safe-method assumptions too
• Treating SameSite=Lax as a complete solution without noting legacy browser gaps

Follow-Up Questions

• Why doesn't HTTPS prevent CSRF? — HTTPS encrypts the channel but the browser still sends cookies automatically — encryption doesn't change cookie-attachment behavior.
• How does the double-submit cookie pattern work, and what is its weakness? — Weakness: if an attacker can write a cookie (via subdomain XSS), they can forge the match.
• How would you protect a stateless REST API (JWT in localStorage) from CSRF? — localStorage is not sent automatically — the attacker can't access it cross-origin, so CSRF is a non-issue there. Shift the discussion to XSS risk.
• What is the difference between CSRF and clickjacking? — Clickjacking uses iframes to trick users into clicking UI elements; CSRF forges requests. Different mitigations: X-Frame-Options for clickjacking.

Related Questions

• Authentication vs Authorization
• JWT — 3 Parts, Signing, Revocation
• SQL Injection
• XSS
• OAuth 2.0 — Authorization Code Flow