Session cookies are the keys to your users' accounts. A few attributes on each cookie decide whether it can be stolen by scripts, sent over plain HTTP, or attached to requests from other websites.

How it happens

Frameworks do not always set safe defaults. A session cookie without HttpOnly can be read by an XSS payload, one without Secure can leak over HTTP, and one without a suitable SameSite value is sent on cross-site requests, enabling CSRF.

Why it matters

• Session hijacking and account takeover.
• Cross-site request forgery.
• Cookie tossing and scope issues across subdomains.

How to prevent it

• Set Secure and HttpOnly on all session and authentication cookies.
• Use SameSite=Lax or Strict; only use None when needed, and always with Secure.
• Scope cookies to the narrowest domain and path.
• Use the __Host- prefix for the most sensitive cookies.

How Vooki Pro helps

• Checks every cookie for the Secure, HttpOnly and SameSite flags, scope and prefixes.
• Flags sensitive data stored in cookies, cookie tossing and oversized cookies.
• Tests session fixation, weak session IDs and missing session expiry.
• Consolidates cookie findings so each cookie is reported once.

Frequently asked questions

What does the HttpOnly flag do?

HttpOnly stops JavaScript from reading the cookie, so an XSS payload cannot steal the session token.

Which SameSite value should I use?

Lax is a good default for session cookies; Strict is stronger. Only use None when cross-site sending is required, and always with Secure.

Related: HTTPS done right: HSTS and TLS configuration · Session management best practices