Cyber Security Quiz: Secure Session Management
10 questions · exam conditions
0:00
Secure Session ManagementQuestion 1 of 10

An application is hosted at app.example.com. A separate, less-trusted content platform is hosted at blog.example.com and permits users to publish active content. The application currently accepts a cookie named session that is scoped to the parent domain, example.com.

Which cookie configuration provides the strongest browser-enforced protection against a sibling subdomain planting or overriding the application's session cookie?

Use __Host-session with Secure, HttpOnly, Path=/, SameSite=Lax, and no Domain attribute.
Use session with Secure, HttpOnly, Path=/, SameSite=Lax, and Domain=example.com.
Use __Secure-session with Secure, HttpOnly, Path=/, SameSite=Strict, and Domain=example.com.
Use session with Secure, SameSite=Strict, Path=/, and Domain=app.example.com.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Secure Session Management

Practice Secure Session Management in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Secure Session Management, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An application is hosted at app.example.com. A separate, less-trusted content platform is hosted at blog.example.com and permits users to publish active content. The application currently accepts a cookie named session that is scoped to the parent domain, example.com.

Which cookie configuration provides the strongest browser-enforced protection against a sibling subdomain planting or overriding the application's session cookie?

  1. Use __Host-session with Secure, HttpOnly, Path=/, SameSite=Lax, and no Domain attribute. (correct answer)
  2. Use session with Secure, HttpOnly, Path=/, SameSite=Lax, and Domain=example.com.
  3. Use __Secure-session with Secure, HttpOnly, Path=/, SameSite=Strict, and Domain=example.com.
  4. Use session with Secure, SameSite=Strict, Path=/, and Domain=app.example.com.
Explanation: When a malicious sibling subdomain (like blog.example.com) can set or overwrite cookies, the threat is called a "cookie shadowing" or subdomain cookie injection attack. To defend against it, you need browser-enforced rules that prevent any subdomain from tampering with your application's cookie — and the strongest tool available is the __Host- cookie prefix. The __Host- prefix is the key to why A is correct. Browsers enforce three strict rules on any cookie named with __Host-: it must have the Secure flag, it must have Path=/, and critically, it must have no Domain attribute. That last rule is what defeats the attack — without a Domain attribute, the cookie is bound exclusively to the exact host that set it (app.example.com). No sibling subdomain can plant or override it, because any such attempt would either fail validation or scope to a different host entirely. Adding HttpOnly blocks JavaScript access, and SameSite=Lax provides CSRF mitigation. B sets Domain=example.com, which deliberately shares the cookie across all subdomains — the exact vulnerability the question asks you to close. A hostile blog.example.com can freely overwrite it. C uses the __Secure- prefix, which only requires the Secure flag. It still allows a Domain attribute, so sibling subdomain injection remains possible. The prefix is weaker than __Host-. D lacks the __Host- prefix entirely. Even though Domain=app.example.com seems restrictive, browsers don't prevent a subdomain from setting cookies scoped to a parent, so this provides weaker guarantees. Your study tip: memorize the three mandatory requirements of __Host- — Secure, Path=/, and no Domain. Any answer that includes a Domain attribute alongside __Host- is automatically invalid and wrong.

Question 2

An API uses signed access tokens that remain valid for 30 minutes and refresh tokens that remain valid for seven days. When a user selects Log out, the browser deletes both tokens, but the server records no logout state. A copied access token continues to work until it expires.

Which design most directly provides prompt logout for the affected session without invalidating every user's tokens?

  1. Record the session or token identifier as revoked and check that status on protected requests. (correct answer)
  2. Reduce the access-token lifetime while continuing to keep logout entirely client-side.
  3. Rotate the global signing key whenever any user logs out of the application.
  4. Delete the browser tokens and rely on the access token's signed expiration time.
