Skip to main content

​
Overview

This vulnerability occurs when an application transmits sensitive data, such as passwords, session tokens, or personal information, over an unencrypted channel (like HTTP). An attacker on the same network (e.g., public Wi-Fi) can “sniff” this traffic and steal the data, leading to account compromise or data breaches.

​
Business Impact

Transmitting data in cleartext is a critical failure of confidentiality. It can lead to the widespread theft of user credentials, session hijacking, and the exposure of all data your application handles. This directly violates compliance standards like PCI-DSS and GDPR, leading to severe fines and a complete loss of user trust.

Reference Details

CWE ID: CWE-319 OWASP Top 10 (2021): A02:2021 - Cryptographic Failures Severity: High

​
Framework-Specific Analysis and Remediation

This is a deployment and configuration issue. The fix is to enforce HTTPS-only communication. This involves:
  1. Setting up a TLS/SSL certificate on your web server (e.g., Nginx, Apache) or load balancer.
  2. Configuring your application framework to redirect all HTTP traffic to HTTPS.
  3. Setting the Secure flag on all sensitive cookies.
  • Python
  • Java
  • .NET(C#)
  • PHP
  • Node.js
  • Ruby

​
Framework Context

This is controlled by SECURE_SSL_REDIRECT in settings.py. In a production deployment behind a reverse proxy (like Nginx), you must also ensure the proxy is configured to pass the correct headers.

​
Vulnerable Scenario 1: SECURE_SSL_REDIRECT = False

The application is deployed without SSL redirection, allowing users to access the site and submit forms over HTTP.
# settings.py (Production)

# DANGEROUS: The application will not redirect HTTP requests to HTTPS.
# If a user bookmarks or types "http://...", they will be insecure.
SESSION_COOKIE_SECURE = False
CSRF_COOKIE_SECURE = False
SECURE_SSL_REDIRECT = False

​
Vulnerable Scenario 2: Misconfigured Proxy

The SECURE_SSL_REDIRECT is True, but the reverse proxy (Nginx) doesn’t set the X-Forwarded-Proto header. Django won’t know it’s behind a secure connection and may cause a redirect loop or serve insecure content.
# /etc/nginx/sites-available/myapp

location / {
    proxy_pass [http://127.0.0.1:8000](http://127.0.0.1:8000);
    proxy_set_header Host $host;
    # DANGEROUS: Missing X-Forwarded-Proto header.
    # Django won't know the client connection is HTTPS.
}

​
Mitigation and Best Practices

In your production settings.py, set SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, and CSRF_COOKIE_SECURE to True. Configure your proxy to pass the X-Forwarded-Proto header and enable SECURE_PROXY_SSL_HEADER.

​
Secure Code Example

# settings.py (Production)

# SECURE: Tell Django to trust the proxy's header
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

# SECURE: Enforce HTTPS
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

# Optional: Enable HSTS for extra security
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True

# /etc/nginx/sites-available/myapp (Secure)

location / {
    proxy_pass [http://127.0.0.1:8000](http://127.0.0.1:8000);
    proxy_set_header Host $host;
    # SECURE: This header tells Django the connection is secure.
    proxy_set_header X-Forwarded-Proto $scheme;
}

​
Testing Strategy

Use a tool like curl -I http://your-domain.com. Assert that the response is a 301 Moved Permanently with a Location header pointing to https://your-domain.com. Also, check your session cookies in a browser to ensure the “Secure” flag is set.