Your page is HTTPS, but is everything on it? Mixed content, explained

The padlock in the address bar says the page came over HTTPS. That's true, and it's also not the whole story. A page can load over a perfectly good encrypted connection and then turn around and pull a script, an image, or a form target over plain HTTP. The padlock doesn't change. The protection does.

That's mixed content: a secure page mixing in insecure resources. It's easy to ship without noticing, because the page works fine and looks fine, and the gap only opens when someone is sitting on the network between your visitor and the HTTP resource.

Active versus passive, and why one is far worse

Not all mixed content is equal, and the difference decides how much you should care. The split is about what the insecure resource can do once it loads.

Active mixed content is a script, an iframe, a stylesheet, or anything that can execute or control the page, loaded over HTTP. This is the dangerous one. If an attacker on the network swaps the HTTP response, they're not changing a picture, they're injecting code that runs with full access to your HTTPS page: reading the DOM, stealing non-HttpOnly cookies, capturing what users type. Passive mixed content is an image, an audio file, or a video over HTTP. Less severe, because the worst an attacker can do is change what the user sees, but it still breaks the page's integrity and most browsers flag it. The third case is a form that submits over HTTP: the page is encrypted, but the data the user types gets sent in the clear, which defeats the point on exactly the data that matters.

How it sneaks in

You rarely write http:// on purpose. It arrives through the back door.

A hardcoded http:// URL in a third-party widget's embed code. A protocol left off and then resolved wrong. A legacy CDN reference that never got updated when you moved to HTTPS. A <form action="http://..."> copied from an old integration. A site migrated to HTTPS years ago can still carry a handful of these in corners nobody revisits: an old analytics snippet, a font loader, an image host. The page loads, the browser may quietly upgrade or block some of it, and the ones that slip through are invisible until you go looking. This is a cousin of serving the page over plain HTTP in the first place; there the whole page is exposed, here it's one resource, but the interception mechanism is identical.

The fix is to make everything HTTPS, and let the browser enforce it

First, find and change the http:// references to https:// (or protocol-relative, but absolute https:// is clearer). Most resources you load already have an HTTPS version; it's just the URL that's stale.

Then add a header that turns "please" into "must": Content-Security-Policy: upgrade-insecure-requests tells the browser to automatically rewrite HTTP subresource requests to HTTPS, and block-all-mixed-content makes it refuse any that can't be upgraded. With those in place, a stray http:// reference gets fixed or blocked by the browser instead of silently downgrading.

<!-- secure page, insecure script -->
<script src="http://cdn.example.com/widget.js"></script>
<form action="http://yoursite.com/subscribe">

<!-- no CSP upgrade rule, the http:// requests go out -->

The header is the backstop, not the fix. Fix the URLs so the page is clean on its own, and keep the header so the next stray reference someone pastes in gets caught automatically.

Which of your subresources load over HTTP is visible in the HTML and assets you serve, so it's checkable from outside without touching your backend. SurfaceCheckr fetches your pages, looks at every script, iframe, stylesheet, image, and form target, and flags the ones pointing at http://, separating the active cases that can run code from the passive ones that can't and the forms that leak input. We read what the page references; we don't sit on anyone's network or intercept anything, because that would be active and we stay passive. The list of insecure references on your secure pages is the finding, and it's usually a short, fixable one that's been hiding behind a padlock that looked fine.