Explanation: When a question asks about session revocation, the core tension is between stateless token design (fast, scalable) and the need for immediate invalidation (security). The passage describes a purely client-side logout — the server has no memory of who logged out, so stolen tokens remain valid until expiration. The most direct fix is A: recording the session or token identifier as revoked in a server-side blocklist (or denylist), then checking that list on every protected request. When a user logs out, their specific token ID gets flagged immediately. Even if an attacker holds a copied token, the server rejects it the moment it checks the revocation store. This surgically targets only that session — other users are completely unaffected. B is a partial mitigation, not a real solution. Shorter-lived tokens reduce the window of exposure but never close it entirely — a stolen token still works until it expires. This also doesn't constitute "prompt" logout. C is a catastrophic overreaction. Rotating the global signing key invalidates every active token for every user, causing mass logouts across the entire application. The question explicitly asks you to avoid disrupting other users' sessions. D describes exactly the broken design already in the passage. Deleting browser tokens and trusting expiration is the status quo — it does nothing to stop someone who copied the token before logout. Study tip: When you see questions about token revocation, ask: does the server have any say in the matter? Purely client-side logout is always vulnerable to token theft — server-side revocation checks are the only way to enforce immediate invalidation.

Question 3

A privileged web application applies a 15-minute idle timeout and an eight-hour absolute session lifetime. A user authenticates at 09:00 and generates legitimate activity at least once every 10 minutes through 16:50. The user then submits another request at 17:05.

Assuming both limits are enforced independently, how should the application handle the 17:05 request?

  1. Accept it because continuing activity repeatedly reset both the idle and absolute expiration times.
  2. Reject it because the absolute lifetime expired even though prior activity prevented idle expiration. (correct answer)
  3. Accept it because the final period of inactivity was exactly the configured idle timeout.
  4. Reject it only if the user's browser has already removed the session cookie locally.
Explanation: When a question gives you two session controls, treat them as two independent clocks running simultaneously — one that resets on activity (idle timeout) and one that never resets (absolute lifetime). Your job is to check both before deciding whether a session is valid. Here, the user authenticates at 09:00, starting an eight-hour absolute session lifetime that expires at 17:00, regardless of any activity. The user also stays active every 10 minutes, which is within the 15-minute idle window, so the idle timer never triggers. At 17:05, however, the absolute clock has already expired — five minutes earlier. No amount of continued activity can extend an absolute lifetime; that's precisely why it exists. The 17:05 request must be rejected. B is correct. A is wrong because it conflates the two mechanisms. Continued activity does reset the idle timer, but it has no effect on the absolute lifetime. Treating one reset as covering both is a dangerous misunderstanding — and exactly the kind of privileged-session vulnerability absolute timeouts are designed to prevent. C is wrong on the math. The final activity was at 16:50, and the request arrives at 17:05 — that's 15 minutes of inactivity, which equals the idle threshold. Even if you argued this is borderline on the idle timer, the absolute limit expired at 17:00, so the session is already invalid on those grounds alone. D is wrong because session validity is enforced server-side. The browser's local cookie state is irrelevant — the server must reject an expired session independently of what the client holds. Study tip: Whenever you see dual session limits, always check the absolute expiration first. It's the hard ceiling that no activity can move.

Question 4

A legacy application accepts its session identifier in a URL such as https://portal.example/report?sid=.... The site uses HTTPS for all requests, but administrators discover session identifiers in browser histories, reverse-proxy logs, and outbound navigation metadata.

Which remediation most directly addresses the common cause of all three exposures?

  1. Continue using URL identifiers but configure TLS with only the newest approved cipher suites.
  2. Continue using URL identifiers but encrypt every page response with a separate application key.
  3. Shorten the URL identifier and rotate it whenever the user opens a different application page.
  4. Place the identifier in a Secure, HttpOnly cookie and reject session identifiers supplied in URLs. (correct answer)
Explanation: When session identifiers appear in URLs, three distinct but related problems emerge: browsers save the full URL in history, proxy and web servers log query strings by default, and when users click outbound links, the full URL (including the query string) leaks in the HTTP Referer header. Notice that all three exposures share the same root cause — the identifier lives in the URL itself. The fix must remove it from there entirely. Placing the session identifier in a Secure, HttpOnly cookie (D) solves all three problems at once. Cookies are not stored in browser history, are stripped from server logs by default, and are never included in Referer headers sent to third-party sites. The Secure flag ensures the cookie only travels over HTTPS, and HttpOnly blocks JavaScript from reading it, reducing XSS risk as a bonus. Rejecting URL-supplied identifiers closes the door against session fixation attacks that might try to smuggle identifiers through the old channel. A is a trap — stronger cipher suites protect data in transit, but they do nothing about identifiers already written to logs, histories, or metadata. TLS never had anything to do with these exposures. B encrypting page responses is similarly irrelevant; the problem is where the identifier appears, not whether the page content is additionally encrypted. C shortening and rotating the identifier reduces the window of exposure but doesn't eliminate the root cause — a shorter token is still logged, still saved in history, and still leaks via Referer. A useful heuristic: when a question lists multiple symptoms, look for the single architectural change that eliminates the shared root cause rather than mitigating each symptom individually. That's almost always the right answer on security exams.

