Build fluency in the vocabulary of the attributes that protect a session cookie from theft.
0 / 5 completed
1 / 5
At standup, a dev mentions setting a session cookie with an attribute that prevents any client-side JavaScript from ever reading its value, even through a successful cross-site scripting injection. What is this attribute called?
The HttpOnly attribute prevents any client-side JavaScript from reading a cookie's value, even if an attacker manages to inject a script through an XSS vulnerability elsewhere on the page, since the browser simply never exposes an HttpOnly cookie to script-level access at all. The Secure attribute is a related but distinct protection, restricting the cookie to being sent only over an HTTPS connection rather than controlling JavaScript readability. This JavaScript-inaccessibility is exactly what limits the damage an XSS vulnerability can do to a session cookie protected this way, since stealing the cookie's value through injected script becomes impossible.
2 / 5
During a design review, the team sets a cookie's SameSite attribute to Strict, so the browser never attaches that cookie to a request originating from a different site, even one following a link the user clicked. Which capability does this attribute provide?
Setting SameSite to Strict provides significantly narrowing the window for a cross-site request forgery attack, since the browser withholds the cookie entirely from a request originating from a different site, meaning an attacker's forged cross-site request won't even have the victim's session cookie attached to piggyback on. Ensuring the cookie is always attached regardless of origin is exactly the vulnerable default behavior SameSite is designed to restrict. This attribute is a strong complementary layer of CSRF defense, though it's typically used alongside, not instead of, a dedicated CSRF token for full protection.
3 / 5
In a code review, a dev notices a session cookie is set with neither the Secure nor the HttpOnly attribute, and the site is served over both HTTP and HTTPS. What does this represent?
This is a session cookie exposed to interception over an unencrypted connection and readable by any client-side script, doubling its risk of theft, since without Secure the cookie can be sent over a plain HTTP connection where it's visible to anyone intercepting the traffic, and without HttpOnly an XSS vulnerability elsewhere on the page can read and exfiltrate it directly. A CSRF token is an unrelated defense against forged requests, not about cookie transmission or script accessibility. This is exactly why both attributes are considered baseline requirements for any cookie carrying session or authentication data.
4 / 5
An incident report shows an attacker on the same coffee-shop Wi-Fi network intercepted a user's session cookie and hijacked their account, because the cookie lacked the Secure attribute and was transmitted over an unencrypted HTTP connection the site still served alongside HTTPS. What practice would prevent this?
Setting the Secure attribute on the session cookie, combined with redirecting all HTTP traffic to HTTPS, ensures the cookie is never transmitted over a connection an attacker on the same network could passively intercept, closing off exactly the interception vector described in this incident. Continuing to serve the site over both protocols with the cookie lacking Secure is precisely what let the attacker capture it over the coffee-shop Wi-Fi. This Secure-plus-HTTPS-redirect combination is a baseline requirement for protecting any session cookie from network-level interception.
5 / 5
During a PR review, a teammate asks why the team sets HttpOnly, Secure, and SameSite on every session cookie instead of relying on just one of these attributes, given that any single one already provides some protection. What is the reasoning?
Each attribute defends against a genuinely different attack vector: HttpOnly blocks a script from reading the cookie even after a successful XSS injection, Secure prevents the cookie from ever crossing an unencrypted connection where it could be intercepted, and SameSite withholds the cookie from cross-site requests to blunt CSRF. Relying on only one leaves the attack vectors the other two were specifically designed to close completely open, since none of these attributes substitutes for what the others actually protect against. The tradeoff is minimal, since setting all three together is a small, one-time configuration change relative to the layered protection it provides for any cookie carrying session or authentication state.