Cookie Security Attributes
debt(d5/e3/b5/t7)
Closest to 'specialist tool catches' (d5). The term's detection_hints list semgrep and owasp-zap as tools that can catch missing cookie security attributes. These are specialist security tools, not default linters — a standard PHP linter won't flag missing __Host- prefixes or SameSite attributes without specific security rules configured.
Closest to 'simple parameterised fix' (e3). The quick_fix shows a single call to session_set_cookie_params with proper flags before session_start(). However, fixing this across an application may require updating multiple setcookie() calls and ensuring all cookie-setting code paths use consistent attributes, pushing slightly beyond a one-liner but still a localized, parameterized fix pattern.
Closest to 'persistent productivity tax' (b5). Cookie security applies to web contexts and affects session handling across the application. Every feature that touches authentication or session state must respect these conventions. The choice has moderate reach — it's not architectural, but misconfiguration anywhere in cookie-setting code creates security holes. Developers must consistently remember the prefix rules and attribute requirements.
Closest to 'serious trap' (t7). The misconception explicitly states developers confuse __Secure- and __Host- prefixes, believing they're equivalent when __Host- has stricter requirements (no Domain attribute, Path=/). Common_mistakes confirm: setting Domain on __Host- cookies causes silent rejection by browsers — no error, just ignored. The 'obvious' approach of adding Domain for flexibility breaks __Host- entirely. This contradicts intuitive expectations about cookie prefixes.
Also Known As
TL;DR
Explanation
Cookie prefixes enforce security at the browser level: __Secure- prefix requires Secure flag and HTTPS. __Host- prefix requires Secure, no Domain attribute, and Path=/ — the strictest option, ensuring the cookie cannot be sent to subdomains or over HTTP. The Partitioned attribute (CHIPS — Cookies Having Independent Partitioned State) prevents cross-site tracking by isolating cookies per top-level site. Combined with SameSite=Strict and HttpOnly, these prefixes defend against session fixation, CSRF, and subdomain takeover attacks.
Common Misconception
Why It Matters
Common Mistakes
- __Host- cookie with a Domain attribute set — the prefix is silently rejected by the browser.
- __Secure- prefix on a cookie served over HTTP — the cookie is rejected.
- Not using SameSite=Strict alongside prefixes — prefixes don't protect against CSRF on their own.
- Forgetting HttpOnly on auth cookies — JS-readable cookies are XSS-vulnerable regardless of prefix.
Code Examples
// Insecure session cookie:
setcookie('session', $token, [
'secure' => false, // Sent over HTTP
'httponly' => false, // Readable by JavaScript
'samesite' => 'None', // Sent on all cross-site requests
]);// __Host- prefix — maximum security:
setcookie('__Host-session', $token, [
'expires' => 0,
'path' => '/', // Required for __Host-
'secure' => true, // Required for __Host-
'httponly' => true, // Block JS access
'samesite' => 'Strict', // CSRF protection
// No 'domain' key — required for __Host-
]);
// Browser enforces: HTTPS only, path=/, no subdomain sharing