Bird
Raised Fist0
Cybersecurityknowledge~20 mins

Secure cookie attributes in Cybersecurity - Practice Problems & Coding Challenges

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
Secure Cookie Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Understanding the Secure attribute in cookies

What is the main purpose of the Secure attribute in HTTP cookies?

AIt ensures the cookie is only sent over encrypted HTTPS connections.
BIt makes the cookie accessible only to JavaScript on the client side.
CIt restricts the cookie to be sent only to the domain that set it.
DIt sets an expiration date for the cookie to automatically delete.
Attempts:
2 left
💡 Hint

Think about how data security is maintained during transmission.

📋 Factual
intermediate
2:00remaining
Role of HttpOnly attribute in cookies

Which of the following best describes the effect of the HttpOnly attribute on a cookie?

AIt allows the cookie to be shared across different domains.
BIt encrypts the cookie content to protect it from being read by the server.
CIt prevents the cookie from being accessed by client-side scripts like JavaScript.
DIt makes the cookie persistent even after the browser is closed.
Attempts:
2 left
💡 Hint

Consider how to protect cookies from malicious scripts running in the browser.

🔍 Analysis
advanced
2:00remaining
Impact of SameSite attribute on cookie behavior

How does setting the SameSite=Strict attribute affect cookie transmission?

AThe cookie is sent with all requests, including cross-site requests.
BThe cookie is sent only with requests originating from the same site, blocking cross-site requests.
CThe cookie is sent only with cross-site requests, not same-site requests.
DThe cookie is deleted immediately after the session ends.
Attempts:
2 left
💡 Hint

Think about how websites prevent cross-site request forgery (CSRF) attacks.

Comparison
advanced
2:00remaining
Difference between SameSite=Lax and SameSite=Strict

Which statement correctly compares SameSite=Lax and SameSite=Strict cookie settings?

ASameSite=Lax allows cookies on some cross-site top-level navigations, while SameSite=Strict blocks all cross-site cookie sending.
BSameSite=Strict allows cookies on some cross-site navigations, while SameSite=Lax blocks all cross-site cookie sending.
CBoth settings allow cookies on all cross-site requests without restrictions.
DSameSite=Lax deletes cookies after 24 hours, SameSite=Strict deletes after session ends.
Attempts:
2 left
💡 Hint

Consider how each setting balances usability and security.

Reasoning
expert
3:00remaining
Choosing secure cookie attributes for a banking website

A banking website wants to protect user session cookies from theft and cross-site attacks. Which combination of cookie attributes provides the strongest protection?

ASecure, SameSite=None
BHttpOnly, SameSite=Lax
CSameSite=Strict only
DSecure, HttpOnly, SameSite=Strict
Attempts:
2 left
💡 Hint

Think about encryption, script access, and cross-site request protections together.

Practice

(1/5)
1. Which cookie attribute ensures that a cookie is only sent over secure HTTPS connections?
easy
A. SameSite
B. HttpOnly
C. Secure
D. Domain

Solution

  1. Step 1: Understand the Secure attribute purpose

    The Secure attribute restricts cookie transmission to HTTPS only, preventing sending over insecure HTTP.
  2. Step 2: Compare with other attributes

    HttpOnly prevents JavaScript access, SameSite controls cross-site sending, Domain sets cookie scope. Only Secure enforces HTTPS.
  3. Final Answer:

    Secure -> Option C
  4. Quick Check:

    Secure = HTTPS only [OK]
Hint: Secure means HTTPS only, no insecure sending [OK]
Common Mistakes:
  • Confusing HttpOnly with Secure
  • Thinking SameSite controls HTTPS
  • Assuming Domain affects security
2. Which of the following is the correct way to set a cookie with the HttpOnly attribute in an HTTP header?
easy
A. Set-Cookie: sessionId=abc123; httpOnly
B. Set-Cookie: sessionId=abc123; HttpOnly
C. Set-Cookie: sessionId=abc123; HTTPONLY
D. Set-Cookie: sessionId=abc123; Http-only

