What is a secure cookie?
A cookie is a small value a website asks the browser to store and send back with later requests. The most valuable one is usually the session cookie: after sign-in, whoever presents it is treated as the signed-in user, often with no further password or MFA prompt. A secure cookie is one the server sets with attributes that limit where the browser will send it and what can read it. In the narrowest sense the phrase means a cookie carrying the Secure attribute; in Security+ usage it means the whole set of protective attributes applied to session cookies and other sensitive cookies.
The attributes and what each prevents
- Secure: the browser sends the cookie only over HTTPS. That keeps the token off plaintext requests, for example when a user on hotel Wi-Fi types the site name without https and the first request leaves unencrypted.
- HttpOnly: page scripts cannot read the cookie through
document.cookie, so a cross-site scripting payload cannot copy the token to an attacker's server. - SameSite: controls whether the cookie goes along on requests that start from another site.
Strictnever sends it cross-site;Laxsends it when the user follows a link to the site but not on cross-site form posts or embedded requests;Nonealways sends it and requiresSecure. Strict and Lax reduce cross-site request forgery. - Expires or Max-Age: limits how long a stolen cookie stays useful. With neither, the browser treats it as a session cookie and normally discards it when it closes.
- Domain and Path: leaving out
Domainkeeps the cookie on the exact host that set it instead of every subdomain. A name starting with__Host-makes the browser insist on Secure, Path=/ and no Domain.
Example: a hardened session cookie
Set-Cookie: __Host-session=Zx8Kq3vT9mW2pL5rB7nD4yH6; Path=/; Secure; HttpOnly; SameSite=Strict; Max-Age=1800
This cookie travels only over HTTPS to the exact host that issued it, is invisible to JavaScript, is never attached to requests launched from other sites, and expires after 30 minutes. Strict suits an online bank. A site whose users often arrive from email links usually picks Lax, because under Strict a user who follows a link from another site lands on the page without the cookie and appears signed out.
What cookie attributes don't fix
Each attribute closes one path. HttpOnly stops a script from reading the token, but a script running in the page can still send requests as the user, so the cross-site scripting flaw itself still needs output encoding. Secure protects the token in transit, not on an infected endpoint: infostealer malware that copies cookies straight out of the browser profile ignores every one of these attributes, which is why short session lifetimes and reauthentication for sensitive actions still matter. The session ID itself must also be long and random, replaced with a new one at login to prevent session fixation, and invalidated on the server at logout.
Secure cookies vs. related controls
- HSTS: tells the browser to use HTTPS for the entire site. The Secure attribute protects one cookie.
- Anti-CSRF tokens: a per-form secret the attacker's site cannot know. SameSite is a browser-side backstop for the same problem.
- Output encoding: fixes cross-site scripting. HttpOnly only limits one consequence of it.
Secure cookie on the CompTIA Security+ exam
Secure cookies are one of the application security controls listed under SY0-801 objective 4.1, and cookie attributes come up again as a defense against session token theft among the attacks in objective 2.5. Match the attribute to the threat: an injected script stole session cookies points to HttpOnly, a cookie was captured from an unencrypted request on public Wi-Fi points to Secure, and a request forged from another site carried the victim's session points to SameSite. Distractors include encrypting the cookie's value, which does nothing if the attacker simply replays the whole cookie, and client-side validation, which has nothing to do with where cookies travel.