Secure: Cookie only transmitted over HTTPS connections (never HTTP). Header: Set-Cookie: sessionid=abc123; Secure. Prevents man-in-the-middle interception on insecure networks. Mandatory for all production cookies. Browsers reject Secure cookies sent over HTTP. HttpOnly: Prevents JavaScript access via document.cookie. Header: Set-Cookie: sessionid=abc123; HttpOnly. Primary XSS defense - even if XSS exists, attacker cannot steal session cookie. Mandatory for authentication/session cookies. Cannot be read/modified by client-side scripts. OWASP Top 10 A05:2021 (Security Misconfiguration).
Cookie Security Attributes FAQ & Answers
6 expert Cookie Security Attributes answers researched from official documentation. Every answer cites authoritative sources you can verify.
unknown
6 questionsSameSite: CSRF protection by controlling cross-site cookie transmission. Values: Strict (cookie only sent in same-site requests, strongest protection, may break OAuth flows), Lax (default in modern browsers, sent on top-level navigation GET requests, balanced protection, recommended for most cases), None (sent on all cross-site requests, requires Secure attribute, use only for embedded content/OAuth). Header: Set-Cookie: sessionid=abc123; SameSite=Lax. Chrome 80+ (2020) defaults to SameSite=Lax if not specified. Best practice: use SameSite=Lax for session cookies, SameSite=Strict for remember-me cookies.
Domain: Restricts cookie scope to specific domain/subdomains. Examples: Domain=example.com (cookie sent to example.com and all subdomains), No Domain attribute (cookie only sent to exact domain that set it - most restrictive). Best practice: Omit Domain attribute or set narrowly (avoid .com, .co.uk). Path: Limits cookie to specific URL path. Example: Path=/api (cookie only sent for /api/* requests). Defense-in-depth (weak protection alone). Default: Path=/ (all paths). Recommendation: use Path for additional security layer, not as primary protection.
__Secure- prefix: Requires Secure attribute. Example: Set-Cookie: __Secure-sessionid=abc; Secure; HttpOnly. Browser rejects if Secure not present. __Host- prefix (strictest): Requires Secure attribute, must NOT have Domain attribute, must have Path=/. Example: Set-Cookie: __Host-sessionid=abc; Secure; HttpOnly; Path=/. Prevents subdomain/path attacks. Recommended for high-security cookies. Production session cookie example: Set-Cookie: __Host-sessionid=abc123; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600. Browser support: all modern browsers (2025), IE11 lacks support (deprecated 2022).
Max-Age / Expires: Controls cookie lifetime. Max-Age=3600 (expires in 3600 seconds / 1 hour), Expires=Wed, 21 Oct 2025 07:28:00 GMT (absolute expiration). Session cookies (no Max-Age/Expires): deleted when browser closes. Persistent cookies: use Max-Age for relative expiration (preferred over Expires). Recommendation: Session cookies for authentication (no Max-Age), remember-me cookies: Max-Age=2592000 (30 days). Example remember-me: Set-Cookie: __Secure-remember=xyz; Secure; HttpOnly; SameSite=Strict; Max-Age=2592000.
Common mistakes: (1) Storing sensitive data in cookies (encrypt if necessary, prefer server-side storage), (2) Forgetting Secure in production (cookies leak over HTTP), (3) Not setting HttpOnly on session cookies (XSS steals sessions), (4) Using SameSite=None without understanding (weakens CSRF protection), (5) Setting Domain too broadly (Domain=.com exposes to all subdomains). Framework implementations: Express.js: session({cookie: {secure: true, httpOnly: true, sameSite: 'lax', maxAge: 3600000}}), Django: SESSION_COOKIE_SECURE=True, SESSION_COOKIE_HTTPONLY=True. Testing: Browser DevTools → Application → Cookies, OWASP ZAP scanner. Compliance: PCI-DSS 6.5.10, GDPR Article 32.