Mixed Content, Modern Browsers, and Principle of Trust


Recently, I came across a blog from Tanvi, a Mozilla Security Engineer (you can find her on Twitter @TanviHacks) talking about mixed content and Firefox 23. It was awesome and refreshing to read that modern browsers are amping up security. A few weeks back while developing a web application, I encountered an issue where the application was not working on a secured SSL connection on Google Chrome v21. Looking at the Google Developer Tools console, I saw the following log message:

[blocked] The page at https://ran insecure content from http://code.jquery.com/ui/1.10.1/jquery-ui.js.

It seems that Google Chrome has moved towards silently blocking mixed content, that is, content from insecure resources. At the time, I was reading forum posts about such annoyances and ways for users to disable this “nuisance” feature. It may be annoying for some users to deal with dialog boxes interrupting their work flow because of non-secure content, but if one recognizes the importance of security,then I strongly believe that blocking mixed content is a necessary behavior. It is a reminder of what we should expect from secured sites.

SSL (Secure Sockets Layer) is a “cryptographic protocol that provide security over the Internet.” This protocol “negotiates” a connection between the client and the server by using a “handshake” procedure, which is a type of procedure to assure that the parties in communication and in transmission with one another are not hackers or phishers. An important way to see the “https://” is like a contract between the server and the user. The purpose is to establish a kind of trust that the user’s information will be secured from any dangers of hacker theft or exploitation.

When we recognize “https://” as an explicit assurance by the server that the site is safe, then the nature of mixed content and incorporating it into your site would clearly break that trust. Mixed content arises whenever an HTTPS origin loads resources over an insecure transport (ie. loading a javascript resource from an http inside a https page). Since the nonsecure resources cannot be trusted, the security of the whole page is called into question. Browsers before warn users of any site that has mixed content in an SSL page, like the following:

But with our lives are becoming more dependent with technology, and with more and more of our personal data being sent through the deep (and at times, shady) alleyways of the Internet, security needs to be one of the highest priorities for developers, and not rely on browsers to show annoying and cryptic popup boxes. Adam Langley, the software engineer who worked on Google Chrome, recently stated, “[M]ixed scripting is an insidious threat for sites that mix HTTP and HTTPS…. By picking a page with mixed scripting, [hackers] can hijack the insecure requests for resources and compromise the origin”.

It is great to find out more modern browsers block mixed script loads. Such increased security will compel developers to be more conscious of the importance of security and adhere to established security standards when using SSL. Again, having HTTPS in the URL should be a clue for users to know the site can be trusted. If a “secured” site cannot adhere to these rules to only anchor secured resources, then the user has neither the right nor reason to put any confidence in the safety of the site, outside of blind faith. The question then follows to developers who still want to incorporate mixed content: Do you want mixed content, or do you want your site secured?


  1. Thanks Peter for writing this article about Mixed Content as a followup from my blog post! One correction, I am actually female ;)

    • I’m so sorry Tanvi! I feel so bad about that mistake. I made the correction. Thank you though for the very interesting article. I really enjoyed it!

  2. Very informative! I would add that loading a resource (js file) from a external source that supports ssl is also pretty bad. Even if that mixed content dialog doesn’t show up.

Leave a Reply

Your email address will not be published. Required fields are marked *