A funds-transfer endpoint accepts a simple cookie-authenticated POST with no token. What's missing?
Short answer
If the browser automatically attaches the session cookie, a malicious page can trigger the transfer on the victim's behalf — cross-site request forgery (CSRF). Defend state-changing requests with anti-CSRF tokens and SameSite cookies, and check the Origin/Referer header. Cookies prove identity but not intent, a login CAPTCHA does nothing for an already-authenticated action, and HTTPS protects transport confidentiality, not request forgery.
A funds-transfer endpoint that trusts nothing but the session cookie is a textbook cross-site request forgery (CSRF) target. The browser will helpfully attach that cookie to any request to your domain — including one fired by a completely unrelated, attacker-controlled page the victim happens to visit.
How the attack works
The attacker hosts a page with an auto-submitting form (or an image/fetch) that POSTs to your transfer endpoint with their chosen recipient and amount. When a logged-in victim opens that page, their browser sends the request with the valid session cookie, and your server — seeing a properly authenticated session — executes the transfer. The victim never clicked "send money." The cookie proved who they are, but never that they intended this action.
The correct fix
State-changing requests need proof of intent that an off-site page cannot supply:
- Anti-CSRF tokens (the synchronizer-token pattern): a per-session, unpredictable value embedded in the form and validated server-side. A cross-site attacker can't read it due to the same-origin policy.
- SameSite cookies (
LaxorStrict) so the session cookie isn't sent on cross-site requests in the first place — a strong, modern baseline. - Verify the Origin/Referer header on sensitive requests as defense in depth.
Why the distractors are wrong
- "Nothing — cookies authenticate the user" confuses authentication with authorization of this specific request. That's the exact gap CSRF exploits.
- A login-page CAPTCHA guards the login event; it does nothing once the user is already authenticated and the forged request rides their existing session.
- HTTPS protects data in transit from eavesdropping and tampering — it does not stop a malicious site from causing the victim's browser to send a perfectly valid, encrypted, forged request.
The interviewer wants to see that you separate identity from intent and reach for tokens and SameSite, not transport security.
Likely follow-ups
- How does SameSite=Lax differ from Strict, and where does each leave a gap?
- Why is the synchronizer-token pattern more robust than checking Referer alone?
- How would CSRF defenses differ for a cookie-based session versus a Bearer token API?