Question 5

A developer constructs each session identifier by concatenating the user's numeric account ID with the current timestamp and then applying a reversible encryption algorithm under a server-held key. The developer argues that the result is secure because users cannot see the plaintext values.

Which redesign best addresses the primary session-management weakness in this construction?

  1. Add the user's IP address to the plaintext before encrypting the resulting identifier.
  2. Hash the account ID and timestamp without a secret key before returning the identifier.
  3. Generate an opaque identifier with a cryptographically secure random generator and map it to server-side state. (correct answer)
  4. Encode the encrypted identifier using a longer text representation before setting the cookie.
Explanation: When evaluating session management designs, ask yourself two foundational questions: does the token reveal or leak information about the user, and is the token's validity enforced server-side or derivable by an attacker? The construction described here has a critical flaw — the session identifier is deterministic. It's built from predictable inputs (account ID and timestamp) and protected only by the secrecy of the encryption key. This violates the principle that session tokens should be opaque and unpredictable. Even with encryption, if an attacker ever recovers the key, or if the algorithm is weak, tokens become forgeable across all users. Reversible encryption also means the structure survives decryption — an insider or key-leakage scenario exposes everything. Option C fixes this at the root: a cryptographically secure random number generator (CSRNG) produces a token with no structural relationship to user data. Server-side mapping means the token itself carries zero exploitable information. This is the industry-standard model. Option A adds the IP address to the plaintext, which is still deterministic and predictable — IP addresses are often known or guessable, and this adds binding, not true randomness. Option B removes the secret key and hashes without one, which is actually worse — an attacker who knows the account ID and approximate timestamp can brute-force the hash offline and forge tokens. Option D simply re-encodes the same flawed token in a longer format; obfuscation through encoding is never a security control. Study tip: On session-security questions, any token derived from user attributes or timestamps — no matter how transformed — is a red flag. True security comes from randomness and server-side validation, not from hiding a predictable value.

Question 6

A shopping site assigns an anonymous session identifier when a visitor first arrives. After successful authentication, the site associates the authenticated account with that same identifier. An attacker can obtain an anonymous identifier from the site and induce a victim's browser to use it before the victim signs in.

Which change most directly prevents the attacker from later using the known identifier as the victim's authenticated session?

  1. Regenerate the session identifier after authentication and invalidate the previously assigned anonymous identifier. (correct answer)
  2. Require HTTPS for the sign-in request and retain the identifier after authentication.
  3. Bind the existing session identifier to the IP address observed during authentication.
  4. Shorten the lifetime of anonymous sessions while retaining their identifiers after authentication.
Explanation: When you see a question about session security and attackers who pre-supply a session token to a victim, you're looking at a session fixation attack. The core vulnerability is that the site never breaks the link between the attacker-controlled identifier and the authenticated session — so fixing it means severing that link at the moment of login. The most direct countermeasure is A: regenerating the session identifier immediately after successful authentication and invalidating the old anonymous one. This works because even if the attacker knew the pre-login identifier, it becomes worthless the instant the victim authenticates — the server has discarded it and issued a fresh, unpredictable token the attacker never possessed. The attack's entire premise (that the known identifier carries over into the authenticated session) is neutralized. B is tempting because HTTPS is genuinely important for session security, but it doesn't address fixation at all. Encrypting the sign-in request doesn't change the fact that the server still promotes the attacker-supplied identifier into an authenticated session — the attacker already has it. C attempts to add a binding constraint, but IP-based validation is a weak mitigation. Many victims share IP addresses with attackers (via NAT, VPNs, or proxies), and mobile users change IPs frequently. This doesn't invalidate the compromised identifier; it just adds an unreliable gate. D shortens the window of anonymous sessions but retains the identifier after login — the exact flaw being exploited. Reducing duration doesn't prevent the attacker from triggering authentication before the short timeout expires. Your study tip: whenever a question describes an attacker pre-planting a session token, look for the answer that replaces that token at the privilege-change boundary — that's the session fixation defense pattern.

