Skip to content

Security

How to fix mixed content warnings

Browsers block active mixed content outright, so a script or stylesheet loaded over HTTP simply does not run — the page can look broken with nothing in your logs. It also removes the padlock, which visitors do notice.

What 13x checks

This is rule security.mixed-content in the public registry: No insecure subresources. It runs on every audit, against the pages we actually fetched, and its result is derived from the response rather than estimated.

Surface
Security
Score weight
9 of the readiness score
Scope
Runs on every audited page
Applies
Only where the market or the page shape makes it relevant

Registry version 2026-07-30. Every rule is published, and the audit is deterministic — the same page produces the same finding every time.

The fix

The same text the audit hands you when this check fails on your own site.

These load over plain HTTP on an HTTPS page: .

Browsers block active mixed content — scripts, stylesheets, iframes — outright. The request never happens, so the page can appear broken with nothing in your server logs.

Change each http:// to https://. If a third party genuinely does not support HTTPS, replace it; there is no workaround worth having.

To find the rest:

bash code
curl -s https://example.com | grep -o 'http://[^"'"'"' ]*' | sort -u

While you are migrating, this header reports what would break without blocking it:

Configuration
Content-Security-Policy-Report-Only: upgrade-insecure-requests

Does your site have this problem?

13x checks this and 112 others against your live URL in about 30 seconds. No account, and every finding comes with the fix for your framework.

No signup. Results in 30 seconds.

More security checks