Unencrypted content on HTTPS pages

What we check

If the home page is delivered over HTTPS, we search the delivered and the rendered HTML for addresses starting with http:// and add the requests the browser actually sent over HTTP while loading.

• Forms whose target is an http:// address: critical. The visitors' input travels unencrypted.
• Scripts, stylesheets, frames and objects over http://: critical. Browsers block them, functions and layout break.
• Images, videos and audio over http://: warning. Browsers try to switch to HTTPS and otherwise do not show the file.

Relative paths (/images/logo.png) and protocol-relative addresses (//cdn.example.ch/...) are fine.

Why it matters

An encrypted page promises visitors that nobody on the way reads along or changes content. Every file loaded over HTTP breaks that promise for exactly that file. For a script this means: someone in the same network, say a public Wi-Fi, could replace it with their own and control the whole page.

Browsers therefore react firmly. Scripts and stylesheets over HTTP are silently blocked; the page then looks broken without anyone getting a message. The padlock in the address bar disappears, and for forms the browser warns before submitting.

For search engines a page with mixed content does not count as fully secure.

How to fix it

Addresses in the content

Search texts, images and templates for http:// and replace it with https:// or with relative paths. For WordPress, plugins such as "Better Search Replace" do this across the whole database. Also check the site address setting (WordPress: "Settings › General").

Embedded services

Old embeds of maps, videos, fonts or counters sometimes still use http://. Get the current embed code from the provider, it is always https:// today.

Forms

The target of a form (action) must be an https:// address. For form services, check the settings of the service.

Safeguard for the future

With the header Content-Security-Policy: upgrade-insecure-requests you tell browsers to request all http:// addresses of the page over HTTPS automatically. This catches forgotten links but does not replace correcting them.

How to check it yourself

Open the page in Chrome and click the icon on the left of the address bar. If it says "Not secure" or mentions insecure content, something is mixed. In the developer tools (F12) under "Console" the affected files are listed with the note "Mixed Content".

Frequently asked questions

The page has a valid certificate. Is that not enough?

The certificate encrypts the page itself. Every embedded file has its own address, though. If it starts with http://, it is requested unencrypted, no matter how well the page is protected.

Do browsers not switch images to HTTPS automatically?

Chrome, Firefox and Safari try that for images and media. If it fails, they do not show the file at all. Scripts and stylesheets are blocked without trying. Do not rely on it, correct the addresses instead.

Where do these http:// addresses come from?

Mostly from the time before the switch to HTTPS: old image links in texts, a hard-coded site URL in the CMS, or a theme that embeds files with a full address.