Question 7

A site stores its session identifier in a cookie configured with Secure, HttpOnly, and SameSite=Lax. The endpoint /account/email/change?value=new@example.net changes the authenticated user's email address in response to a GET request. An attacker places a link to that endpoint on another site.

Which change most appropriately addresses the remaining session-related request-forgery risk while preserving normal authenticated navigation?

  1. Change the operation to POST and require a valid anti-CSRF token tied to the user's session. (correct answer)
  2. Change SameSite from Lax to Strict and continue performing the update through a GET request.
  3. Remove HttpOnly so client-side code can verify the session identifier before the update.
  4. Add a restrictive CORS policy and continue accepting the state-changing GET request.
Explanation: When a question involves cookies, cross-site requests, and state-changing operations, you should immediately think about Cross-Site Request Forgery (CSRF). The core issue is: can an attacker trick a victim's browser into making an authenticated request the victim didn't intend? Here, the vulnerability is a GET request that changes account data. GET requests are supposed to be safe (read-only) by HTTP convention, and browsers freely send them across sites — including when a user clicks an attacker's link. The existing cookie flags (Secure, HttpOnly, SameSite=Lax) don't fully protect here because SameSite=Lax still allows cookies on top-level cross-site GET navigations — exactly what happens when someone clicks a link. Option A closes this gap correctly: moving the operation to POST (which Lax blocks cross-site) and requiring a synchronizer anti-CSRF token creates two independent layers of defense. The server validates that the request originated from a legitimate form, not a forged link. Option B is tempting but incomplete. SameSite=Strict would block cross-site navigations entirely, but it also breaks legitimate bookmarks and referral links — harming normal navigation, which the question explicitly says to preserve. It also doesn't fix the underlying architectural mistake of using GET for state changes. Option C is actively harmful. Removing HttpOnly exposes the session cookie to JavaScript, creating an XSS attack surface — a far worse trade-off than the problem you're solving. Option D is a common misconception. CORS governs cross-origin JavaScript requests, not browser-navigated GET requests triggered by links. An attacker doesn't need JavaScript to exploit this; a simple anchor tag suffices. Study tip: Remember that SameSite=Lax is not full CSRF protection — it permits cross-site GET navigations. Pair POST with anti-CSRF tokens for any state-changing operation.

Question 8

A mobile application uses refresh-token rotation. Each successful refresh invalidates the presented refresh token and issues a replacement belonging to the same token family. An attacker copies refresh token R1. The legitimate application uses R1 and receives R2. Later, the attacker attempts to use R1.

Which server response best uses token rotation to contain the likely session compromise?

  1. Reject R1 and revoke every refresh token issued to every user by the service.
  2. Reject R1, leave R2 valid, and record the failed attempt only for later review.
  3. Accept R1 once more, issue R3, and allow both R2 and R3 to remain valid.
  4. Reject R1, revoke the entire refresh-token family, and require the user to authenticate again. (correct answer)
Explanation: Refresh-token rotation is a security mechanism built on a simple contract: each token can be used exactly once. When a token is reused — especially one that was already consumed — the system treats it as a strong signal that the token family has been compromised, because either the legitimate user or an attacker is holding a stolen copy. Your job on questions like this is to identify which response best contains the breach rather than just reacting to the immediate event. When the attacker presents R1 (already consumed), the server knows something is wrong. The correct response, D, rejects the stale R1 and revokes the entire token family — every token derived from R1's lineage, including R2. This forces the legitimate user to re-authenticate, cutting off both the attacker's access and any lingering session. This is the core promise of rotation: reuse detection triggers full family invalidation, limiting the blast radius of a stolen token. A is a wildly disproportionate overreaction — revoking every user's tokens causes a service-wide denial of access for innocent users, which is both harmful and unnecessary. B is dangerously passive; leaving R2 valid means the attacker, if they somehow obtained R2, still has a live session, and "logging it for later" does nothing to stop ongoing compromise. C is the worst option — accepting a already-used token destroys the entire security model, effectively rewarding token replay attacks. The study tip here: when rotation questions describe a consumed token being replayed, the answer will almost always involve revoking the entire family, not just the individual token. Family-wide revocation is what makes rotation meaningful.

