Fix Warnings of Non-SSL Elements on Your Site

 

Browser Mixed-Content Warnings
Why Am I Seeing This Warning?
Mixed Passive Content
Mixed Active Content
Fixing Mixed Content Warning


Browser Mixed-Content Warnings

Visitors to sites protected by SSL expect (and deserve) seamless protection. When a site doesn’t fully protect all content, a browser will display a “mixed-content” warning. When your customers see this warning, they can react one of two ways. If they don’t take security seriously, they will ignore it, click through and presume everything will be okay (very bad). If they do take security seriously, they will pay heed to it, back out of your site and assume that you don’t take security seriously (even worse).

Furthermore, all modern browsers will block the more malicious types of mixed content – and in doing so may break your site.

The best solution, of course, is to make sure that these warnings and/or blocks won’t occur in the first place by correctly configuring your site to serve only secure content.


Why Am I Seeing This Warning?

A mixed-content warning means that both secured and unsecured elements are being served up on a page that should be completely encrypted. Any page using an HTTPS address must have all content coming from a secured source. Any page that links to an HTTP resource is considered insecure and is flagged by your browser as a security risk.

Mixed-content warnings fall into two categories: mixed passive content and mixed active content.


Mixed Passive Content

Passive content refers to items which can be replaced or altered but can’t change other parts of the page – for instance, a graphic or photograph. Probably the most common cause of all mixed content warning is when a (theoretically) secure site is configured to pull images from an unsecured source.

Passive HTTP requests are served via these tags:<audio>(src attribute)
<img> (src attribute)
<video> (src attribute)
<object> subresources (when an <object> performs HTTP requests)


Mixed Active Content

Active content can alter the web page itself. A man-in-the-middle attack could allow a request for HTTP content on any HTTPS page to be intercepted and/or rewritten. This makes malicious active content very dangerous – user credentials and sensitive data can be stolen, or malware installed on the user’s system. For instance, a bit of JavaScript on an account-creation page designed to help users generate a random password could be replaced by code providing a random-seeming but pre-generated one instead, or to deliver an otherwise secure password secretly to a third party.

Active mixed content can be exploited to compromise sensitive private data, but even public-facing web pages which seem innocuous can still redirect visitors to dangerous sites, deliver unwanted content or steal cookies for exploitation.

Active HTTP requests are served via:<script> (src attribute)
<link> (href attribute) (this includes CSS stylesheets)
XMLHttpRequest object requests
<iframe> (src attributes)
All cases in CSS where a url value is used (@font-face, cursor, background-image, etc.)
<object> (data attribute)

All modern browsers will block active mixed content by default (which may break an incorrectly-configured site)


Why and How to Fix Mixed-Content Warnings

Securing your website lets your visitors trust you, which is vitally important. However, eliminating all insecure content from your site has an even greater bonus of eliminating false positive warnings – if your correctly-configured site is compromised, any insecure element an attacker inserts will trigger the mixed-content warning, giving you an extra tripwire to detect and address these issues.

Again,the best way to avoid mixed content issues is to serve all content via HTTPS instead of HTTP.

For your own domain, serve all content as HTTPS and fix your links. Often, the HTTPS version of the content already exists and this just requires adding an “s” to links – http:// to https://.

For other domains, use the site’s HTTPS version if available. If HTTPS is not available, you can try contacting the domain and asking them if they can make the content available via HTTPS.

Alternatively, using “relative URLs” lets the browser automatically choose HTTP or HTTPS, depending on which protocol the user is using. For example, instead of linking to an image using a link with the “absolute path” of:

<img src=”http://somedomain.com/image.png”>

The site can use a relative path:

<img src="//somedomain.com/image.png”>

This allows the browser to automatically add either http: or https: to the start of the URL as needed. (Note that the site linked to will need to offer the resource over both HTTP and HTTPS for relative URLs to work.)


Follow these links for more browser-specific information on mixed-content warnings:
Chrome
Firefox
Internet Explorer
Excellent tools to help track down non-SSL links in your source code are the Firebug add-on for Firefox and the Developer Console built into Chrome.Information on forcing an Apache server to handle only HTTPS can be found here.