Practices
Stop your secure page loading insecure files
Your page is served over a secure connection, but some of the files it loads still use the old insecure http address, so browsers block them or load them in a downgraded state.
Why it matters
A padlock on a broken page is worse than no padlock. Visitors see missing images, unstyled sections, or a script that silently does nothing, and browsers may warn them that the page contains insecure content. In almost every case it is one link written before the site moved to https that nobody updated, often inside a template or a third-party embed.
How you would notice it
- The address bar shows a padlock, but some images or icons do not appear.
- The page looks different on a phone than on your desktop.
- A browser console shows warnings containing the words mixed content.
What to do
Stage 1
- Open the page in a browser, open the developer tools console, and look for warnings containing mixed content or blocked. Each one names the exact address at fault.
This turns the job into a list. Work through the list rather than searching your files for http.
- For each address reported, find where it appears in the page and change http to https.
The file must also be available over https. Load the new address directly in a browser to confirm it before you move on.
<img src="http://cdn.example.com/photo.jpg" alt="Team photo">Stage 2
- Check your stylesheets as well, because a background image written in CSS counts and does not always appear in the console as clearly.
.hero {
background-image: url(http://cdn.example.com/hero.jpg);
}Stage 3
- Where the file is inside a third-party embed such as a video, a map, or a chat widget, take the secure version of that embed code from the provider.
Some older providers only publish an insecure snippet. If no secure option exists, that embed has to be replaced or removed.
- If you control the server, you can also ask browsers to upgrade these requests automatically instead of editing every file.
Treat this as a safety net rather than a replacement for fixing the addresses. A file that is not available over https will still fail.
# tells the browser to rewrite insecure subresources to https
Content-Security-Policy: upgrade-insecure-requestsHow to check it worked
Confirm it worked
Reload the page with the developer tools console open and confirm the mixed content warnings are gone and every image and icon is visible. Check it in a private window as well, because a cached copy can hide a remaining problem. Then re-run the Siege Test and confirm the mixed content recommendation is gone.