Question 9

An employee signs in to a support portal with ordinary privileges. To access administrative functions, the employee completes an additional authentication step. The application then adds an administrator role to the existing server-side session but leaves the session identifier unchanged.

Which modification best protects the privilege transition if the pre-elevation identifier was previously fixed or copied?

  1. Issue a new identifier after elevation but permit the old identifier brief continued access to allow in-flight requests to complete.
  2. Retain the identifier after elevation but reduce the session's remaining idle timeout to five minutes to limit exposure.
  3. Issue a new identifier after elevation, invalidate the old identifier, and transfer authorized session state to the replacement. (correct answer)
  4. Retain the identifier and set a separate signed cookie that asserts the additional authentication step was completed.
Explanation: When a session identifier remains unchanged across a privilege boundary, it becomes vulnerable to session fixation — an attack where an adversary who captured or planted the pre-elevation token can silently inherit the elevated privileges. Any question about protecting a privilege transition should immediately trigger this mental model: the old identifier is potentially compromised, so it must be fully replaced and destroyed. Option C is the correct approach because it addresses all three requirements of a secure transition: issuing a fresh identifier eliminates the attacker's foothold, invalidating the old one closes the window entirely, and transferring authorized session state ensures the legitimate user experiences no disruption. This is the standard defense mandated by frameworks like OWASP's Session Management Cheat Sheet — regenerate the session ID on any privilege change. Option A introduces a dangerous grace period. Allowing the old identifier to remain valid, even briefly, gives an attacker a predictable exploitation window. "Brief continued access" is exactly the gap an adversary exploits in automated attacks. Option B retains the compromised identifier entirely and only reduces timeout — this limits duration of exposure but does nothing to block an attacker already holding the token. Reducing timeout is a compensating control, not a fix. Option D compounds the problem by adding a signed cookie on top of an already-suspect identifier. If the session ID was fixed or copied, the attacker captures both the identifier and the privilege-assertion cookie together, gaining full elevated access anyway. Remember this rule: any privilege escalation = mandatory session ID regeneration with immediate invalidation of the predecessor. Partial measures that retain the old identifier are always distractors on session security questions.

Question 10

A team moves its session token from browser local storage into a Secure, HttpOnly session cookie. Several developers conclude that a later cross-site scripting vulnerability could no longer be used against authenticated sessions because injected JavaScript cannot read the cookie.

Which assessment of the developers' conclusion is most accurate?

  1. It is correct because HttpOnly prevents both reading the cookie and issuing authenticated browser requests.
  2. It is incomplete because injected code may issue authenticated requests even without reading the cookie. (correct answer)
  3. It is correct if the cookie is also Secure, because scripts cannot execute in an HTTPS origin.
  4. It is incomplete only because HttpOnly cookies may still be disclosed through the Referer header.
Explanation: When evaluating XSS mitigations, you need to distinguish between two separate threats: credential theft (stealing a token) and session riding (abusing an authenticated session). HttpOnly addresses only the first. Moving a session token into an HttpOnly cookie does block JavaScript from reading that cookie — document.cookie will not expose it. However, when injected JavaScript issues an HTTP request (via fetch(), XMLHttpRequest, or a dynamically created form), the browser automatically attaches all eligible cookies to that request, including HttpOnly ones. The attacker's script never needs to see the token; the browser does the work for them. This means authenticated requests can still be forged from within the victim's browser context. B is correct — the developers' conclusion is incomplete because they've only solved half the problem. A is wrong because it attributes a capability to HttpOnly that it simply doesn't have. HttpOnly prevents JavaScript from reading the cookie, but it does nothing to prevent the browser from sending it. Those are entirely different operations. C confuses the Secure flag's purpose. The Secure attribute ensures the cookie is only transmitted over HTTPS — it has no effect on whether scripts can execute or whether cookies are sent with scripted requests. D introduces a real but narrow edge case (Referer header leakage) and frames it as the only gap. The much more significant gap — forged authenticated requests — goes unmentioned, making D dangerously incomplete as an assessment. As a study tip, always ask yourself: does this control stop the attacker from obtaining a credential, or from using a session? XSS questions often hinge on that distinction.