Images and Scripts That Still Load Over HTTP

What Google announced yesterday

Google said yesterday that Chrome will gradually block mixed content: files loaded over plain http by a page that is itself secure.

Chrome already refuses to run insecure scripts and frames on secure pages. Insecure images, audio and video have been allowed so far, with the padlock removed as a warning.

That changes in steps, starting with Chrome 79 in December.

Chrome 80, early next year, will try audio and video over https first and block them if that fails. It will also show Not secure in the address bar on pages with insecure images.

Chrome 81 will do the same upgrade for images, and block any that fail.

For a site that moved to HTTPS but never quite finished, the leftovers are about to stop being a missing padlock and start being missing pictures.

Where the http:// addresses hide

• Images inserted years ago, stored in old pages with their full address.
• The theme's stylesheet, with background images and fonts written in.
• Theme and page builder settings, such as the logo and header image.
• Embedded maps, videos and forms copied from other services long ago.
• Badges and banners loaded from an association's or supplier's server.
• Widgets from services that have since moved or closed.

The fifth is the one a single letter cannot fix. If the server holding the file has no certificate, there is no https version to switch to.

Why some will fix themselves

Chrome's plan is to try each insecure image, audio or video file over https before giving up. If the same address works securely, the file loads and the visitor never knows.

That rescues most references to your own site, since your own server already answers over https.

It does not rescue files on servers without certificates: an old images subdomain nobody set up for https, a supplier's ageing server, a service that no longer exists. Those are the files that will disappear.

Scripts and frames get no such rescue. They are blocked already, which is why an old map or booking widget on a secure page may be an empty space today.

Checking a single page

Open the page in Chrome, open the developer tools from the menu, and look at the Console. Each insecure file is listed as mixed content, with its full address.

Not every http:// in a page's code is a problem. A link to another website, which the visitor chooses to follow, is fine.

What matters is anything the page loads by itself: images, scripts, stylesheets, fonts, frames, audio and video. A form that sends its data to an http address is flagged too, and deserves fixing first.

Checking the whole site

Page by page works for a five-page site. Anything larger needs a crawl: a tool that visits every page and reports each insecure file, which most web developers use routinely.

On a WordPress site, most leftovers live in the database. Searching it for the http version of your own domain shows how many references remain in pages, posts, widgets and settings.

Replacing them needs care. Page builders and theme settings store addresses in a format a plain find and replace can corrupt, so use a tool built for WordPress, after taking a backup.

Then check the theme's own files and stylesheets, which a database search does not cover.

A worked example

An independent optometry clinic with two locations moved its site to HTTPS last year, with a certificate and redirects, and assumed the job was done.

The locations page said otherwise. Its two maps had been embedded years before with http addresses, so Chrome blocked both frames and the page showed blank spaces where the maps belonged.

The home page header image was set in the theme's stylesheet, from an old images subdomain that had never had a certificate. It still loaded, but without a padlock, and under the new plan it would eventually be blocked.

The footer carried a professional association's badge, loaded from the association's own server over http, with no secure version available.

The fix took an afternoon. The maps were embedded again with current code, and the header image moved onto the main domain.

The badge was saved and served from the clinic's own site, with the association's permission. A crawl afterwards found nothing left.

Files with no secure version

When the server holding a file has no https version, there are three choices.

Host a copy yourself, where the owner or the licence allows it. That works for badges, logos, photographs and documents.

Replace it with the service's current embed code, which is how most old maps, videos and booking widgets are fixed.

Or remove it. A widget from a service that closed years ago has been doing nothing for a long time; Chrome is only making that visible.

A safety net, not a substitute

A setting called upgrade-insecure-requests, sent by the server as part of a content security policy, tells browsers to request every file on a page over https.

Google suggests it as a way to avoid the coming warnings. It helps wherever a secure version exists, does nothing where one does not, and Internet Explorer ignores it.

So add it after the cleanup, not instead of it. A site relying on it alone has still not found the files that are going to break.

The counter-case

A site built on HTTPS from the start, or a small site with a few pages and nothing embedded, may have nothing to fix. A few minutes with the Console on each page will confirm it.

Nor is there an emergency today. Chrome 79's first step changes little for most sites; the changes for images arrive with Chrome 80 and 81 next year.

But the work is the same now as in February, and doing it first means no visitor ever sees the warning. Find the http:// addresses, fix each at its source, and add the safety net afterwards.

Before December

1. Open each key page with the Console showing.
2. Crawl the whole site for insecure files.
3. Search the database for your old http address.
4. Fix theme files and stylesheets by hand.
5. Embed maps and videos again with current code.
6. Host, replace or remove third-party leftovers.
7. Add upgrade-insecure-requests once the rest is done.

Step six is the one Chrome's automatic upgrade cannot do for you. Files on your own server will mostly survive the change; files on somebody else's insecure server will not, and only you can decide what replaces them.

The rest of a proper move is covered in moving a site to HTTPS properly.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.