Mixed Content (HTTP subresources on an HTTPS page)

Mixed content occurs when a page delivered over HTTPS includes subresources fetched over plain HTTP. Browsers distinguish two kinds. Active (blockable) mixed content, such as scripts, stylesheets, iframes and fetch or XHR requests, can change the whole page, so browsers block it. Passive (upgradable) content, such as images, audio and video, is automatically retried over HTTPS by current Chrome and Firefox versions and simply not loaded if that fails.

Why it matters

An attacker who can modify a single HTTP script controls the HTTPS page that loads it, including its forms and any cookies not marked HttpOnly. Users see a missing or warning padlock, and features break because blocked resources never load. Typical causes are hard-coded http:// URLs in templates or CMS content, old third-party widgets, and applications moved behind an HTTPS reverse proxy that still believe they run on HTTP and therefore generate http:// links.

Example

Find hard-coded HTTP references, or run the mixed content scanner:

curl -s https://example.com | grep -oE '(src|href)="http://[^"]+"'

Fix URLs at the source; as a safety net, ask browsers to upgrade the rest:

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

Common misconceptions

• Mixed content is only a cosmetic padlock issue. For images that is close to true now that browsers auto-upgrade them, but mixed scripts or iframes hand control of the page to anyone on the network path.
• A redirect to HTTPS on the resource host fixes it. Browsers block active mixed content before the request is sent, so no redirect is ever seen; the URL in the page must change.
• HSTS fixes mixed content. HSTS only upgrades requests to hosts that sent the header; third-party HTTP resources are not covered.