Mixed Content: The Hidden HTTPS Vulnerability

You've deployed your site over HTTPS, obtained valid certificates, and watched the padlock appear in browsers. Your site is secure, right? Not necessarily.

A critical vulnerability lurks in many HTTPS deployments: mixed content. When an HTTPS page loads resources (scripts, images, stylesheets, iframes) over unencrypted HTTP connections, the security guarantees of HTTPS are fundamentally compromised.

Mixed content is particularly insidious because it's invisible to casual users, may only appear under specific conditions, and can completely undermine the authentication and encryption HTTPS provides. Understanding and preventing mixed content is essential for any engineer deploying secure web applications.

In this comprehensive exploration, we'll dissect the mixed content problem—what it is, why it's dangerous, how browsers protect against it, and how to detect and eliminate it from your applications.

Mixed content occurs when an initial HTML document is loaded securely over HTTPS, but that document then loads sub-resources (scripts, stylesheets, images, videos, iframes, etc.) over insecure HTTP connections.

The Fundamental Problem:

HTTPS provides three guarantees:

1. Confidentiality: Encrypted data can't be read by network observers
2. Integrity: Modified data will be detected and rejected
3. Authenticity: You're communicating with the intended server

Mixed content breaks all three guarantees for the HTTP resources:

https://secure-bank.com/dashboard
    │
    ├── loads https://secure-bank.com/app.js    ✓ Protected
    ├── loads https://secure-bank.com/style.css ✓ Protected
    │
    └── loads http://cdn.example.com/widget.js  ✗ EXPOSED!
              ↑
              Man-in-the-middle can:
              - Read all data in this request
              - Modify the response (inject malicious code)
              - Impersonate the resource server

Why Does Mixed Content Exist?

Mixed content typically appears due to:

1. Legacy Integration: Old code written before HTTPS became universal
2. Third-Party Resources: CDNs, analytics, ads that only support HTTP
3. Hardcoded URLs: http:// explicitly written in HTML/CSS/JS
4. User-Generated Content: Users pasting HTTP links
5. Backend-Generated URLs: Server code constructing HTTP URLs
6. Protocol-Relative URLs: //example.com/resource on HTTP sites later migrated to HTTPS

Request Flow Comparison:

Not all mixed content is equally dangerous. Browsers distinguish between two categories based on the potential impact of compromise:

Active Mixed Content (High Risk)

Active mixed content can modify the DOM, execute code, or interact with the page. Compromise of active content gives attackers full control of the page.

Blocked by default in all modern browsers.

Passive (Display) Mixed Content (Lower Risk)

Passive mixed content cannot execute code or directly access page content. The impact of compromise is limited to the content itself.

May be loaded with warnings, or blocked in stricter modes.

Why the Distinction?

Browsers make this distinction for practical migration reasons:

1. Active content is always blocked — The risk is too high to allow any execution
2. Passive content may be allowed with warnings — Enables gradual migration without completely breaking sites
3. Upgradeable resources — Some browsers automatically upgrade HTTP to HTTPS for certain resources

The Evolution:

Modern browsers (Chrome 80+) attempt to auto-upgrade passive mixed content to HTTPS. If the HTTPS version fails, the resource is blocked.

Browsers implement sophisticated mixed content protection, but behavior varies across browsers and evolves over time.

Chrome Mixed Content Behavior (2024):

1. Active Mixed Content: Blocked unconditionally, console error
2. Mixed Images: Auto-upgraded to HTTPS, blocked if fails
3. Mixed Audio/Video: Auto-upgraded to HTTPS, blocked if fails
4. Mixed Downloads: Blocked for dangerous file types (exe, dmg, etc.)

Visual Indicators:

🔒 Secure (HTTPS, no mixed content)
     → "Connection is secure" in address bar

⚠️  Not Secure (mixed content detected)
     → Warning triangle, "Not secure" or "Mixed content"

🔓 Not Secure (HTTP page or severe issues)
     → "Not secure" prominently displayed

Console Errors and Warnings:

// Active mixed content (script)
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, 
but requested an insecure script 'http://cdn.example.com/widget.js'. 
This request has been blocked; the content must be served over HTTPS.

// Passive mixed content (image, before auto-upgrade)
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, 
but requested an insecure image 'http://cdn.example.com/photo.jpg'. 
This content should also be served over HTTPS.

// Auto-upgrade notification
Automatically upgrading a mixed content request from 
'http://cdn.example.com/photo.jpg' to 'https://cdn.example.com/photo.jpg'

