--- title: "Cookie Prefixes Explained: `__Secure-` and `__Host-`" description: "Secure your cookies with __Secure- and __Host- prefixes. Learn built-in browser protections for better session management." slug: "cookie-prefixes-explained-secure-and-host" url: "https://furkanbaytekin.dev/blogs/cookie-prefixes-explained-secure-and-host" author: "Furkan Baytekin" category: "Software" tags: [] published: 2025-12-14T08:39:40Z updated: 2025-12-14T08:39:40Z readTime: 3 cover: "https://myblogcms.furkanbaytekin.dev/uploads/cover/cookie-prefixes-explained-secure-and-host+1765700934598" --- Modern web apps rely heavily on cookies for sessions, preferences, and authentication. But cookies are also a common attack surface, especially in XSS and session hijacking scenarios. To reduce risk, browsers support special cookie **prefixes** that enforce security rules automatically: `__Secure-` and `__Host-`. If you’re building anything that handles user accounts, tokens, or sessions, these prefixes are your friends. --- ## What Cookie Prefixes Are A cookie prefix is simply a naming convention. When a cookie starts with `__Secure-` or `__Host-`, the browser expects it to follow certain rules. If the rules aren’t met, the browser refuses to set the cookie. This adds an extra layer of protection that developers can’t accidentally misconfigure. --- ## `__Secure-` Cookie Prefix **What it requires:** - Must be set over HTTPS - Must include `Secure` flag That’s it. Browsers will block the cookie if it’s set over HTTP or without `Secure`. **Why it matters:** `Secure` ensures the cookie is never leaked over plaintext connections. Combined with HTTPS, it protects session cookies from basic network sniffing and MITM attacks. **Example:** ```http Set-Cookie: __Secure-sessionId=abc123; Secure; HttpOnly; Path=/; SameSite=Lax ``` --- ## `__Host-` Cookie Prefix `__Host-` is the strictest cookie prefix. Think of it like a hardened version of `__Secure-`. **What it requires:** - Must be set over HTTPS - Must include the `Secure` flag - Must NOT include a `Domain` attribute - Path must be `/` ### Why these rules matter - **No Domain attribute** → cookie is locked to the _exact_ host that set it. No subdomains, no shared cookies, no unintended scope. - **Path=/** → full-site cookie, avoids tricky path scoping issues. - **Secure+HTTPS** → same protection as `__Secure-`. This makes it ideal for: - Session cookies - CSRF tokens - Authentication state - Anything you never want a subdomain to mess with **Example:** ```http Set-Cookie: __Host-authToken=xyz789; Secure; HttpOnly; Path=/; SameSite=Strict ``` If you try to add `Domain=example.com`, browsers will reject it. That’s the whole point. --- ## When to Use Which? **Use `__Secure-` when:** - You want extra safety but still need domain scoping - You’re dealing with multi-subdomain setups **Use `__Host-` when:** - You’re setting a session cookie - You want the highest protection level - You want to prevent subdomain attacks - You want to guarantee strict host-level isolation For authentication, `__Host-` is the best choice. --- ## SEO Angle: Why Search Engines Care Search engines reward secure sites. Using cookie prefixes helps ensure: - No mixed-content issues - No insecure session handling - Better Core Web Vitals from reduced browser warnings - A cleaner security profile, which indirectly helps trust signals Security → trust → stronger SEO. --- ## Best Practices - **Always combine prefixes with `HttpOnly` and `SameSite`** - **Avoid storing sensitive data directly in cookies** - **Rotate session identifiers regularly** - **Never set auth cookies from JavaScript** Prefixes help, but they don’t replace secure coding. --- ## Final Thoughts `__Secure-` and `__Host-` prefixes give you built-in safety nets against common cookie misconfigurations. They’re simple to use, harden your session management, and reduce the risk of accidental exposure. If you handle logins or sessions, just use them - they’re basically free security. --- Album of the blog: