Skip to main content

​
Overview

This vulnerability occurs when an application sets a sensitive cookie (like a session identifier, authentication token, or CSRF token) over an HTTPS connection but fails to set the Secure attribute on that cookie. Without the Secure flag, the browser might transmit the cookie over subsequent unencrypted HTTP requests to the same domain (e.g., if the user manually types http:// or clicks an http:// link). An attacker eavesdropping on the network (e.g., on public Wi-Fi) could then intercept this cookie and potentially hijack the user’s session. 🍪🔓➡️👂

​
Business Impact

Failure to set the Secure flag on sensitive cookies transmitted over HTTPS undermines the protection offered by TLS/SSL:
  • Session Hijacking: Attackers sniffing network traffic can steal session cookies sent over HTTP, allowing them to impersonate the user.
  • Exposure of Sensitive Tokens: Other sensitive information stored in cookies (like CSRF tokens or user preferences linked to identity) can be exposed.
  • Compliance Issues: Many security standards (like PCI-DSS) require the Secure flag for cookies handling sensitive data.

Reference Details

CWE ID: CWE-614 OWASP Top 10 (2021): A05:2021 - Security Misconfiguration Severity: Medium

​
Framework-Specific Analysis and Remediation

This is almost always a configuration issue. Modern web frameworks typically provide settings to enforce the Secure flag globally for session cookies, especially in production environments (often linked to HTTPS redirection settings). The vulnerability arises when these settings are disabled, misconfigured, or when developers set custom sensitive cookies manually without including the Secure flag. Remediation:
  1. Enforce HTTPS: Ensure your entire application runs exclusively over HTTPS (see CWE-319).
  2. Configure Secure Cookies: Set the framework’s configuration option to always add the Secure flag to session cookies in production.
  3. Set Flag on Custom Cookies: When creating custom cookies containing sensitive data, explicitly add the Secure attribute.
  • Python
  • Java
  • .NET(C#)
  • PHP
  • Node.js
  • Ruby

​
Framework Context

Controlled by SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE in Django settings.py. Flask requires manual setting or configuration via extensions.
# settings.py (Production)
# DANGEROUS: Session cookie will be sent over HTTP if user visits an HTTP URL.
SESSION_COOKIE_SECURE = False
# Also dangerous for CSRF token:
CSRF_COOKIE_SECURE = False
# Even if SECURE_SSL_REDIRECT = True, a misconfiguration or temporary
# availability over HTTP could leak the cookie.

# app.py (Flask)
from flask import make_response

@app.route('/set-auth-token')
def set_auth_token():
    token = generate_sensitive_token() # Assume this generates a token
    response = make_response("Token Set")
    # DANGEROUS: Secure flag is missing. Cookie will be sent over HTTP.
    response.set_cookie('auth_token', token, httponly=True, samesite='Strict')
    return response

​
Mitigation and Best Practices

  • Django: Set SESSION_COOKIE_SECURE = True and CSRF_COOKIE_SECURE = True in your production settings.py.
  • Flask: When using response.set_cookie, explicitly set secure=True. Configure session extensions (like Flask-Session) to set the secure flag.

​
Secure Code Example

# settings.py (Django Production - Secure)
# SECURE: Ensure cookies are only sent over HTTPS.
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
# Assumes HTTPS is enforced via SECURE_SSL_REDIRECT = True or proxy config.

# app.py (Flask - Secure Custom Cookie)
from flask import make_response, request

@app.route('/set-auth-token-secure')
def set_auth_token_secure():
    token = generate_sensitive_token()
    response = make_response("Token Set")
    # SECURE: Added secure=True. Flag only effective if site is accessed via HTTPS.
    # Use request.is_secure or config to determine if secure should be True.
    is_https = request.is_secure or request.headers.get('X-Forwarded-Proto', 'http') == 'https'
    response.set_cookie('auth_token', token,
                       httponly=True,
                       samesite='Strict',
                       secure=is_https) # Set secure based on connection
    return response

​
Testing Strategy

Access your site over HTTPS. Use browser developer tools (Application/Storage tab) to inspect the session cookie (sessionid, csrftoken) and any custom sensitive cookies. Verify that the “Secure” column/flag is checked/true. Try accessing an HTTP version of a page (if HTTPS redirection isn’t perfectly enforced) and see if the cookie is still sent (it shouldn’t be if Secure is set).