Mixed Content on an HTTPS Page: Find and Fix HTTP Resources

In one paragraph

Mixed content on an HTTPS page means the document references resources through insecure URLs. Browsers block some requests and automatically upgrade others, so a working-looking page can still contain outdated references. Replace the insecure URLs at their source, confirm the destinations support valid HTTPS, and test both the served HTML and requests initiated after JavaScript runs.

Why it matters

HTTPS protects a connection, not every resource a page might request. If a script or other dependency travels over an unencrypted channel, a network attacker can potentially observe or modify it. Browser mixed-content rules reduce that risk, but can leave the application with missing functionality.

Current terminology distinguishes upgradable from blockable content. Some image, audio, and video requests can be upgraded to HTTPS; scripts, stylesheets, frames, and other request contexts are generally blocked instead. Exceptions matter: an image using srcset or an IP-address URL does not necessarily receive the same handling as a simple domain-based img src. Do not assume every image is silently repaired.

An ordinary top-level navigation to an HTTP site is a different situation from an insecure subresource loaded into the HTTPS document. Avoid rewriting every outbound reference without understanding its purpose.

How WebAuditOS evaluates this finding

The supplied check inspects HTTPS HTML for http:// references in img src, script src, stylesheet links, and iframe src. It can use an image's data-src when src is absent. A recognised insecure reference fails; none passes. HTTP documents and unparseable HTML are not graded.

It reads source markup, not the full browser request graph. srcset, CSS resources, media sources, scripted fetches, and runtime-injected URLs are outside the described coverage. Its literal case-sensitive match can also miss differently cased schemes. A pass is not proof that the complete rendered page has no mixed content.

How to fix it

1. Locate the quoted URL in the page source and identify its owner: template, CMS record, plugin setting, stylesheet, or external embed. Fix the producer rather than only the final rendered string.
2. Open the intended HTTPS resource directly and confirm a valid certificate, correct response, and acceptable redirects. Simply changing the scheme cannot make an HTTP-only provider support TLS.
3. For external resources, use an explicit supported HTTPS URL. For same-origin resources, a root-relative path can be suitable when the document's base URL resolves it as intended. Review any base element rather than assuming every relative reference stays on the page's origin.
4. Search stored CMS content as well as code. In WordPress, a platform-aware search-replace tool can preserve serialised values. Back up first, run a dry run where available, and inspect a sample before changing the production database.
5. Consider CSP upgrade-insecure-requests as a transitional browser-side backstop, not a replacement for clean source references:

Content-Security-Policy: upgrade-insecure-requests

Integrate this directive with your existing policy deliberately. It cannot make a destination with no working HTTPS succeed, and the source-markup check can continue reporting the original HTTP URL.

6. Reload with the browser Console and Network panel open. Exercise menus, forms, lazy-loaded media, account screens, and relevant embeds. Inspect runtime requests and downloads as well as the four source patterns the scanner recognises.
7. Clear appropriate content caches after correcting the source, then rescan the exact affected pages. Retain browser tests on each major template so the warning does not return through an old widget.

What the fix can break

A newly secure URL can fail because of certificate, hostname, CORS, or provider limitations that the HTTP version did not encounter. Replace unsupported dependencies rather than re-enabling unsafe loading.

Bulk replacements can corrupt data or alter examples and intentionally external links. Review what is being changed and use platform-supported tools.

An auto-upgraded resource can make the page appear fixed while stale markup remains. Conversely, a source-level pass can miss a background image or API call. Treat source review and browser verification as complementary tests.

Questions

Why does the page look fine despite this finding?

The browser may have upgraded a resource, or a lazy-loaded reference may not have been used yet. Check the actual URL in the evidence.

Can mixed content exist in CSS or JavaScript?

Yes. Source-tag inspection alone does not cover the complete request graph. Use browser tools to inspect resource and API requests after interaction.

Are protocol-relative URLs the preferred fix?

Use explicit HTTPS for new external references when possible. Protocol-relative references can inherit an insecure scheme in another context and are less clear.

What should I review next?

Review HTTPS availability, redirects, and the security headers guide.