Please read my blog's comment policy here.
Update: IE9 includes improved handling of Mixed Content. Click to learn more...
As we developed Internet Explorer 8, we spent quite a bit of time pondering what to do about IE7’s infamous “Mixed Content” warning prompt:
As I noted on the IEBlog four years ago, the mixed content warning occurs when a web developer references an insecure (http) resource within a secure (https) page. Such references create vulnerabilities that put the privacy and integrity of an otherwise-secure page at risk, because the insecure content could be modified in transit. If added to the DOM, insecurely-delivered content can read or alter the rest of the page even if the bulk of the page was delivered over a secure connection. These types of vulnerabilities are becoming increasingly dangerous as more users browse using untrusted networks (e.g. at coffee shops), and as attackers improve upon DNS-poisoning techniques and weaponize exploits against unsecure traffic.
From a security standpoint, our best option would be to suppress the prompt altogether and simply make the secure choice on the user’s behalf, blocking all insecure content in secure pages. Unfortunately, as I mentioned in my MiX 2009 Security session, security is usually easy, but tradeoffs are often hard. If we were to simply automatically block the insecure content, we risk confusing the user; pages which rely on insecure images, stylesheets, or scripts could appear broken. In the worst case, the user might think the broken pages indicate a bug in IE8 and subsequently revert to an older version of the browser to get the prompt and unbroken pages.
In an attempt to resolve the compatibility / security tradeoff, we experimented with a number of concepts. For instance, we tried blocking insecure content in secure pages by default, with an information bar that allowed refresh of the page with mixed content permitted.
In our testing, we discovered a number of important scenarios where this approach introduced a much more severe problem-- data loss. For instance, when the user is composing a blog post or email message on a secure site, they might type or copy/paste a reference to an insecure resource within that message. When the information bar is subsequently used to unblock the mixed content, the blog post or email message would be lost because the web application was refreshed. If we didn’t refresh the page after permitting the mixed content, the page could break anyway, because the insecure resource would be run out of its normal order.
Ultimately, we concluded that removing the prompt wasn’t feasible. In IE8, we continue to rely on web developers to fix their pages to remove insecure content vulnerabilities; pages without such vulnerabilities won’t trigger the prompt.
Though we couldn’t get rid of it entirely, we did make some improvements to the prompt to correct several violations of our secure design principles. We identified three major problems with the older version:
1> The secure choice is not the default option.
2> The prompt does not clearly identify that the user is being asked to make a security decision.
3> The prompt does not offer the user enough information to make a safe choice. Specifically, it doesn’t indicate what the consequences of their choice might be.
To address these issues, we changed the default behavior of this prompt such that the secure option is the default; if the user simply clicks through, the page remains secure. We also updated the title, question, and explanatory information to help users understand the implications of the security decision they are being asked to make. The new prompt appears as follows:
If the user chooses “No,” then the insecure resources are displayed in the page and the lock icon is removed from the browser address bar.
If you encounter a mixed content warning, feel free to point the website administrator to the following section of this blog post to help them fix the bug in their site.
Users may choose to suppress mixed content warnings by adjusting browser security settings. Inside the Tools / Internet Options / Security / Internet Zone / Custom… dialog, the “Display mixed content” option can be set to “Disable.” This option will automatically block insecure content in secure pages without the annoyance of the prompt. In many cases the web page will not be seriously broken; in some cases, no user-visible change will occur, for instance, if the insecure content was a tracking pixel or metrics-tracking script.
Similar configurations can be made to the Intranet Zone and Trusted Zone settings. Within some organizations, it may be appropriate to set the Intranet zone option to “Enable,” because it is less likely that an attacker outside the organization could exploit Intranet sites containing mixed content. In contrast, while it might be tempting to set the “Trusted” zone setting to “Enable,” it’s important to remember that in the face of a DNS-poisoning or man-in-the-middle attack, even “trusted” HTTP traffic could be intercepted.
Note: There's one other important factor to keep in mind-- IE checks the Security Settings for the Zone of the insecure content, not the Security Settings of the Zone of the page. Intuitively, that's seems quite backwards, doesn't it? It certainly seemed surprising and wrong to me when I first learned about it.
However, if you think harder about it, it turns out that it makes perfect sense: you (the user) may know that you have a "safe" connection to a particular zone (say, the Intranet) and hence any content that is coming from that Zone can be transfered without HTTPS but remain secure (say, because your organization's firewall prevents tampering by external attackers). In contrast, if you were visiting a HTTPS page on your Intranet, and it tried to pull in insecure content from the Internet, it would be incorrect for the browser to say "Well, the outer page is trusted, so we'll let unprotected content from another source be mixed in."
For security and user-experience reasons, mixed content vulnerabilities should be fixed by the web developer. In principle, this is very simple: within a HTTPS page, never include a link to a HTTP-delivered resource.
One trick which might be useful is to use protocol-relative hyperlinks, of the form “//example.com/image.gif”. When the user visits a secure page containing such a reference (e.g. https://example.com/page.htm) the resulting URI will be evaluated as https://example.com/image.gif. On the other hand, if the user visits the same page using HTTP, the resulting URI will be evaluated as http://example.com/image.gif. In this way, site developers can easily build pages that work for either HTTP or HTTPS without introducing a mixed content vulnerability.
If you simply remove the SRC attribute from this tag (since it's not performing a download), you will find the problem goes away.
If you encounter a mixed content warning while working with your site, you may be able to use IE’s built-in developer tools to search for the insecure reference. However, it’s also possible that a HTTPS URL returned a redirect to an insecure resource, which could be difficult to determine by examining the DOM alone. The Fiddler web debugger can help troubleshoot the problem; simply follow these steps:
1> Start Fiddler
2> Clear the browser cache
3> Hit CTRL+F5 to reload the page
4> In Fiddler, click the Protocol column to sort by requests by protocol
6> Eliminate the use of those HTTP URLs or update any secure redirectors pointing to HTTP resources
By removing mixed content vulnerabilities, you can protect the integrity and privacy of the content on your secure pages, and avoid annoying your visitors with this security prompt.
Thanks for your help in securing the web!
Clicking the "enable mixed content" option selectively for just trusted sites does not seem to work. (That is, if you have "trusted zones" selected on the security page, and then go in and change the enable mixed content option.)
It seems I have to enable this option for the entire internet zone. Is this a bug in IE8, where they aren't checking the zone properly?
While not a perfect solution, being able, as a user, to selectively pick those secure sites where I'll allow mixed content is worthwhile.
Thanks for providing us with some background about this change in IE8, Eric. It seems MS can't win no matter what they do. If they didn't do this check and warning for secure sites, then just as soon as somebody was burned by it, it'd be trumpted to the world as another blatant MS flaw -- even though other browsers silently allow this flaw, with no fanfare, heck, not even a peep, from the press. I notice, for example that Chrome simply changes the lock icon to a warning icon, and that's it. Very easy to miss. (Personally, I find Chrome's solution to be reasonable -- but I agree with Eric, the problem should be fixed at the source -- ie the mixing of content from diff places. We shouldn't just be treating the symptom.)
<<Clicking the "enable mixed content" option selectively for just trusted sites does not seem to work.>>
In every case I have ever seen, that means that the insecure content is coming from a server that is NOT in your Trusted Zone. The Zone option applies to the *source* of the insecure content, not to the Zone of the containing page.
If you have a public repro, I'd be happy to take a look, just send me the URL and what hostnames you've put in the Trusted Zone.
OK, I have changed my images to https so my images are showing but, some style sheets are not working (ie.css & menu.css) and I am still getting the security pop up.
I ran an order through the shopping cart and loaded it into Fiddler and it shows everything with the lock icon.
How do I find the insecure references that are not showing up in Fiddler?
Thanks for your help!
@Rock: The problem is likely that you didn't clear your cache before running the test.
Your homepage page still includes mixed content, including the image: /sites/rock-band-t-shirts.com/files/images/share_save.jpg
You can email the exact URL that you're having a problem with once you fix all of the insecure references you find after clearing the cache and retrying.
Thanks, I will try it again with the cache cleared.
To view a page like the one in question you need to place an order an go through the check out sequence up to the part when you would input some credit card info.
It is on this page that the security pop up appears. I have created a custom template for this page without the AddThis bookmarking script.
Success! Thanks for all your valuable research and information!!
It's killing me - I'm experiencing the same issue on the following website I coded in the past. Everything looks good inside the code, plus fiddler is returning everything as HTTPS. Any suggestions?
And obvisuoly I forgot the link: www.restaurantfurniture.net
The home page is completely clean but still alerting with insecured content.
@Nick: I don't see any mixed content warnings on that site in IE9. Which IE version are you using? Have you tried using the ScriptFree extension to get the mixed content URL?
I'm using IE8 and also tried it on IE7.
I'm not sure what you mean by "ScriptFree" extension.
I appreciate the help.
@Nick: I mentioned in the comments above: an addon which pops a dialog that lists the insecure URL in the dialog; see http://www.enhanceie.com/dl/scriptfreesetup.exe. You should uninstall that tool when you're done using it.
@Nick: Scriptfree shows you exactly what IE's security manager sees. In your case:
See that https://www.restaurantfurniture.net/script/script.js contains:
I had the same troubles, only with IE8 we get an error after an user enters his password. We use Ajax, and a part of the page is being replaced at that point, showing a new window asking for a SMS code.
Scriptfree saved my day, after a lot of searching. All URL's were relative, but scriptfree showed me that images where referenced as "about:/images/imagename.png". I have replaced those relative URL's to images with https://<website>/images/... URL's, and the problem has disappeared. Thanks to this BLOG and all people posting their experiences and advice here!
Hi Eric, thanks for this post, it is very helpful!
On our website we're running into the very situation you mention above: end users can compose html content inside a text editor on our secure site, but if they paste html from an insecure site into the editor, the mixed content prompt appears. In our case, it doesn't make any difference whether the user chooses to block the insecure content or not, so ideally we would like to be able to tell IE to just block the content automatically and not confuse users with the security warning. Is there any way we can configure the site to do this?