Solution

  1. Step 1: Check correct attribute spelling and casing

    HttpOnly must be spelled as 'HttpOnly' without spaces or hyphens.
  2. Step 2: Validate options

    Set-Cookie: sessionId=abc123; HttpOnly uses correct spelling and casing. Others have non-standard casing or hyphenation.
  3. Final Answer:

    Set-Cookie: sessionId=abc123; HttpOnly -> Option B
  4. Quick Check:

    HttpOnly attribute uses standard casing [OK]
Hint: HttpOnly standard casing: capital H and O [OK]
Common Mistakes:
  • Using lowercase 'httponly'
  • Adding hyphens like 'Http-only'
  • Using all uppercase 'HTTPONLY'
3. Consider this Set-Cookie header:
Set-Cookie: id=123; Secure; HttpOnly; SameSite=Strict
Which of the following is true about this cookie?
medium
A. It will only be sent over HTTPS and not accessible via JavaScript.
B. It will be sent with cross-site requests regardless of origin.
C. It is not restricted to HTTPS and can be sent over HTTP.
D. It can be accessed by JavaScript on the client side.

Solution

  1. Step 1: Analyze Secure and HttpOnly attributes

    Secure means cookie sent only over HTTPS. HttpOnly means JavaScript cannot access it.
  2. Step 2: Understand SameSite=Strict effect

    SameSite=Strict prevents sending cookie with cross-site requests, enhancing security.
  3. Final Answer:

    It will only be sent over HTTPS and not accessible via JavaScript. -> Option A
  4. Quick Check:

    Secure + HttpOnly + SameSite=Strict = HTTPS only, no JS access [OK]
Hint: Secure + HttpOnly means HTTPS only and no JS access [OK]
Common Mistakes:
  • Thinking HttpOnly allows JavaScript access
  • Assuming SameSite=Strict allows cross-site sending
  • Ignoring Secure attribute effect
4. A developer sets a cookie with this header:
Set-Cookie: token=abc; Secure; SameSite=None
Users report the cookie is not sent in some browsers. What is the likely issue?
medium
A. SameSite=None requires Secure attribute, which is missing.
B. HttpOnly attribute is missing, causing cookie to be blocked.
C. SameSite=None is invalid and blocks the cookie.
D. Secure attribute requires HTTPS, but site uses HTTP.

Solution

  1. Step 1: Understand Secure attribute requirement

    Secure cookies are only sent over HTTPS connections. If site uses HTTP, cookie won't be sent.
  2. Step 2: Check SameSite=None and Secure relation

    SameSite=None requires Secure attribute to be set, which is done here, so no issue.
  3. Final Answer:

    Secure attribute requires HTTPS, but site uses HTTP. -> Option D
  4. Quick Check:

    Secure cookie + HTTP site = cookie not sent [OK]
Hint: Secure cookies need HTTPS; HTTP sites block them [OK]
Common Mistakes:
  • Thinking SameSite=None alone blocks cookies
  • Assuming HttpOnly is required for sending
  • Ignoring HTTPS requirement for Secure
5. A website wants to protect user session cookies from being stolen via cross-site scripting (XSS) and cross-site request forgery (CSRF). Which combination of cookie attributes best achieves this?
hard
A. Secure; HttpOnly; SameSite=Strict
B. HttpOnly; SameSite=None
C. Secure; SameSite=Lax
D. SameSite=Strict only

Solution

  1. Step 1: Prevent XSS with HttpOnly

    HttpOnly prevents JavaScript access to cookies, reducing XSS risk.
  2. Step 2: Prevent CSRF with SameSite=Strict and Secure

    SameSite=Strict blocks cross-site requests sending cookies, preventing CSRF. Secure ensures cookies sent only over HTTPS, adding protection.
  3. Final Answer:

    Secure; HttpOnly; SameSite=Strict -> Option A
  4. Quick Check:

    HttpOnly + Secure + SameSite=Strict = best XSS and CSRF protection [OK]
Hint: Use all three: Secure, HttpOnly, SameSite=Strict for best safety [OK]
Common Mistakes:
  • Using SameSite=None which allows cross-site sending
  • Omitting Secure attribute on HTTPS sites
  • Relying on SameSite only without HttpOnly