The one-sentence version
A website remembers that "you are logged in" thanks to a session cookie stored in your browser. Obtaining it is equivalent to obtaining your account.
Four attributes block four different paths: Secure prevents eavesdropping via plaintext transmission, HttpOnly prevents reading by page scripts (XSS), SameSite prevents misuse by other websites (CSRF), and the __Host- prefix prevents overwriting by other subdomains under the same domain. Combined with the principle that "high-privilege sessions must be short," these form the fundamentals of session security.
This article has three layers:
- Layer 1: The Intuition: A cookie is an automatically presented pass
- Layer 2: Real-World Use: The real consequences of session hijacking and CSRF
- Layer 3: Principles and Engineering details: Rules for each attribute, SSO sessions, and high-privilege session separation
Layer 1: The Intuition
1.1 An Automatically Presented Pass
After you log in once, the website sends a "pass" (cookie) to your browser. Every subsequent visit to this website will automatically include it, allowing the website to know it is you.
"Automatic" brings convenience, but it also brings three problems:
| Problem | Analogy |
|---|---|
| The pass is seen by someone on the road | Plaintext transmission over public Wi-Fi |
| A thief sneaks into the room and photocopies the pass | Malicious scripts are injected into the webpage (XSS), and the script steals the cookie |
| Someone tricks you into knocking on a door, and your pass is automatically presented | A malicious website makes your browser send a request to a bank (CSRF) |
Layer 2: Real-World Use
- Session Hijacking: The 2010 Firesheep browser extension could intercept Facebook and Twitter session cookies with one click on cafe Wi-Fi. It directly drove the widespread adoption of HTTPS and the Secure attribute across the web.
- Stealing cookies to bypass 2FA: In recent years, many "information stealer Trojans" directly steal session cookies from browsers. Once the cookie is obtained, passwords and verification codes are no longer needed; the large-scale hijacking of YouTube creator accounts used this exact method.
- CSRF: In the early days, many router management pages and online banking systems fell victim to this: you visit a malicious webpage, and it submits a form in the background to modify your router's DNS or initiate a transfer.
Caloogy Wallet also employs strict cookie attributes.
Layer 3: Principles and Engineering
3.1 A "Fully Equipped" Session Cookie
Set-Cookie: __Host-session=random long string; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=...
| Attribute | Rule | Protects against |
|---|---|---|
Secure |
Sent only over HTTPS connections | Network eavesdropping |
HttpOnly |
Page JavaScript cannot read it (cannot be seen in document.cookie) |
XSS directly stealing the session |
SameSite=Strict |
Only included in requests initiated from this site | CSRF: Requests triggered by other websites do not include the cookie |
SameSite=Lax |
Included in cross-site standard link navigation, but not in cross-site form POSTs, images, or iframes | Most CSRF, without affecting the ability to stay logged in when clicking an external link |
__Host- Prefix |
Browser enforcement: Must be Secure, Path=/, and cannot set Domain |
Other subdomains under the same primary domain writing a cookie with the same name to overwrite your session (cookie injection / session fixation) |
3.2 HttpOnly is not a silver bullet
HttpOnly prevents scripts from "stealing" the cookie, but XSS scripts can still send requests directly from your page, using your identity. Therefore, it only mitigates damage; true XSS prevention relies on input/output encoding and CSP (see "CSP and SRI").
3.3 Beyond SameSite: Verifying the Origin Again
SameSite relies on browser implementation; older browsers or certain special redirects may not work as expected. The server should perform an additional check on the Origin header (or use a CSRF token) for all requests that modify state, creating a double layer of protection.
3.4 Session Tiering
| Session | Duration | Capabilities |
|---|---|---|
| Standard Login (SSO) | Can be long, measured in weeks | Browsing, read-only |
| High-privilege Session | Short: expires quickly after inactivity, and has an absolute limit | Moving money, changing security settings |
The two are issued separately: a high-privilege session requires an additional strong authentication (such as a passkey) on top of the standard session. If the standard session is revoked, the high-privilege session must also be invalidated simultaneously.
3.5 "same-site" does not equal "same-origin"
a.example.com and b.example.com are same-site but cross-origin. SameSite cannot block requests initiated by sibling subdomains under the same primary domain. This is precisely why high-value applications must be isolated separately and use the __Host- prefix (see "Same-Origin Policy and Subdomain Isolation").
Summary
| Attribute | In a nutshell |
|---|---|
| Secure | HTTPS only |
| HttpOnly | Scripts cannot read |
| SameSite | Other websites cannot use |
__Host- |
Sibling subdomains cannot modify |
| Session Tiering | Sessions for moving money must be short and require extra authentication |