Firefox Behavior:

Similar to Chrome with some differences:

• Uses shield icon to indicate blocked content
• "Enable Protection" / "Disable Protection" toggle in URL bar
• Settings page for per-site exceptions (not recommended)

Safari Behavior:

• Blocks all active mixed content
• Blocks mixed video/audio
• May load mixed images with warnings in some contexts

Mixed Content in Different Contexts:

The upgrade-insecure-requests Directive:

CSP can instruct browsers to upgrade all requests:

Content-Security-Policy: upgrade-insecure-requests

This tells the browser to automatically rewrite all HTTP URLs to HTTPS before making requests. Unlike browser auto-upgrade, this applies to ALL resources, not just passive content.

Finding all mixed content in a web application requires systematic detection across multiple sources.

Method 1: Browser Developer Tools

The most immediate approach—check the console after loading pages over HTTPS:

1. Open DevTools (F12)
2. Navigate to Console tab
3. Filter by "Mixed Content" or look for warnings
4. Check Network tab for HTTP requests
   - Filter: "scheme:http" or look for 🔓 icons

Limitations: Only detects mixed content on pages you visit, doesn't catch dynamic content or edge cases.

Method 2: Content Security Policy Reporting

Deploy CSP in report-only mode to collect violations:

Content-Security-Policy-Report-Only: 
  default-src https:;
  report-uri https://example.com/csp-reports;
  report-to csp-endpoint;

Report-To: {
  "group": "csp-endpoint",
  "max_age": 86400,
  "endpoints": [
    { "url": "https://example.com/csp-reports" }
  ]
}

Browsers will report violations without blocking, allowing you to discover mixed content from real user traffic.

CSP Report Format:

{
  "csp-report": {
    "document-uri": "https://example.com/page",
    "violated-directive": "img-src https:",
    "blocked-uri": "http://cdn.example.com/image.jpg",
    "line-number": 42,
    "source-file": "https://example.com/app.js"
  }
}

Method 3: Automated Scanners

Tools that crawl your site and identify mixed content:

# WebPageTest (includes mixed content detection)
https://www.webpagetest.org

# SSL Labs (certificate check + mixed content)
https://www.ssllabs.com/ssltest/

# Why No Padlock (targeted mixed content finder)
https://www.whynopadlock.com/

# Lighthouse (Chrome DevTools or CLI)
lighthouse https://example.com --output json

Method 4: Source Code Analysis

Grep for HTTP URLs in your codebase:

# Find hardcoded HTTP URLs in code
grep -rn 'http://' --include='*.html' --include='*.js' --include='*.css' .

# More targeted search
grep -rn 'src="http://' --include='*.html' .
grep -rn "src='http://" --include='*.html' .
grep -rn 'url(http://' --include='*.css' .

Once mixed content is identified, remediation follows a systematic approach. The strategy depends on the source of the mixed content.

Strategy 1: Use Protocol-Relative URLs (Transitional)

<!-- Instead of -->
<script src="http://cdn.example.com/lib.js"></script>

<!-- Use -->
<script src="//cdn.example.com/lib.js"></script>

Protocol-relative URLs inherit the page's protocol. On HTTPS pages, they become HTTPS requests.

⚠️ Warning: This is a transitional solution. If the HTTPS version doesn't exist, this will break. Modern best practice is explicit HTTPS.

Strategy 2: Use Explicit HTTPS URLs (Recommended)

<!-- Best practice: explicit HTTPS -->
<script src="https://cdn.example.com/lib.js"></script>
<img src="https://images.example.com/photo.jpg">
<link rel="stylesheet" href="https://example.com/style.css">

This is the most reliable approach—ensures HTTPS is always used, fails loudly if HTTPS isn't available.

Strategy 3: Update Server URL Generation

Backend code often constructs URLs. Ensure HTTPS is used:

# Python/Django
from django.contrib.sites.models import Site

# Bad: may return HTTP
site = Site.objects.get_current()
url = f"http://{site.domain}/path"  

# Good: use request scheme or force HTTPS
url = request.build_absolute_uri('/path')  # Uses request's scheme
url = f"https://{site.domain}/path"  # Explicit HTTPS

// Node.js/Express
// Bad
const url = `http://${req.headers.host}/path`;

// Good: check for HTTPS or X-Forwarded-Proto
const protocol = req.secure || req.headers['x-forwarded-proto'] === 'https' 
  ? 'https' : 'http';
