Rule Details

Mixed content occurs when an HTTPS page loads resources over HTTP. The browser has established a secure channel to your server, but part of the page data arrives over an unencrypted connection — potentially modified by a network attacker.

Code Examples

Active Mixed Content (Blocked)

Resources that can access and modify the page DOM are classified as active mixed content and are blocked by all modern browsers:

• <script src="http://...">
• <link rel="stylesheet" href="http://...">
• <iframe src="http://...">
• XMLHttpRequest / fetch() to http:// URLs
• <object data="http://...">

❌ Blocked — attacker can inject scripts into your HTTPS page
<script src="http://cdn.example.com/analytics.js"></script>
 
✅ Correct
<script src="https://cdn.example.com/analytics.js"></script>

Passive Mixed Content (Warned or Upgraded)

Resources that cannot directly modify page content are passive mixed content. Modern browsers (Chrome 81+) auto-upgrade these to HTTPS and block them if the HTTPS version doesn't exist:

• <img src="http://...">
• <audio src="http://...">
• <video src="http://...">

⚠️ Will be upgraded to HTTPS by Chrome (blocked if no HTTPS version exists)
<img src="http://example.com/photo.jpg" alt="Photo">
 
✅ Correct
<img src="https://example.com/photo.jpg" alt="Photo">

Why It Matters

Active mixed content (scripts loaded over HTTP into an HTTPS page) gives network attackers the ability to execute arbitrary JavaScript on your page — the same power as XSS, despite the page itself being served over HTTPS.

Fix: Update All HTTP URLs

Search for HTTP Resources

# Find http:// references in HTML, CSS, JS files
grep -r 'http://' ./src --include="*.html" --include="*.css" --include="*.js" --include="*.jsx" --include="*.tsx"
 
# Focus on resource attributes
grep -rE 'src="http://|href="http://|url\(http://' ./src

Common Locations

1. HTML templates — <script>, <link>, <img>, <iframe> attributes
2. CSS files — url() in background-image, @import, @font-face
3. JavaScript — hardcoded API endpoints, CDN URLs
4. CMS content — database-stored content with old HTTP asset URLs

Fix: CSP upgrade-insecure-requests

The upgrade-insecure-requests directive tells the browser to upgrade all HTTP sub-resource requests to HTTPS before fetching them. This is especially useful when you have legacy content in a database with hardcoded HTTP asset URLs.

Content-Security-Policy: upgrade-insecure-requests

<!-- Equivalent meta tag (not recommended for CSP security headers, but works for upgrade-insecure-requests) -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Nginx

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Next.js

// next.config.js
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: 'upgrade-insecure-requests',
          },
        ],
      },
    ]
  },
}

Detecting Mixed Content

Browser DevTools

Open Chrome or Firefox DevTools in the Console tab. MDN's mixed content guide (opens in new tab) and web.dev's remediation guide (opens in new tab) both show the same browser error pattern:

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

Automated Tools

• Why No Padlock? (free online scanner)
• SSL Checker
• Chrome Lighthouse audit (Network tab)

# Lighthouse CLI
npx lighthouse https://example.com --only-categories=best-practices --output=json \
  | jq '.audits["mixed-content"]'

Exceptions

• Local development or internal-only environments can differ, but production user-facing traffic should still satisfy the transport requirement strictly.
• A redirect or HTTPS control that fails on one hostname, subdomain, or CDN edge path is still a real failure for users and crawlers reaching that surface.
• Fix the strongest transport weakness first instead of treating every downstream symptom as a separate primary issue.

Verification

Automated Checks

• Test the affected flow in a production-like environment, not just local development.
• Document any intentional exceptions explicitly.

Manual Checks

• Inspect the final HTTP response or browser behavior to confirm the control is actually enforced.
• Verify third-party integrations or embeds still work after the restriction is applied.