Why does one http:// image break the whole page's security, not just that image?

Because that one request is unencrypted and unauthenticated, an attacker on the same network (public wifi, a compromised router) can intercept or alter it in transit - and depending on what it is (a script, in particular), that can compromise the rest of the page even though everything else loaded over HTTPS correctly.

Does the browser block mixed content automatically, or just warn?

It depends on the resource type. "Active" mixed content - scripts, stylesheets, iframes - is blocked outright by modern browsers. "Passive" mixed content - images, video, audio - is usually still loaded but triggers a broken-padlock warning in the address bar, which is exactly the kind of trust signal that makes visitors hesitate.

How does Scanverra find mixed content - does it just scan my HTML for http:// links?

No, it's stronger than that. Scanverra loads the page in a real browser and captures the actual network requests the page makes, then flags any request starting with http:// on a page served over https. That catches resources loaded dynamically by JavaScript, not just ones hardcoded in your markup.

Can I just add upgrade-insecure-requests and stop worrying about individual URLs?

It helps as a safety net - it tells the browser to automatically rewrite http:// requests to https:// before sending them - but it only works if the resource is actually available over HTTPS at that same host. It's a good backstop, not a substitute for fixing the hardcoded URLs.

How to Fix Mixed Content Warnings

Mixed content happens when a page served over HTTPS loads even one resource - a script, an image, a stylesheet, an iframe - over plain HTTP instead. That single unencrypted request undermines the security guarantee the rest of the page was making, and browsers respond by blocking the resource, breaking the padlock icon, or both.

Why Mixed Content Shows Up

Hardcoded http:// URLs left over from before an HTTPS migration. Old markup, CMS content, or a database of stored asset URLs written back when the site ran on plain HTTP and never updated.
Third-party embeds and widgets still serving over HTTP. An ad network, a comment widget, or an old analytics snippet that never migrated its own delivery to HTTPS.
CDN or asset host URLs missed during a protocol migration.The main domain moved to HTTPS, but a subdomain or third-party asset host serving images or fonts wasn't updated at the same time.
User-generated content with pasted HTTP links. A user submits content (a forum post, a product review, a CMS field) containing an http:// image or embed URL that gets rendered as-is.

How to Identify Every Instance

Scanverra detects mixed content by loading your page in a real browser and capturing its actual network activity - both the Browser Test and the security scan flag any request that starts with http://while the page itself is served over HTTPS. Because it's based on real captured network requests rather than a static scan of your HTML source, it catches resources loaded dynamically by JavaScript after the page renders, not just ones hardcoded directly in your markup.

How to Fix It

1. Replace hardcoded http:// URLs with https://

Before: a hardcoded http:// image URLtypescript

1<img src="http://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

After: served over https, or protocol-relative if the host supports bothtypescript

1<img src="https://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

2. Add upgrade-insecure-requests as a backstop

This CSP directive tells the browser to automatically rewrite any remaining http:// requests to https:// before sending them, catching URLs you missed - though it only works if the resource is genuinely reachable over HTTPS at that host:

Auto-upgrade any stray http:// request to https://typescript

1Content-Security-Policy: upgrade-insecure-requests

3. Audit third-party embeds specifically

Third-party scripts and widgets are the most common source of mixed content you don't directly control - check each one's documentation for an HTTPS embed URL, and remove any that don't offer one.

4. Sanitize or rewrite protocol in user-submitted content

If users can submit content containing URLs, rewrite http:// to https:// at render time (or reject the submission) rather than rendering whatever protocol was pasted in.

How Scanverra Detects This

Both Scanverra's Browser Test and its security scan capture your page's real network requests in a live browser and flag any that start with http:// on a page served over HTTPS - a genuine runtime check against actual traffic, not a text search of your source.