Insecure Cookie Configuration (Missing Secure / HttpOnly Flags)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Session Management / Cookie Security
Typical Severity Medium
OWASP A02:2021 – Cryptographic Failures; A07:2021 – Identification and Authentication Failures
CWE CWE-614 (Missing Secure flag), CWE-1004 (Missing HttpOnly flag)
Also known as Insecure session cookie, cookie without Secure flag, cookie without HttpOnly flag
Affected systems Any web application that sets HTTP cookies for session management, authentication, or user tracking
Relevant standard RFC 6265 – HTTP State Management Mechanism

Overview

HTTP cookies are the primary mechanism web applications use to maintain state — most critically, authenticated sessions. RFC 6265 defines several optional cookie attributes that restrict how and when browsers transmit or expose cookie values. Two of the most security-critical attributes are:

  • Secure — instructs the browser to transmit the cookie only over HTTPS connections, preventing exposure over unencrypted HTTP.
  • HttpOnly — prevents client-side JavaScript from accessing the cookie value via document.cookie, mitigating cookie theft through Cross-Site Scripting (XSS).

When either attribute is absent on a sensitive cookie (e.g., a session identifier), the attack surface for session hijacking expands significantly. Sensagraph automatically detects missing Secure and HttpOnly flags on cookies set by scanned applications.

How it works

Missing Secure flag: If a session cookie is issued without the Secure attribute, the browser will include it in both HTTP and HTTPS requests. An on-path attacker (e.g., on an open Wi-Fi network) performing a passive intercept or an SSL-stripping attack (HTTPS downgrade) can capture the cookie in plaintext, even if the origin server exclusively serves HTTPS.

Missing HttpOnly flag: Without the HttpOnly attribute, any JavaScript executing in the page context — including injected malicious scripts from an XSS vulnerability — can read the cookie value using document.cookie and exfiltrate it to an attacker-controlled server. This is the canonical post-exploitation step in XSS-based session hijacking.

  • A Set-Cookie header such as Set-Cookie: sessionid=abc123; Path=/ is insecure — it lacks both flags.
  • The secure version is: Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Strict.
  • The SameSite attribute (Lax or Strict) is a complementary control that mitigates Cross-Site Request Forgery (CSRF) but does not replace Secure or HttpOnly.
  • Cookies set over HTTP cannot retroactively become Secure cookies — the flag must be present in the original Set-Cookie response header.
  • Third-party or analytics cookies lacking HttpOnly also expose user tracking identifiers to script injection attacks.

Business impact

Exploitation of insecurely configured cookies can lead to full account takeover if the affected cookie carries a session token or authentication credential. Specific consequences include:

  • Session hijacking: An attacker who obtains a valid session cookie can impersonate the authenticated user without needing their password.
  • Privilege escalation: If an administrative session cookie is captured, the attacker gains the highest level of access to the application.
  • Regulatory exposure: Session data is often considered personal data under GDPR, CCPA, and similar regulations. Inadequate cookie security can constitute a failure to implement appropriate technical safeguards, resulting in fines and mandatory breach notification.
  • Reputational damage: Account takeover incidents erode user trust and may require public disclosure depending on jurisdiction.
  • PCI DSS non-compliance: Applications handling payment card data are required under PCI DSS Requirement 6 to protect session management mechanisms, including cookie security.

How to fix it

  1. Set the Secure flag on all sensitive cookies. Ensure every cookie that carries a session identifier, authentication token, or any sensitive value is issued with the Secure attribute. This must be combined with enforcing HTTPS across the entire application (use HSTS — Strict-Transport-Security).
  2. Set the HttpOnly flag on all session and authentication cookies. Unless a cookie value genuinely needs to be read by client-side JavaScript (rare and generally avoidable by design), apply HttpOnly to prevent script access.
  3. Add the SameSite attribute. Set SameSite=Strict for session cookies where cross-site requests are not required, or SameSite=Lax as a minimum baseline. Avoid SameSite=None unless necessary (and it requires Secure).
  4. Audit cookie issuance centrally. Use framework-level or middleware-level cookie configuration rather than setting attributes per-response. Most frameworks provide a global session cookie configuration (e.g., SESSION_COOKIE_SECURE and SESSION_COOKIE_HTTPONLY in Django; cookie: { secure: true, httpOnly: true } in Express/connect sessions).
  5. Scope cookies with Path and Domain. Restrict cookies to the narrowest necessary path and domain to limit exposure if another subdomain is compromised.
  6. Implement Content Security Policy (CSP). A robust CSP reduces the risk of XSS, which is the primary attack vector that benefits from a missing HttpOnly flag. This is a defence-in-depth measure, not a substitute for HttpOnly.
  7. Rotate and expire cookies appropriately. Issue cookies with explicit Max-Age or Expires values; issue new session cookies upon privilege changes (login, role change) and invalidate old ones server-side.
  8. Test using automated and manual review. Inspect all Set-Cookie headers in HTTP responses, including those from third-party integrations and CDN edge layers, to confirm flags are consistently applied.

References

Frequently asked questions

Yes. Even on a fully HTTPS site, the browser will still send cookies over HTTP if the Secure flag is absent — for example, if a user types the URL without 'https://' and is redirected, or if an attacker performs an SSL-stripping attack before the redirect occurs. The Secure flag ensures the cookie is never sent over a plaintext connection regardless of how the request was initiated. Pairing it with HTTP Strict Transport Security (HSTS) provides the strongest protection.

Yes. Defence in depth requires both. XSS remediation reduces the likelihood of script injection, but HttpOnly independently prevents any JavaScript — including browser extensions, third-party scripts, or future XSS regressions — from reading the cookie. HttpOnly is a low-cost, high-value control that should be applied unconditionally to session and authentication cookies.

Cookies you set server-side via your own Set-Cookie headers are fully under your control. For cookies set by third-party JavaScript (e.g., analytics platforms), you typically cannot add HttpOnly because such cookies are set via document.cookie in client-side code — HttpOnly cookies can only be set by the server. The practical mitigations are to use a Content Security Policy to restrict third-party script behaviour, and to review whether third-party cookies are genuinely necessary.

SameSite controls whether a cookie is sent on cross-site requests, which primarily mitigates Cross-Site Request Forgery (CSRF). It does not prevent network interception (Secure's role) nor script access (HttpOnly's role). All three attributes serve different threat models and should all be applied to session cookies. SameSite=Strict or SameSite=Lax is recommended; SameSite=None requires the Secure attribute.

You can inspect Set-Cookie response headers in your browser's developer tools (Application tab → Cookies, or Network tab response headers). Look for session, auth, or token cookies that do not list 'Secure' and 'HttpOnly' in their attributes. Automated scanners, including Sensagraph, detect these misconfigurations across all pages and authenticated paths of your application.