'Mixed Content' blocked — serve everything over HTTPS
Quick answer: your HTTPS page requested an http:// resource - a script, fetch, image, or iframe - and the browser blocked it for being insecure. Fix the resource URLs to https:// (or use relative paths), make your API and assets serve over HTTPS, and behind a proxy trust X-Forwarded-Proto so the app builds https URLs. The upgrade-insecure-requests CSP directive is a good backstop.
What the error looks like
It appears in the browser console and names the blocked resource:
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure resource 'http://api.example.com/data'.
This request has been blocked; the content must be served over HTTPS.The blocked URL is right there in the message. It is always an http:// resource requested from an https:// page - fix the scheme of that resource.
Why it happens
Hardcoded http:// URL
A script, image, or fetch points at http:// in the markup or code.
API served over http
Your frontend on HTTPS calls an API endpoint that is only reachable over http.
CDN or asset over http
An embedded font, image, or third-party widget loads over http.
Backend builds http URLs
Behind a proxy the app sees http and emits absolute http:// links because it ignores X-Forwarded-Proto.
Diagnose it in three steps
Read the blocked URL in the console
# The message names the exact http:// resource. Is it your API, an asset, or a third party?Grep the source for http://
grep -rn "http://" src/ public/ # find hardcoded insecure URLsIf the backend builds the URL, check the proxy header
# does the proxy set X-Forwarded-Proto, and does the app trust it?
curl -sI https://example.com | grep -i location # redirects to http?Use https everywhere, trust the proxy header
Change resource URLs to https:// or relative paths, make sure your API and assets are reachable over HTTPS, and behind a proxy tell the app to trust X-Forwarded-Proto so it builds https URLs. Add upgrade-insecure-requests as a safety net.
<!-- prefer relative or https, never http:// -->
<script src="/assets/app.js"></script>
<img src="https://cdn.example.com/logo.png">
// Express behind a proxy - trust the forwarded scheme
app.set('trust proxy', true);
# CSP backstop - auto-upgrade insecure sub-resource requests
Content-Security-Policy: upgrade-insecure-requestsFor a third-party widget that only offers http, replace it or self-host an https copy - you cannot make the browser load it insecurely on an HTTPS page, and you should not want to.
HTTPS and forwarded-proto, done right
Mixed content is usually a TLS-termination detail - the edge speaks HTTPS but the app does not know it. On your own servers, Infraveil helps you stand up consistent HTTPS and proxy config so X-Forwarded-Proto is set and trusted, security headers like upgrade-insecure-requests are in place, and the posture stays correct across every host - with changes recorded.
Frequently asked questions
What is mixed content?
An HTTPS page that loads a sub-resource over plain HTTP. Since the insecure resource could be tampered with, browsers block active mixed content (scripts, fetch, iframes) and block or flag passive content (images, media).
Why is it blocked even though the resource exists?
The block is about the scheme, not the file. The http:// version may load on its own, but on an HTTPS page the browser refuses it because the connection is not encrypted. Request the https:// version.
How does upgrade-insecure-requests help?
The CSP directive tells the browser to rewrite http:// sub-resource requests to https:// automatically. A useful backstop, but it only works if an https:// version actually exists - the real fix is to stop emitting http:// URLs.
Why does my backend build http:// URLs behind a proxy?
The app sees the internal HTTP connection from the proxy and assumes http. Trust the X-Forwarded-Proto header the proxy sets (e.g. app.set('trust proxy', true) in Express) so absolute URLs use https.
Client-side, no signup — they run in your browser.