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.
Mixed content weakens HTTPS
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.
Mozilla
Chrome
It's up to you, the developer, to fix mixed content issues in your application.
Why this is dangerous?
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.
Browser behavior with mixed content
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.
Browser versions
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.
Two types of Mixed Content
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.
Mixed passive/display content
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.
Passive content list
This section lists all types of HTTP requests which are considered passive content:
-
<img>(srcattribute) -
<audio>(srcattribute) -
<video>(srcattribute) -
<object>subresources (when an<object>performs HTTP requests)
Mixed active content or mixed scripting
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.
An attacker has access to all or parts of the Document Object Model of the HTTPS page. This allows the attacker to change anything about the page, including displaying entirely different content, stealing user passwords or other login credentials, stealing user session cookies, or redirecting the user to a different site entirely, even rewrite the response to include malicious JavaScript code. Active mixed content includes scripts, stylesheets, iframes, flash resources, and other code that the browser can download and execute.
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.
Active content examples
This section lists some types of HTTP requests which are considered active content:
-
<script>(srcattribute) -
<link>(hrefattribute) (this includes CSS stylesheets) -
<iframe>(srcattribute) XMLHttpRequest requests-
fetch()requests - All cases in CSS where a
<url>value is used (@font-face,cursor,background-image, and so forth). -
<object>(dataattribute)
Reference
Found this article interesting? Consider buying a coffee for me.
Top comments (13)
Great post. I feel like this is one of those topics that creeped up into great relevancy as the web went https en masse and most people kind of just get hit with these notices without much prep. Many people probably deal with this for the first time in production because of some content-specific edge case or difference between dev and prod.
Using HTTPS for everything makes it hard for the attackers to hack into, since people starting watching movies like: Mission Impossible.
From that moment, it feels like anything is possible, even breaking through a HTTPS secure connection 😂
Glad you like the post.
That's true, it's kinda hard to keep track of minor things and mixed content is one of them.
Had the same issue today at my Jekyll homepage/blog. I changed the theme and with it the css, but the page was fetching the css over http instead of https so the css was not loaded. Fixed it after declaring that is should be loading over https.
Interesting 🙄, was that CSS file created by you or the jekyll theme caused the error.
It was autogenerated in the build process. I didn't specified the url exactly, just the url.
See here. Had to declare it with // instead of https and then it was loading it correctly.
I see 😮.
As far I know that
urlis kinda optional to use in jekyllconfig.yml.Great blog!
I have deployed my client side to Azure but the server side is hosted on apache server (HTTP) and I am getting the same error in production mode and waring in development mode.
But I am not getting any way to fix this.
So can you please tell me how can I fix this?
Help needed.
Part of this article was copied directly from this source
developers.google.com/web/fundamen...
You should credit the author -- it is available under a CC license, as noted in the site's footer.
I have mentioned at the bottom of the article, under sources section.
how to resolve this type of mixed content issues in nginx configuration file
Brilliant Post, well explained! 🙂 Thanks for sharing!
Glad you found it helpful.