CWE-614: Sensitive Cookie Without 'Secure' Flag
Overview
This vulnerability occurs when sensitive cookies (such as session IDs or authentication tokens) are set without the Secure flag, allowing them to be transmitted over unencrypted connections and exposed to attackers.
OWASP Classification
A02:2025 - Security Misconfiguration
Risk
High: Attackers can intercept cookies over insecure channels, leading to session hijacking, account compromise, or data breaches.
Remediation Steps
Core principle: Never allow sensitive cookies to be transmitted over unencrypted connections; cookie confidentiality must be enforced by the transport and server configuration, not by client behavior.
Locate cookies missing the Secure flag
- Review the flaw details to identify which cookies lack the Secure flag
- Check cookie-setting code: response.set_cookie(), res.cookie(), Cookie.setValue()
- Identify sensitive cookies: session IDs, authentication tokens, CSRF tokens, user preferences
- Trace cookie creation: where cookies are set in authentication, session management
Set the Secure flag on all sensitive cookies (Primary Defense)
- Always set Secure flag:
response.set_cookie('sessionid', value, secure=True) - Framework-specific: Flask:
secure=True, Express:secure: true, Spring:cookie.setSecure(true) - Ensure cookies only sent over HTTPS: Secure flag prevents transmission over HTTP
- Apply to ALL sensitive cookies: Session IDs, auth tokens, CSRF tokens, remember-me tokens
- Enforce HTTPS: Use HSTS to ensure all connections use HTTPS
Use HttpOnly and SameSite flags for defense in depth
- Set HttpOnly flag: Prevent client-side JavaScript access to cookies (XSS protection)
- Use SameSite attribute: Set
SameSite=StrictorSameSite=Laxto mitigate CSRF attacks - SameSite=Strict: Cookie never sent on cross-site requests (most secure, may break some flows)
- SameSite=Lax: Cookie sent on top-level navigation (balance security and usability)
- Complete cookie security:
secure=True, httponly=True, samesite='Strict'
Limit cookie scope and lifetime
- Set appropriate Path: Limit cookie to specific paths (
path='/app'), not site-wide (path='/') unless needed - Set appropriate Domain: Don't use wildcard domains unless necessary
- Use short-lived cookies: Session cookies expire on browser close, or set max_age for limited lifetime
- Rotate session tokens regularly: Regenerate session IDs periodically, especially after privilege changes
Monitor and audit cookie usage
- Log cookie creation and access events (session creation, authentication events)
- Alert on suspicious cookie usage (duplicate sessions from multiple IPs, unusual access patterns)
- Review cookie configuration regularly (ensure Secure, HttpOnly, SameSite flags are set)
- Scan for insecure cookies in code reviews
- Use security headers scanner to verify cookie attributes
Test the cookie security fix thoroughly
- Verify Secure flag is set: inspect Set-Cookie headers in browser DevTools or Burp Suite
- Test cookies not sent over HTTP: make HTTP request, verify cookie not transmitted
- Verify HttpOnly flag: attempt to access cookie from JavaScript (document.cookie should not show it)
- Verify SameSite flag: test cross-site request, verify cookie not sent
- Test on HTTPS: ensure cookies work correctly over secure connections
- Re-scan with security scanner to confirm the issue is resolved
Common Vulnerable Patterns
- Setting cookies without the
Secureflag - Allowing cookies to be sent over HTTP
- Failing to use
HttpOnlyorSameSiteattributes
Cookie Without Secure Flag (Python)
Why this is vulnerable: Without the Secure flag, cookies are transmitted over both HTTP and HTTPS connections, allowing attackers on the same network (public WiFi, compromised router) to intercept session cookies via packet sniffing or man-in-the-middle attacks, leading to session hijacking and account takeover.
Secure Patterns
Secure Cookie with HttpOnly and SameSite (Python)
# Sets session cookie with Secure, HttpOnly, and SameSite flags
response.set_cookie(
'sessionid',
value,
secure=True, # Only sent over HTTPS
httponly=True, # Not accessible to JavaScript
samesite='Strict' # Not sent in cross-site requests
)
Why this works:
Secureflag ensures cookies are only transmitted over HTTPS, preventing interception on unencrypted HTTP connectionsHttpOnlyprevents JavaScript access to the cookie, blocking XSS attacks from stealing session tokensSameSite='Strict'prevents cookies from being sent in cross-site requests, blocking CSRF attacks- Protects session cookies and authentication tokens from man-in-the-middle attacks on insecure networks
- Combined flags provide defense-in-depth against multiple attack vectors (session hijacking, XSS, CSRF)
Language-Specific Guidance
For detailed examples and best practices in specific languages:
- Python - Flask/Django/FastAPI cookie security with
secure=True,httponly=True,samesite='Strict' - Java - Servlet/Spring Boot/JAX-RS cookie security with
setSecure(true),setHttpOnly(true) - JavaScript/Node.js - Express/Fastify/Next.js cookie security with
secure: true,httpOnly: true,sameSite: 'strict'
Dynamic Scan Guidance
For guidance on remediating this CWE when detected by dynamic (DAST) scanners:
- Dynamic Scan Guidance - Analyzing DAST findings and mapping to source code