# Chrome's security push makes mixed-content checks vital

The team at Chrome has [announced their plans for handling mixed content last week](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html) on their blog.

We'll highlight the most important details and what the potential impact is.

## A security-first approach: what is mixed content?

As a general reminder: "mixed content" exists when you have a website loaded via `HTTPS`, that loads insecure resources over plain `HTTP`. These can be images, CSS or even JavaScript & iFrames.

Certain types of mixed content are already blocked. They won't load in a secure context (= `HTTPS` site) and your users might find a half-broken or fully broken website. In the console, you'll see notices like these.

> Mixed Content: The page at 'https://domain.tld' was loaded over HTTPS, but requested an insecure resource 'http://domain.tld/iframe'. This request has been blocked; the content must be served over HTTPS.

The goal is to protect the user: websites served via `HTTPS` have an encrypted connection between the user and the server. A man-in-the-middle attack is a lot harder to perform when a site is loaded via HTTPS than via HTTP.

Images, CSS or JavaScript loaded via HTTP could then still be intercepted and modified, potentially compromising your users.

## Chrome's plan to auto-upgrade mixed content

It would have been pretty good for our business use case if Chrome decided to all-out block mixed content. :-)

But, luckily for the smooth operation of the web, [they're going about it much smarter](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html).

The timeline is as follows:

> In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. 

> Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS.

Marking websites as non-secure has been a gradual process since early last year, when [all HTTP sites were shown a similar message](https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/).

Early next year, Chrome 81 will force upgrade all non-secure elements on a secure page to HTTPS.

> In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.

In other words: if your images, css or JavaScript aren't able to be served by HTTPS, they'll be blocked by default.

## Start scanning for mixed content today

This is probably a good time to mention that Oh Dear! has [mixed content checking](/docs/features/mixed-content-reporting) available for all our users (on top of our [broken links checking](/features/broken-page-and-mixed-content-detection)).

If you don't want to be caught by surprise early next year, make sure you monitor for mixed content and preventively upgrade all your links & resources to HTTPS.

This would be especially important if your assets are served on a subdomain or different server that isn't capable of serving HTTPS just yet. Once Chrome auto-upgrades those to HTTPS, they'll stop working for your users altogether.