Build fluency in the vocabulary of a forged cross-site request riding on an automatically attached cookie.
0 / 5 completed
1 / 5
At standup, a dev mentions an attacker's page silently submitting a form to the victim's bank while the victim is still logged in, relying on the browser automatically attaching the victim's session cookie to that cross-site request. What is this attack called?
Cross-site request forgery, or CSRF, has an attacker's page silently submit a form, or fire an equivalent request, to a victim's logged-in site, relying entirely on the browser automatically attaching the victim's session cookie to that request even though it originated from a completely different, malicious page. Cross-site scripting is a related but distinct attack that injects and executes a script in the victim's browser, rather than merely forging a request using their existing session. This reliance on the browser's automatic cookie attachment, regardless of which page initiated the request, is exactly the gap CSRF exploits.
2 / 5
During a design review, the team requires every state-changing form to include a unique, unpredictable token issued by the server and verified on submission, rejecting any request missing or mismatching it. Which capability does this token provide?
A CSRF token confirms the request actually originated from the site's own page, since an attacker's forged cross-site request has no way to read or predict the correct token value, even though the browser will still automatically attach the victim's session cookie. Confirming only that a valid session cookie is present is exactly the gap CSRF exploits, since that cookie gets attached automatically regardless of which page initiated the request. This unique, server-verified token is what lets the server distinguish a genuine same-site form submission from a forged cross-site one.
3 / 5
In a code review, a dev notices a state-changing endpoint, like a funds transfer, only checks for a valid session cookie and performs no CSRF token verification at all. What does this represent?
This is a CSRF vulnerability, since an attacker's page can trigger this exact same request, and the victim's browser will automatically attach their valid session cookie, with nothing else standing in the way because no token is required or checked. A parameterized query is an unrelated defense from the SQL injection domain, not CSRF. This is exactly why any state-changing endpoint, one that transfers funds, changes a password, or performs some other meaningful side effect, needs CSRF token verification in addition to session cookie validation.
4 / 5
An incident report shows victims' funds were transferred without their knowledge after visiting an unrelated malicious page, because the bank's transfer endpoint relied solely on the session cookie the browser attached automatically, with no CSRF token check in place. What practice would prevent this?
Requiring a unique, server-verified CSRF token on every state-changing request ensures a forged cross-site request, one that has no way to know or include that token, gets rejected even though the victim's session cookie is still attached automatically. Continuing to rely solely on the session cookie with no token check is exactly what allowed the unauthorized fund transfers described in this incident. This token requirement is a standard, well-established defense for any endpoint that changes state based on an authenticated user's session.
5 / 5
During a PR review, a teammate asks why the team adds an explicit CSRF token check on top of already requiring a valid session cookie for every state-changing request. What is the reasoning?
A session cookie gets attached by the browser automatically to any request sent to that domain, regardless of which page actually initiated the request, so its mere presence proves the user is logged in but says nothing about whether the request itself was genuinely intentional. A CSRF token, by contrast, is only known to and readable by the site's own legitimate page, so its presence and correctness specifically proves the request originated from that trusted page rather than an attacker's forgery. The tradeoff is the added implementation overhead of generating, embedding, and verifying a token on every state-changing form, which is a small cost relative to the class of attack it closes off entirely.