What is CSRF?
Learn what CSRF is, how attackers forge requests using a valid session, and how CSRF tokens and SameSite cookies prevent it.
Expected Interview Answer
CSRF (Cross-Site Request Forgery) is an attack where a malicious site tricks a victim's browser into sending an authenticated request to another site the victim is logged into, performing an unwanted action using the victim's own credentials.
Because browsers automatically attach cookies to requests regardless of which page triggered them, a malicious page can embed a form or image tag pointing at a trusted site's endpoint, and the victim's browser will send that request with their valid session cookie attached. If the target site only checks for a valid cookie and does nothing else, it cannot tell the difference between a request the user actually intended and one forged by another page. Defenses include CSRF tokens (a unique value the server issues and the legitimate form must echo back, which an attacker cannot know), the SameSite cookie attribute (which stops cookies from being sent on cross-site requests), and checking the Origin/Referer header. Modern frameworks bake CSRF tokens into forms automatically, and SameSite=Lax/Strict cookies have become a strong default protection.
- Understanding CSRF explains why tokens exist in every form you build
- SameSite cookies now block most CSRF by default in modern browsers
- CSRF tokens are cheap to implement and highly effective
- Recognizing CSRF sharpens general state-changing-request security thinking
AI Mentor Explanation
CSRF is like someone slipping a forged team-sheet change under the captain's door, knowing the ground staff will act on any note bearing the captain's signature stamp without checking who actually wrote it. The captain never wrote that note, but because it carries the right stamp, the staff execute it anyway. That trusted-stamp-without-verifying-the-author trick is exactly how CSRF abuses a victim's valid session cookie to forge an action.
Step-by-Step Explanation
Step 1
Victim logs into a trusted site
Their browser stores a valid session cookie for that site.
Step 2
Victim visits a malicious page
The page contains a hidden form or auto-submitting request targeting the trusted site.
Step 3
Browser auto-attaches cookies
The forged request is sent with the victim's valid session cookie, without their knowledge.
Step 4
Server executes the action
Without a CSRF token or SameSite protection, the server cannot tell the request was forged and processes it.
What Interviewer Expects
- Clear explanation of why cookies alone are not proof of user intent
- Knowledge of CSRF tokens as the classic mitigation
- Awareness of SameSite cookie attribute as a modern defense
- Distinction between CSRF (forged request, valid session) and XSS (injected script)
Common Mistakes
- Confusing CSRF with XSS โ they are different attack classes with different fixes
- Believing HTTPS alone prevents CSRF (it does not โ encryption is unrelated)
- Forgetting that GET requests with side effects are just as vulnerable to CSRF
- Assuming CSRF tokens are unnecessary once SameSite cookies are set (defense in depth is still recommended)
Best Answer (HR Friendly)
โCSRF is a trick where a malicious website causes your browser to send a request to another site you are logged into, using your own session without your knowledge. For example, visiting a bad page could secretly submit a form to your bank using your logged-in cookies. Websites defend against this with things like CSRF tokens and a cookie setting called SameSite, which stops cookies from being sent on cross-site requests.โ
Code Example
const csrfToken = req.body._csrf
const sessionToken = req.session.csrfToken
if (!csrfToken || csrfToken !== sessionToken) {
return res.status(403).send("Invalid CSRF token")
}
// Only proceed with the state-changing action once the token matches
transferFunds(req.session.userId, req.body.amount)
// Cookie set with SameSite as an additional layer of defense
res.cookie("sessionId", sessionId, { sameSite: "strict", httpOnly: true })Follow-up Questions
- How does the SameSite cookie attribute help prevent CSRF?
- Why do CSRF tokens need to be unpredictable and tied to the session?
- How does CSRF differ from XSS in attack mechanism and defense?
- Are GET requests vulnerable to CSRF, and why should they avoid side effects?
MCQ Practice
1. What makes CSRF possible by default?
CSRF relies on the browser automatically sending stored cookies with any request to that domain, even from another site.
2. Which is a standard defense against CSRF?
A CSRF token that only the legitimate page knows and must echo back prevents forged cross-site requests from succeeding.
3. What does the SameSite=Strict cookie attribute do?
SameSite=Strict stops the browser from attaching that cookie to requests originating from a different site.
Flash Cards
What does CSRF stand for? โ Cross-Site Request Forgery.
What browser behavior enables CSRF? โ Automatically attaching cookies to requests regardless of which site triggered them.
Name two defenses against CSRF. โ CSRF tokens and the SameSite cookie attribute.
Is CSRF the same as XSS? โ No โ CSRF forges a request using a valid session; XSS injects malicious script into a page.