The fix, in one snippet
grep -rn 'http://' templates/ static/
# or force it at the edge:
Content-Security-Policy: upgrade-insecure-requestsIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now parses the HTML of the HTTPS homepage and collects every URL that begins with http:// in resource-loading positions. Active mixed content, rated high, covers <script src>, <link rel="stylesheet">, <iframe src>, <object> and <embed>. Passive mixed content, rated low, covers <img>, <audio>, <video>, <source> and poster attributes, plus url(http://...) inside inline styles. Protocol-relative URLs (//cdn.example) are fine and are not flagged. If the page's Content-Security-Policy contains upgrade-insecure-requests, the findings are downgraded to informational, because supporting browsers will rewrite the URLs before fetching. Form actions pointing to HTTP are a separate, higher-severity check: insecure-form-action. Scan.now reads the markup only; it does not fetch the insecure resources.
Why it matters
An HTTPS page that loads a script over HTTP is as exposed as a plain-HTTP page: whoever controls the network path can replace that script and run anything they like in the page's origin. Browsers have blocked active mixed content since 2015, so on modern clients the practical effect is that the feature silently breaks, and the padlock is downgraded or removed. Passive content is subtler. Chrome has automatically upgraded mixed images, audio and video to HTTPS since version 86 and blocks them if the upgrade fails; Firefox does the same since version 127. An attacker who can still serve a passive resource can swap an image (defacement, misinformation) or use the plaintext request to track the user, and the browser's security indicator changes, which trains users to distrust the padlock. Details and a triage method are in the mixed content guide.
How to fix it
Change the URLs. Relative or scheme-relative references are the durable fix:
<script src="/js/app.js"></script>
<script src="https://cdn.example.com/lib.js"></script>Find remaining references in a codebase or a database dump:
grep -rn 'http://' templates/ static/ | grep -v 'http://www.w3.org'WordPress sites usually need the site URL updated in Settings > General and a search-and-replace across post content; the Better Search Replace plugin or WP-CLI does it: wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid. As a safety net, tell browsers to upgrade any stragglers:
Content-Security-Policy: upgrade-insecure-requestsnginx: add_header Content-Security-Policy "upgrade-insecure-requests" always; (merge it into your existing CSP if you have one). Apache: Header always set Content-Security-Policy "upgrade-insecure-requests". Cloudflare's Automatic HTTPS Rewrites (SSL/TLS > Edge Certificates) rewrites http:// links to hosts known to support HTTPS as the HTML passes through the edge. After deploying, open the page with the browser console visible: every remaining mixed-content warning names the exact resource.
Where this fits
Mixed content (HTTP resources on an HTTPS page) is check 3 of 10 that the website vulnerability scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits JavaScript library with known vulnerabilities (high), where the page loads a JavaScript library version with published vulnerabilities. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Mixed content (HTTP resources on an HTTPS page) closes one route in. Immediately below it: Advertising and tracking endpoints, where which of the page's third-party hosts exist to advertise to the visitor or to follow them, matched against the EasyList and EasyPrivacy blocklists that also power our <a href="/ad-blocker">ad blocker</a>; CMS / generator version disclosure, where the page announces the CMS or static-site generator it was built with, usually including the version, in a meta tag, header or comment banner; Sensitive information in HTML comments, where hTML comments in the page source contain material that looks internal: Credentials, TODO notes, internal hostnames or IP addresses, file paths, or links to unpublished areas of the site.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Mixed content (HTTP resources on an HTTPS page) (high severity)
Scanner check id: mixed-contentThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
