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.
What does the "Secure Cookie Attributes Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to secure cookie attributes vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.