Internet Explorer 8 Mixed Content Handling

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see IE Developer Center.

Eric Lawrence
Microsoft Corporation

July 1, 2009


Understanding Mixed Content

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, shown in the following image.

The Mixed Content Warning from Internet Explorer 7

Figure 1: Mixed content warning in Internet Explorer 7

As I first discussed on the IEBlog four years ago, the mixed content warning occurs when a Web developer references an unsecure (http) resource within a secure (https) page. Such references create vulnerabilities that put the privacy and integrity of the otherwise secure page at risk, because the unsecure content could be modified in transit. If added to the DOM, malicious unsecure content can read or alter the content which was delivered over the secure connection. These types of vulnerabilities are becoming increasingly dangerous as more users browse untrusted networks and 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 unsecure 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 unsecure content, we risk confusing the user; pages which rely on unsecure 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 unsecure content in secure pages by default, with an information bar that allowed refresh of the page with mixed content permitted, shown in the following image.

The Mixed Content Warning displayed by the Information Bar
Figure 2: Mixed content warning displayed by the Information bar

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 e-mail message on a secure site, they might type or copy/paste a reference to an unsecure resource within that message. When the Information bar is subsequently used to unblock the mixed content, the blog post or e-mail 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 unsecure 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 unsecure content vulnerabilities; pages without such vulnerabilities won't trigger the prompt.

The Improved 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 the 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 is shown in the following figure.

The Mixed Content Warning displayed by Internet Explorer 8
Figure 3: The Mixed Content Warning displayed by Internet Explorer 8

If the user chooses No, the unsecure resources are displayed in the page and the lock icon is removed from the browser address bar.

Suppressing the Mixed Content Warning (for End-users)

End users may choose to suppress mixed content warnings by adjusting browser security settings. Inside the Tools / Internet Options / Security / Internet Zone / Custom dialog box, the "Display mixed content" option can be set to "Disable." This option will automatically block unsecure 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 unsecure content was a tracking pixel or metrics-tracking script.

Disabling the Mixed Content Warning
Figure 4: Disabling the mixed content warning

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.

If you do encounter a mixed content warning, feel free to point the website administrator to the following section of this article to help them fix the bug in their site.

Suppressing the Mixed Content Warning (for Web Developers)

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 "//". When the user visits a secure page containing such a reference (such as the resulting URI will be evaluated as On the other hand, if the user visits the same page using HTTP, the resulting URI will be evaluated as In this way, site developers can easily build pages that work for either HTTP or HTTPS without introducing a mixed content vulnerability.

If you encounter a mixed content warning while working with your site, you may be able to use the built-in Internet Explorer Developer Tools to search for the unsecure reference. However, it's also possible that a HTTPS URL returned a redirect to an unsecure 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. Press CTRL+F5 to reload the page.

  4. In Fiddler, click the Protocol column to sort by requests by protocol.

  5. Determine which URLs have been delivered using HTTP.

  6. Eliminate the use of those HTTP URLs or update any secure redirectors pointing to HTTP resources.

The following image shows the type of thing you're looking for.

Using Fiddler to Find Mixed Content
Figure 4: Using Fiddler to find mixed content

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.

Eric Lawrence is a Product Manager on the Internet Explorer team.