When a user is visiting a page, which is served over a secure connection (HTTPS), their connection with the web server is encrypted with TLS and is therefore safeguarded from attackers.
As the other resources (such as images, videos, stylesheets, scripts) are loaded over an insure HTTP connection, displaying the content on the same page, and the initial request was secure over HTTPS. Pages like this are only partially encrypted, leaving the unencrypted content accessible to attackers. That leaves the pages unsafe.
You’ll occasionally come across these warnings while browsing the web, but what exactly do they mean?
This all comes down to the difference between HTTP (HyperText Transfer Protocol) and HTTPS (HyperText Transfer Protocol Secure). HTTP is the most commonly used type of connection — when you visiting a page using the HTTP protocol, your connection to the website isn’t secured. Anyone eavesdropping on the traffic can see the page and any data you’re sending back and forth.
That’s why we have HTTPS — which stands for "HTTP Secure" and creates a secure connection between you and the web server. HTTPS stands for HTTP Secure, Hyper(t)ext Transfer Protocol Secure. The secure portion here comes from the encryption added to the requests sent and received by the browser. Currently, most browsers use the TLS protocol to provide encryption; TLS is sometimes referred to as SSL.
Mixed content warnings indicate a problem with a web page you’re accessing over HTTPS. Since the HTTPS connection is secure, and the web page’s source code is pulling in other resources with the insecure HTTP protocol, not HTTPS. Your web browser’s address bar will say you’re connected with HTTPS, but the page is also loading resources with the insecure HTTP protocol in the background. To ensure you know that the web page you’re using isn’t completely secure, browsers display a warning saying that the page has both HTTPS and HTTP content — mixed content, in other words.
Requesting subresources using the insecure HTTP protocol weakens the security of the entire page, as these requests are vulnerable to attackers, where an attacker eavesdrops on a network connection and views or modifies the communication between two parties. Using these resources, an attacker can often take complete control over the page, not just the compromised resource.
Although many browsers report mixed content warnings to the user, by the time this happens, it is too late: the insecure requests have already been performed and the security of the page is compromised. This scenario is, unfortunately, quite common on the web, which is why browsers can't just block all mixed requests without restricting the functionality of many sites.
It's up to you, the developer, to fix mixed content issues in your application.
It is a serious matter, let’s say you’re on a payment page and you’re about to enter your credit card details. The payment page indicates it’s an encrypted HTTPS connection, but you see a mixed content warning.
It’s possible that the payment details you enter could be captured by the insecure content and sent over an insecure connection, removing the benefit of HTTPS security — someone could eavesdrop and see your sensitive data.
Because HTTP doesn’t authenticate the web server in the same way HTTPS does, it’s also possible that a secure HTTPS site pulling in a script from an HTTP site could be tricked into pulling an attacker’s script and running it on the otherwise secure site. When HTTPS is used, you have more assurances that the content was not tampered with and is legitimate.
In both cases, this eliminates the benefit of having a secure HTTPS connection. It’s possible that a website could have an insecure content warning and still secure your personal data properly, but we really don’t know for sure and shouldn’t take the risk — that’s why web browsers warn you when you come across a website that’s not coded properly.
Due to the multifarious threats, it would be ideal for browsers to block all mixed content. However, this would break a large number of websites that millions of users rely on every day. The current compromise is to block the most dangerous types of mixed content and allow the less dangerous types to still be requested.
From the spec, a resource qualifies as optionally blockable content "when the risk of allowing its use as mixed content is outweighed by the risk of breaking significant portions of the web"; this is a subset of the passive mixed content category described above. At the time of this writing, images, video, and audio resources, as well as prefetched links, are the only resource types included in optionally blockable content. This category is likely to get smaller as time goes on.
All content that is not optionally blockable is considered blockable and is blocked by the browser.
It is important to remember that not every visitor to your website uses the most up-to-date browsers. Different versions from different browser vendors each behave differently with mixed content. At worst, some browsers and versions don't block any mixed content at all, which is very unsafe for the user.
The exact behaviour of each browser is constantly changing, so we won't include specifics here. If you're interested in how a specific browser behaves, look for information published by the vendors directly.
There are two types of mixed content — mixed passive/display content and mixed active content or mixed scripting. The difference lies in the threat level, worst case scenario, one is worse than the other, but neither is good.
In the case of passive content, the threat is lower (the page may contain misleading content, or the user's cookies may be stolen). In the case of active content, the threat can lead to phishing, sensitive data disclosure, redirection to malicious sites, etc.
Passive mixed content poses a security threat to your site and your users. This happens when an HTTPS site loads something like an image or audio file which is served over HTTP that is included in an HTTPS webpage, this type of content cannot alter other portions of the webpage. However, it’s still a bad security practice that could cause problems.
For example, an attacker could replace an image served over HTTP with an inappropriate image or message to the user, tampering with a theoretically secure page. Even if the attacker doesn't alter the content of your site, you still have a large privacy issue where an attacker could also infer information about the user's activities by watching which images are served to the user; often images are only served on a specific page within a website. If the attacker observes HTTP requests to certain images, they could determine which web page the user is visiting, tampering with a theoretically secure page.
This section lists all types of HTTP requests which are considered passive content:
<object>subresources (when an
<object>performs HTTP requests)
Mixed active content poses a greater threat than passive. This occurs when an HTTPS site loads a script file over HTTP. The script file can run any code on the page it wants to, so loading a script over an insecure connection completely ruins the security of the current page. Web browsers generally block this type of mixed content completely.
The risk involved with mixed content does depend on the type of website the user is visiting and how sensitive the data exposed to that site may be. The webpage may have public data visible to the world or private data visible only when authenticated. If the webpage is public and has no sensitive data about the user, using mixed active content still provides the attacker with the opportunity to redirect the user to other HTTP pages and steal HTTP cookies from those sites.
Due to the severity of this threat, many browsers block this type of content by default to protect users, but functionality varies between browser vendors and versions.
This section lists some types of HTTP requests which are considered active content:
hrefattribute) (this includes CSS stylesheets)
- All cases in CSS where a
<url>value is used (
background-image, and so forth).