CSRF: How to Explain It in an Interview (2026)

Cross‑Site Request Forgery (CSRF) is a classic web security flaw that still shows up in interview conversations. The key is to explain it clearly, show you understand the underlying mechanism, discuss the practical trade‑offs of mitigations, and be ready for follow‑up questions that probe depth. Below is a structured way to cover every angle, plus a ready‑to‑use 60‑second spoken answer.

What CSRF Is in One Sentence

CSRF is an attack where a malicious site causes a victim’s browser, which is already authenticated to a target site, to send an unintended request that performs an action on the target site.

How the Attack Works

1. Victim logs in – The browser stores a session cookie or token for example.com.
2. Attacker lures the victim – The victim visits evil.com while still logged in to example.com.
3. Malicious request is forged – evil.com embeds a hidden form or image tag that points to a state‑changing endpoint on example.com (e.g., POST /transfer).
4. Browser sends the request – Because the cookie is automatically attached, example.com sees a legitimate authenticated request and executes the action.

The attack succeeds because browsers automatically include cookies (or other credentials) with any request to the same origin, regardless of where the request originated.

Concrete Example

Imagine an online banking portal bank.com that lets users transfer money via a POST to /transfer. After logging in, Alice’s browser holds a session cookie sid=abc123. While still logged in, she clicks a link in a phishing email that loads a hidden form on evil.com:

<form action="https://bank.com/transfer" method="POST" style="display:none;">
  <input name="amount" value="5000"/>
  <input name="to" value="attacker"/>
</form>
<script>document.forms[0].submit();</script>

The browser silently sends the POST with Alice’s sid cookie, causing the bank to move $5,000 to the attacker’s account. The bank never asked Alice for confirmation because the request looked like any other authenticated request.

Common Defensive Strategies and Their Trade‑offs

Each mitigation balances implementation effort, compatibility with existing flows, and the level of protection. In practice, a combination—SameSite cookies plus a synchronizer token—is common.

Typical Interview Follow‑up Questions

1. Why isn’t a simple referer check enough? The Referer header can be stripped or forged by the attacker, and some privacy settings suppress it, making it unreliable.
2. How does SameSite=Strict differ from Lax? Strict blocks all cross‑site requests, even top‑level navigation. Lax allows GET navigation (e.g., clicking a link) but blocks POST, PUT, DELETE, etc.
3. What’s the difference between CSRF and XSS? CSRF abuses the victim’s authenticated session without needing to inject script. XSS requires the attacker to run script in the victim’s browser.
4. Can a CSRF token be reused? Ideally no – tokens should be single‑use or tied to a session and expire after a short window. Reusing tokens weakens the guarantee of uniqueness.
5. How would you test for CSRF vulnerabilities? Use a proxy or browser extension to replay state‑changing requests without the token, observe if the server accepts them, and verify that SameSite or token checks reject the attempt.

60‑Second Spoken Answer (Template)

"Cross‑Site Request Forgery, or CSRF, is when an attacker tricks a logged‑in browser into sending a request to a trusted site without the user’s intent. The browser automatically attaches the session cookie, so the target sees a legitimate request and carries out the action. A classic example is a hidden form on a malicious site that POSTs to a banking endpoint, causing an unauthorized transfer. To defend against CSRF we usually set cookies with the SameSite attribute and also embed a random token in every state‑changing form – the server validates that token before processing. SameSite is easy to add but can break some cross‑origin flows; tokens are more robust but require extra handling. In an interview you might be asked why a referer check isn’t enough, how SameSite=Lax differs from Strict, or how you’d test for the flaw. Practicing the answer aloud with Call Assistant helps you stay concise and anchor the story to your own experience."

How to Practice This

1. Write the answer on paper – Draft the 60‑second version, then trim any filler until you hit the 45‑90 second range.
2. Record yourself – Use a phone recorder or Call Assistant’s practice mode to speak the answer, then listen for pacing and clarity.
3. Simulate follow‑ups – Have a friend ask the typical questions above, and answer them while keeping the conversation tied to a concrete project from your resume.

---

FAQ

• What exactly does the browser do that enables CSRF? The browser automatically includes cookies, HTTP authentication headers, and sometimes stored tokens with any request to the same origin, regardless of the page that initiated the request.
• Is SameSite=Strict enough on its own? It blocks most CSRF vectors, but it can interfere with legitimate cross‑origin workflows (e.g., OAuth redirects), so many teams combine it with a token strategy for safety.
• Can CSRF affect mobile apps? Yes, if the app uses a web view that shares the same cookie store as a browser, or if it relies on cookie‑based authentication for API calls.
• Why do some frameworks generate CSRF tokens automatically? Frameworks like Django or Rails embed tokens in forms and verify them on the server, reducing developer error and ensuring a consistent defense across the application.