Mixed Content

Mixed content is when an HTTPS page loads sub-resources over plain HTTP. The page itself is encrypted, but anyone on the network path can intercept and modify the unencrypted resources. This breaks the security guarantees of HTTPS: an attacker can inject malicious JavaScript, swap images, or hijack iframe navigation while the user's browser still shows a padlock. Modern browsers block active mixed content (scripts, stylesheets, iframes) outright and warn about passive (images, audio, video).

How the check works

Per primary HTTPS host, the check parses the HTML response and tallies references with explicit http:// URLs. Two categories:

• Active mixed content: scripts, stylesheets, iframes, web workers, fetch/XHR. These execute or apply rules; an injected version takes over the page. Browsers BLOCK these on HTTPS pages.
• Passive mixed content: images, audio, video, object/embed. These do not execute scripts but still leak content and trigger browser warnings.

Per-host scores:

• No mixed content: 1.0 (pass).
• Passive only: 0.6 (warn). Reason: passive_mixed_content.
• Any active: 0.0 (fail). Reason: active_mixed_content.
• Page served over HTTP: not applicable (mixed content only matters on HTTPS pages).

How the verdict maps to evidence

• Pass: no http:// resources on any HTTPS primary host.
• Warn: passive mixed content (images, audio, video over HTTP) on at least one host.
• Fail: any active mixed content (scripts, stylesheets, iframes over HTTP).
• Not applicable: page served over HTTP (the check defers; you have a deeper HTTPS Consistency problem).

Evidence shows mixed_active and mixed_passive counts per host.

Special states

• Not Applicable: primary serves HTTP (fix HTTPS Consistency first), or default/empty placeholder.
• Degraded: probe data unavailable.

Fix: upgrade every http:// to https:// (or relative)

1. Audit and replace hardcoded http:// references

Mixed content almost always comes from hardcoded URLs in templates or content. Find them:

grep -rE 'http://[^"'\"]+' \
  --include='*.html' --include='*.tsx' --include='*.jsx' \
  --include='*.vue' --include='*.svelte' --include='*.tmpl' \
  --include='*.twig' --include='*.erb' --include='*.php' .

# Also check CSS:
grep -rE 'url\(["\']?http://' --include='*.css' --include='*.scss' .

Replace each with https:// (if the resource is HTTPS-available) or with a protocol-relative URL (//). Protocol-relative URLs inherit the page's scheme; on an HTTPS page they load over HTTPS. They are deprecated in modern usage in favor of explicit https://, but still work everywhere.

2. Add Content-Security-Policy: upgrade-insecure-requests

This CSP directive tells the browser to automatically upgrade every http:// request on the page to https:// before issuing it. A safety net for mixed content that escapes hand-audit:

Content-Security-Policy: upgrade-insecure-requests; default-src 'self' https:

If the upgraded URL does not actually exist over HTTPS, the request fails (rather than fallback to HTTP). That is the point: better a broken image than a man-in-the-middle. See the CSP fix in Web Application Security for full setup.

3. Sanitize user-uploaded content

If users can post HTML (rich-text editors, comment systems, forum software, CMS pages), you may be picking up mixed content from user input. Sanitize on save:

• Run user HTML through an allow-list sanitizer (DOMPurify in browser, html-sanitizer / Bleach in Python, sanitize-html in Node). Configure to rewrite http:// to https:// on src and href attributes.
• Validate uploads: when users paste image URLs in a CMS, validate the URL is HTTPS before accepting.
• Audit existing content. Run a one-time database query to find http:// in stored HTML and rewrite it.

Per-CMS quick fixes

• WordPress: Better Search Replace plugin to rewrite http://yourdomain.tld to https://yourdomain.tld site-wide. Add the upgrade-insecure-requests CSP. Wordfence and Really Simple SSL also auto-rewrite mixed content.
• Drupal: drush php-eval 'db_query(...)' or contrib modules like Convert Mixed Content. Add CSP via the security_kit module.
• Webflow / Squarespace / Wix: most modern hosted CMSs sanitize this automatically on saves; check for hardcoded http:// in custom code blocks.
• Static site generators: grep your source for http:// during build; many have CI lint rules to catch mixed content before deploy.

Verify the fix

• Open the page in Chrome DevTools → Console. Mixed content blocks log explicitly with the resource URL and what the browser did (blocked vs warned).
• DevTools → Network: filter by mixed (or look for items with http:// scheme on an HTTPS page).
• https://www.whynopadlock.com or similar tools fetch your page and report any mixed content with line numbers.
• curl -sL https://yourdomain.tld | grep -oE 'http://[^"'\"]+' lists candidate http:// URLs in the response.
• Re-run the RedScore lookup. The score recovers as soon as the mixed content is removed.

Common pitfalls

• Padlock icon stays after fixing one item but more remain. Browsers downgrade the indicator if ANY mixed content is present. Fix every reference.
• upgrade-insecure-requests masking real broken links. The directive auto-upgrades, but if the upgraded URL does not exist over HTTPS, it 404s silently. Audit your sources too.
• Third-party widgets serving HTTP content. Some embedded widgets (older payment forms, ad networks, video players) load assets over HTTP. The check counts them. Either replace the widget, contact the vendor for HTTPS support, or block the widget.
• data: URLs counted as mixed content. They should not be; the check only flags explicit http:// scheme. If you see false positives, file an issue.
• WebSocket connections. ws:// on an HTTPS page is mixed content. Use wss:// instead.
• Mixed content in iframes. The parent page's scheme matters; if the iframe is HTTP and parent is HTTPS, the iframe content is active mixed content and gets blocked. Use HTTPS iframe sources.