Mixed Content Scanner

How this check works

Scanaris reads the HTML of your page served over HTTPS and looks for references to resources starting with http://: scripts, stylesheets, iframes, images, video, audio and fonts. It splits them into two groups. Active mixed content (scripts, styles, iframes) opens a medium-severity finding, because those resources can run code or change the page. Passive mixed content (images, video, audio) opens a low-severity one: it runs nothing, but it travels unencrypted and breaks the padlock. Only references in the initial HTML are reviewed; resources added later by JavaScript are not seen this way.

Why it matters

A script loaded over HTTP inside an HTTPS page is the worst case: whoever controls the network can swap it for another and run whatever they want in your page, with the user's session. That is why modern browsers block it outright, and your site silently breaks in that part. For images, the browser loads them but removes the padlock or shows a "not secure" warning, which is what the user sees. In both cases the message is the same: the page claims to be secure and is not entirely.

Where it comes from

Almost always from old code: URLs copied from a tutorial or a years-old template, a library linked from a CDN that had no HTTPS back then, images from a migrated blog, or a database field with the full URL of an image uploaded when the site still ran over HTTP. In WordPress it is typical after switching from HTTP to HTTPS without updating the stored URLs.

How to fix it

• Change the references to https:// or to relative paths (/images/photo.jpg), which inherit the page's protocol. It is the correct and definitive fix.
• If an external resource has no HTTPS, download it and serve it from your domain, or find another source. In 2026 almost nothing legitimate is still HTTP-only.
• In WordPress, update the URLs stored in the database with a search-and-replace tool that respects serialization, and review the site URLs in the general settings.
• As a safety net, the CSP directive upgrade-insecure-requests tells the browser to automatically turn your page's http:// requests into https://. It helps while you clean up the code, but it does not replace the clean-up: the resource must exist over HTTPS for it to work.

Content-Security-Policy: upgrade-insecure-requests

Check it is fixed

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

Nothing should come out. Then open the page with the browser console: any mixed resource loaded by JavaScript shows up there as a warning or a block.

Frequently asked questions

My page loads fine and has the padlock. Why is it flagged?

Because the browser may be blocking the resource silently or upgrading it to HTTPS on its own. The reference in your HTML is still http:// and other clients (bots, older browsers, email) do not make that correction.

Are URLs starting with // mixed content?

No. Protocol-relative URLs inherit the page's protocol and load over HTTPS on HTTPS. Even so, writing https:// directly is the recommendation today.

Does an <a href="http://…"> link count?

No. A link loads nothing into your page; it only takes the user elsewhere. Mixed content is what the page embeds.