const url = `${protocol}://${req.headers.host}/path`;

// Best: always use HTTPS in production
const url = `https://${req.headers.host}/path`;

Strategy 4: Configure CDNs and Third Parties

Ensure all external services support HTTPS:

CDN Configuration:
├── Verify SSL/TLS is enabled on CDN
├── Update CDN origin to use HTTPS
├── Force HTTPS in CDN settings
└── Update all CDN URLs in application

Third-Party Services:
├── Google Analytics: Already HTTPS
├── Font services: Use HTTPS URLs
├── Ad networks: Contact for HTTPS support
└── Widgets: Update embed codes

Strategy 5: Use CSP upgrade-insecure-requests

For sites with many HTTP references, CSP can auto-upgrade:

# Upgrade all HTTP requests to HTTPS
Content-Security-Policy: upgrade-insecure-requests

How it works:

1. Browser intercepts all resource requests
2. HTTP URLs are rewritten to HTTPS
3. Request is made to HTTPS version
4. If HTTPS fails, request fails (no fallback to HTTP)

This is a transition tool, not a permanent solution—fix the underlying URLs.

Strategy 6: Handle User-Generated Content

User content (comments, profiles, CMS entries) may contain HTTP links:

// Sanitize on input or output
function sanitizeContent(html) {
  // Replace HTTP with protocol-relative for same-site resources
  return html.replace(
    /src=["']http:\/\/example\.com\//g,
    'src="https://example.com/'
  );
}

// Or convert all image sources to HTTPS
function upgradeImageUrls(html) {
  return html.replace(
    /<img([^>]*)src=["']http:\/\//gi,
    '<img$1src="https://'
  );
}

For truly external HTTP images, consider:

• Proxy through your HTTPS server
• Replace with placeholder indicating insecure content
• Store copies of images on your HTTPS CDN

Content Security Policy (CSP) provides the most robust defense against mixed content by explicitly declaring what sources are permitted for each resource type.

Basic HTTPS-Enforcing CSP:

Content-Security-Policy: default-src https:; script-src https:; style-src https:; img-src https: data:; font-src https: data:;

This policy:

• Allows all resources ONLY from HTTPS sources
• Includes data: URIs for inline images and fonts (common requirement)
• Blocks any HTTP resources

Strict CSP with Specific Sources:

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' https://cdn.example.com;
  style-src 'self' https://fonts.googleapis.com;
  img-src 'self' https://images.example.com data:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
  frame-src https://www.youtube.com;
  base-uri 'self';
  form-action 'self';

CSP Directives for Mixed Content:

block-all-mixed-content vs upgrade-insecure-requests:

# Block approach: any HTTP request fails
Content-Security-Policy: block-all-mixed-content

# Upgrade approach: try HTTPS first, fail if unavailable  
Content-Security-Policy: upgrade-insecure-requests

upgrade-insecure-requests is generally preferred—it provides a migration path while still ensuring security.

Implementing CSP:

# Nginx
add_header Content-Security-Policy "default-src https:; upgrade-insecure-requests;" always;

# Report-only mode for testing
add_header Content-Security-Policy-Report-Only "default-src https:; report-uri /csp-reports;" always;

// Express.js using helmet
const helmet = require('helmet');

app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'", "https:"],
    scriptSrc: ["'self'", "https://cdn.example.com"],
    imgSrc: ["'self'", "https:", "data:"],
    upgradeInsecureRequests: [],
  },
}));

<!-- Meta tag (limited, can't use report-uri) -->
<meta http-equiv="Content-Security-Policy" 
      content="default-src https:; upgrade-insecure-requests;">

Mixed content detection and prevention has several edge cases that can trip up even experienced developers.

The Referrer-Policy Interaction:

When following HTTP links from HTTPS pages, the Referrer header behavior depends on Referrer-Policy:

# Strict: no referrer to HTTP destinations
Referrer-Policy: strict-origin-when-cross-origin

# With this policy:
https://example.com → https://other.com → Referrer: https://example.com/
https://example.com → http://other.com  → Referrer: (none)

This is a security feature—HTTPS page URLs shouldn't leak to HTTP destinations.

The <base> Tag Trap:

<!-- If your page has -->
<base href="http://example.com/">

<!-- Then relative URLs become HTTP -->
<script src="/app.js"></script>  <!-- Becomes http://example.com/app.js -->

Ensure <base> tags use HTTPS or remove them entirely.