DEV Community

Cover image for Mixed Content: Fetching data from HTTPS and HTTP
Yashu Mittal
Yashu Mittal

Posted on

Mixed Content: Fetching data from HTTPS and HTTP

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?

Secure and Not secure

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.


Mixed content screenshot from mozilla console


Mixed content screenshot from chrome console

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> (src attribute)
  • <audio> (src attribute)
  • <video> (src attribute)
  • <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> (src attribute)
  • <link> (href attribute) (this includes CSS stylesheets)
  • <iframe> (src attribute)
  • XMLHttpRequest requests
  • fetch() requests
  • All cases in CSS where a <url> value is used (@font-face, cursor, background-image, and so forth).
  • <object> (data attribute)


Found this article interesting? Consider buying a coffee for me.
Buy Me A Coffee Button

Top comments (13)

ben profile image
Ben Halpern

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.

mittalyashu profile image
Yashu Mittal

Using HTTPS for everything makes it hard for the attackers to hack into, since people starting watching movies like: Mission Impossible.

Mission impossible - falling from Burj Khalifa

From that moment, it feels like anything is possible, even breaking through a HTTPS secure connection 😂

mittalyashu profile image
Yashu Mittal

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.

lschultebraucks profile image
Lasse Schultebraucks

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.

mittalyashu profile image
Yashu Mittal • Edited

Interesting 🙄, was that CSS file created by you or the jekyll theme caused the error.

lschultebraucks profile image
Lasse Schultebraucks

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.

Thread Thread
mittalyashu profile image
Yashu Mittal

I see 😮.

As far I know that url is kinda optional to use in jekyll config.yml.

rupeshiya profile image
Rupesh Krishna Jha

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.

ryan profile image

Part of this article was copied directly from this source

You should credit the author -- it is available under a CC license, as noted in the site's footer.

mittalyashu profile image
Yashu Mittal

I have mentioned at the bottom of the article, under sources section.

jayachandra1209 profile image

how to resolve this type of mixed content issues in nginx configuration file

pierre profile image
Pierre-Henry Soria ✨

Brilliant Post, well explained! 🙂 Thanks for sharing!

mittalyashu profile image
Yashu Mittal

Glad you found it helpful.