Handling Mixed (HTTPS/HTTPS) Content

Artículo
06/22/2009

Update: IE9 includes improved handling of Mixed Content. Click to learn more...

Background

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.

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 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.

Suppressing Mixed Content Warnings (for end-users)

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. "

Preventing Mixed Content Warnings (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 “//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 https://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.

Another common problem (described by lots of folks in the comments) is caused by using JavaScript protocol links for the SRC attribute of SCRIPT tags. In IE8 and below, the following SCRIPT tag will cause a mixed-content warning:

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

5> Determine which URLs have been delivered using HTTP. Also, search for any instances of SRC="javascript: in your markup.

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!

-Eric Lawrence

Comments

Anonymous
June 25, 2009
Why you can't turn off this warning for trusted sites. Time to switch to Firefox...
Anonymous
June 25, 2009
@Prior poster: You can turn this warning off for any site you want, and this blog post contains a screenshot clearly showing how to do so. As noted in the blog post, if you want to make a change, I recommend you move the setting from "Prompt" (the default) to "Disable." The point of this blog post is that the "Enable" setting exposes you to a security risk that many people don't recognize, even for sites you trust. This blog post explains the source of that risk. The risk is one that you would face with ANY browser, so switching browsers doesn't help you in any way. The best fix, as shown by this post, is for websites with Mixed Content vulnerabilities to fix those vulnerabilities.
Anonymous
July 10, 2009
The comment has been removed
Anonymous
July 10, 2009
The comment has been removed
Anonymous
July 31, 2009
I experienced an odd situation where the secure lock was not displayed but no warning was given either. We were requesting a 3rd party image URL via an https://www..../..jpg and that was being redirected by the third party to http://www..../...jpg and served to us. So, the result was no security warning in the browser, but the page did not show the lock icon after that particular image loaded either. Sort of like a “silent mixed mode trigger”. As an aside, the browser did not block the content. Be sure to inspect any third party references that are meant to be secure to make certain they are not returning standard http.
Anonymous
July 31, 2009
@Chris: Yes, unfortunately the image-redirect problem was not fixed in IE8; the redirect is allowed and the lock is silently removed. From a security POV, this is a minor problem because the auto-allow-but-remove-lock behavior only applies to images, not JavaScript/CSS, which are the more dangerous cases. For images, there's the possibility of spoofing the user, but the lock is correctly removed to indicate that the page is no longer secure. As noted in the article, Fiddler is very useful for detecting insecure redirections. Other quirks to be aware of: In IE6, we treat "about:blank" as insecure content, as well as "javascript:" and "res:". In IE7, we fixed the "about:blank" case, but we have not (yet) changed javascript and res.
Anonymous
August 04, 2009
@eric: Thanks for the quick response! I've set up a test page that exhibits the problem: https://www.magnifeast.com/test_ben/ssl_test Some interesting things to note: If you run HTTPWatch or Fiddler, sometimes the error does not occur (which makes me wonder if it's something related to the SSL certs). If you run without either of these, it seems pretty consistent. I'm using IE 8.0.7100.0. Any advice you can offer would be greatly appreciated! Cheers, Ben
Anonymous
August 04, 2009
The comment has been removed
Anonymous
August 04, 2009
Eric, Thanks very much for looking at this. I'm not entirely sure why this particular URL is relative, but it definitely gives us a much better idea of where to look. Cheers, Ben
Anonymous
August 07, 2009
The comment has been removed
Anonymous
August 07, 2009
As an aside, is there a way to reference content so that if my connection is over HTTPS, the external references will be called via HTTPS as well?
Anonymous
August 07, 2009
@Chris asked: "is there a way to reference content..." Indeed, that's the subject of the second paragraph in the section "Preventing Mixed Content Warnings (for web developers)." Use a protocol-relative hyperlink.
Anonymous
August 07, 2009
@Chris opined: "There was no vetting or advanced notice of the change to IT firms or the IE community at large..." Actually, that's not true. We have a Beta program for a reason. New browser versions have tens of thousands of changes, and there are hundreds of millions of browser users. As you might imagine, such scale prevents one-on-one walkthroughs of every change with every developer.
Anonymous
August 11, 2009
I have installed Fiddler and tested it with my site that seems to give this problem - all protocol requests shows HTTP and not HTTPS... I then tested this with my bank's online banking and this has the same result in Fiddler... it just shows HTTP for everything. On my site I get the IE 8 warning, but not on the bank's site - so I'm fairly confident that the bank's site is secure, but fiddler isn't really helping me out though!
Anonymous
August 11, 2009
@Sam: If you want to see HTTPS requests in Fiddler, you have to turn on HTTPS decryption (see the Help). Otherwise, you'll only see the HTTP CONNECT tunnels through which secure traffic flows. If you see any HTTP request which is NOT a CONNECT tunnel while visiting a secure site, that's a Mixed Content bug. If your site is public, I'd be happy to have a look. -Eric
Anonymous
September 11, 2009
@Berrisford: The problem you're describing is unrelated to the mixed-content issue. The problem you're encountering is caused by the "Cache-Control: no-cache" response header sent with the HTTPS-delivered image. That header prevents persistent caching of the HTTPS image, and that, in turn, prevents proper saving of the image from the HTML page. Incidentally, this is the same root cause of the related problem where, if you right-click on that image, only the Bitmap file type is available as a Save As choice. The image cannot be saved in .JPG format because it's not in the cache; Trident only has the in-memory bitmap available to re-save.
Anonymous
November 25, 2009
How could we ever leave an https section of the site to move back to an http section of the site if we can't include a link to the http section from the https page without generating a mixed content warning?
Anonymous
November 26, 2009
@Odinhaus: Including an <A> tag with an HREF to a non-HTTPS site will not trigger a mixed content warning. Only if you include a tag that performs a download (e.g. SCRIPT, IMG, LINK, @import, etc) will the URL be checked to verify that the protocol is secure.
Anonymous
December 07, 2009
Hi Eric, I´m reading this and hoping you can help me. We´re having simmilar problems. In FF everything looks fine, but in IE 7/8 we get a ´unsecure items´ error. I really cannot find what is causing this. I tried httpwatch, fiddler and your script (but that is not working with me, IE crashes). I was wondering if you could take a look? It would be great.
Anonymous
December 07, 2009
@Rene: The problem is where you do this: document.write('<script type="text/javascript" id="contentloadtag" defer="defer" src="javascript:void(0)"></script>') *URLACTION_DisplayMixedContent Flags: 0001:[PUAF_NOUI;] u:javascript:void(0) cbContext: 0 If you take out the SRC, you won’t have this problem.
Anonymous
December 08, 2009
The comment has been removed
Anonymous
December 08, 2009
The comment has been removed
Anonymous
December 15, 2009
I looked closely with fiddler and do not see any http content being delivered to our secure page. Perhaps you could take a peek at this url and let me know what I'm missing? https://bresweb.bresnan.com/nuggets/login.html
Anonymous
December 15, 2009
@Jason, you have exactly the same problem as Rene above. //bresweb.bresnan.com/nuggets/js/goldrush.js Contains this text: script type="text/javascript" id="contentloadtag" defer="defer" src="javascript:void(0)" Remove the SRC attribute and your problem goes away. Incidentally, your server is misconfigured and sending the wrong MIME Content-Type for JavaScript files.
Anonymous
December 15, 2009
Unfortunately, the src="javascript:void(0)" is required there to determine when the DOM is ready since IE ignores the DOMContentLoaded event supported by Firefox and others. See http://www.javascriptkit.com/dhtmltutors/domready.shtml Can you think of another solution either to determining when the DOM is ready or to hiding this errant error message? BTW, thanks for pointing out the mimetype problem. Will investigate.
Anonymous
December 15, 2009
Actually it looks like I can replace src="javascript:void(0)" with src="/js/blank.js" where the blank.js file is an empty text file. Causes an additional hit to the server but seems to function in https.
Anonymous
December 15, 2009
@Jason: To be clear, IE doesn't "ignore" the event-- it simply doesn't implement this nonstandard event that was added by Gecko. The DEFER attribute on the SCRIPT tag already does what you're trying to do. The alternative is to attach an event to the ONLOAD event of the BODY element. Other approaches: http://dean.edwards.name/weblog/2005/02/order-of-events/ http://dean.edwards.name/weblog/2005/09/busted/ http://javascript.nwbox.com/IEContentLoaded/ http://groups.google.com/group/jquery-dev/browse_thread/thread/517dd87b61515162 http://www.kryogenix.org/days/2007/09/26/shortloaded
Anonymous
January 12, 2010
Great job!! I have the mixed problem in a site when deploy in a secure server. Know I know Fiddler (very good tool that I didn´t know) but finally I installed scriptfree and saw a javascript:void(0) (in a js library we import) Thanks.
Anonymous
January 20, 2010
My menu images all use full URL addresses as do the images in the footer yet, when I check them in fiddler they appear without the http://. I can't say how much revenue I have lost since IE8 came out but, I know that is is a lot. It would be nice if at the very least images were excluded from this security function since images do not offer a security risk. Thanks for this info! Ralph
Anonymous
January 21, 2010
@Ralph: I'm not sure I understand you. IE is working exactly as designed in this case; if you want your page to work properly, you need to remove the insecure references. That includes your images, and your insecure reference to addthis_widget.js which compromises the whole page. <<I can't say how much revenue I have lost since IE8 came out but, I know that is is a lot>> IE5/6 and 7 blocked insecure content as well. Is there some reason you didn't fix your page a decade ago? <<images do not offer a security risk.>> I'm not sure how you arrived at that conclusion, but you're mistaken. It's true that images cannot be used to steal content from the page, but they can leak your cookies and they can modify the page with misleading instructions (E.g. Telephone your credit card # to <evil phone number>)
Anonymous
January 21, 2010
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.)
Anonymous
January 21, 2010
<<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.
Anonymous
January 23, 2010
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! Ralph
Anonymous
January 24, 2010
@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.
Anonymous
January 24, 2010
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. Ralph
Anonymous
January 24, 2010
Success! Thanks for all your valuable research and information!!
Anonymous
February 08, 2010
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?
Anonymous
February 08, 2010
And obvisuoly I forgot the link: www.restaurantfurniture.net The home page is completely clean but still alerting with insecured content.
Anonymous
February 08, 2010
@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?
Anonymous
February 09, 2010
I'm using IE8 and also tried it on IE7. I'm not sure what you mean by "ScriptFree" extension. I appreciate the help.
Anonymous
February 09, 2010
@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.
Anonymous
February 09, 2010
I get the javascript:void(0), the thing is there is nothing in the code..
Anonymous
February 09, 2010
@Nick: Scriptfree shows you exactly what IE's security manager sees. In your case: See that https://www.restaurantfurniture.net/script/script.js contains: document.write("<script id=__ie_onload defer src=javascript:void(0)></script>");
Anonymous
February 22, 2010
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!
Anonymous
March 31, 2010
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?
Anonymous
March 31, 2010
@Kyle: Unfortunately, no such option exists (although I did propose it). One thing you might try is to intercept the paste, parse the content, and if there are any links, replace the URLs with a "temporary" secure URL (or just remove them temporarily). Then, when the user actually performs the post, you could "fixup" your blocked URLs. I believe this is how Outlook Web Access handles this scenario, although I haven't tried it in a while.
Anonymous
July 14, 2010
The comment has been removed
Anonymous
July 15, 2010
@tabba: :-) Have you looked at the console tab in the IE9 Platform Preview Build #3? Expect a blog post on this topic on the IEBlog in the IE9 Beta timeframe.
Anonymous
July 15, 2010
Heh heh - Hey Eric, no that's your job! We're far too busy securing content on our websites ;o) Sounds like something good to look forward to though, will await blog-post happy knowing you've got it all under control! Your script is a real-lifesaver btw, so thanks for that too, popped up an offending item we had 5 secs after installing - would advise anyone with probs to go straight for the script; we had some absolute refs to images in a bit of css nested in a jquery call so it had been proving a bit of a headscratcher reviewing code manually... thanks again
Anonymous
July 16, 2010
I have tried the option that is mentioned above. But even after allowing the Mixed content, I'm still getting the prompt. Any ideas? TD
Anonymous
July 16, 2010
You likely set the option for the incorrect zone. Do you have a repro URL?
Anonymous
August 11, 2010
The comment has been removed
Anonymous
August 11, 2010
@Misery: Generally speaking, no, IE's not that smart-- it doesn't know what your control is doing with the filesystem. Did you try running your repro using my "Script Free" plugin referenced above to find the URLs that are causing the Mixed Content warning?
Anonymous
August 12, 2010
@Eric: yes, I did try "Script Free" and it defiantely confirmed the suspicion that the mixed content was caused by the Active-x control accessing files in the local file system. However, it is only the thumbnail versions of the scanned document that seem to be unsecured, the full size image files are not causing a mixed content problem, though they are stored in the same directory structure. Are there different methods of accessing the files system where some are considered secure and others not? Thanks!
Anonymous
August 12, 2010
@Mixed: Please elaborate-- what are the URLs specifically? IE doesn't care what files the ActiveX control loads. If, however, the ActiveX control directs IE itself to render insecure content (e.g. creates an IMAGE element in the containing document and directs that IMAGE element to load, say, file:///Something.jpg") then that will cause a Mixed Content prompt.
Anonymous
August 12, 2010
I think what you just described above is what is happening. The URLs that are causing the problem look like this: file:///C:/Documents%20and%20Settings/userID/Application%20Data/Capture/Batch/thumb.1.gif. Thanks very much for your help. I guess they will just need to change the app to call the thumbnails to load in the same way that the full size image is loaded. That is why I'm confused, the full sized images are in the same directory structure and they get loaded with no issues. That is why I asked if there were different ways of dealing with local files. Thanks again.
Anonymous
August 12, 2010
What are they doing to load the full-size images? My guess (based on the information provided thus far) is that they're using the ActiveX control itself to display those; since IE has no real idea what's going on in the control, there's no prompt for those images.
Anonymous
August 12, 2010
The comment has been removed
Anonymous
August 30, 2010
We can't seem to get the Protocol Relative URLs to work. This was/is the perfect solution to our problem, as we do not want to deal with changing a user's browser settings for a number of reasons. When we use the Protocol Relative URLs, the images and style sheet located on the non-secure server are not loaded. Any ideas? Thanks, Suzanne
Anonymous
August 30, 2010
@Suzanne: Please provide a repro page. Thanks.
Anonymous
August 30, 2010
Eric, thanks so much for your offer of help. Everything is still on development right now, so I don't have a page to direct you do. We may have figured it out thought. Question....do both the secure and non-secure servers have to be configured to be secure and non-secure for this to work? Someone else said they got, from this article, that the // will take where they are supposed to go from the last protocol from the browser? Any of that true? If not, any ideas why this is not working? Here is the scenario: Application resides on secure server with domain of https://app.domain.com. The app has been designed to have the same look and feel as the website, which resides on http://domain.com where domain.com is the same for both. So as not to store and maintain site images and style sheets in multiple locations, the images and style sheets are all maintained on the non-secure server, http://domain.com and are linked from the secure site https://app.domain.com using the full path currently. The typical use is for visitors to start off on the non-secure site, and click one of the secure links. When this happens in IE, the visitor receives the message asking if they want to download the non-secure content. When the http:// was replaced with //, and we go to the secure page, the visitor is not prompted; the page is simply loaded without the non-secure content. It would also be nice for browsers to recognize that the server in question is the same domain, and not joedreamland.com or something! grin Any help you can provide would be greatly appreciated. Thanks, Suzanne
Anonymous
August 31, 2010
The comment has been removed
Anonymous
September 01, 2010
Hi Eric, Thanks, as always, for your prompt response. Yes, I understand that, and appreciate the link. I was afraid there would be no way around this. Unfortunately, clients many times have to purchase SSL's for this. Seems pretty silly to have to purchase a licence to make a server secure when it doesn't really need to be, and in actuality, is only being done to stop IE from asking the user about mixed content! Any idea how IE9 will handle mixed content? If you have any input, please let pass on the many issues this causes, especially in the case such as ours, where we simply do not want to maintain non-secure shared files such as images and style sheets in more than one place. Thanks again, Suzanne
Anonymous
September 01, 2010
Suzanne, I think you may have a few misunderstandings-- if you don't need your page to be secure, then don't deliver it over HTTPS to begin with! In contrast, if you do need the page to be secure, then you should deliver all of the content over HTTPS. Certificates are not necessarily expensive, and some CAs offer certificates for under $20 per year. We haven't yet announced IE9's changes to Mixed Content handling, but it's worth mentioning that all browsers, including IE9, will remove the lock icon when a HTTPS-delivered page contains insecurely-delivered content.
Anonymous
September 02, 2010
What happens when you would like to use a javascript addon like "addtoany" they offer both a http:// and https:// version of their code. Is there a way for you to check if the page is loading with http:// and load the url with http:// and if the user is on the https:// version of your site (ie. they are logged in) displays the https:// version of their code snippet? Summary: looks for some code that would check if the user is on your http:// or https:// version of your site and to load the correct off site url.
Anonymous
September 02, 2010
@Jasmel: I either don't understand your question, or I answered it already. If you do something like this: script src="//addtoany.com/whatever.js" Then you will find that if your hosting page is HTTPS the request will be made using HTTPS, or if your hosting page is HTTP then the request will be made with HTTP.
Anonymous
September 08, 2010
Is "javascript:void(0)" considered "unsecured" for any particular reason, or is it simply an oversight? Are we going to see this addressed in IE 9, or is this something we're going to gradually see developers pick up on?
Anonymous
September 08, 2010
@Alun: javascript:void(0) is no longer treated as insecure in the IE9 Platform Preview Builds. When IE9 Beta is released, there will be a blog post explaining all of the changes in IE9 when it comes to mixed content.
Anonymous
September 12, 2010
Eric, thanks again for the comments. Sorry for the delay, have tried to post this several times without any luck, maybe this time will work! ;-) Ok, let me try again to explain what we are doing. I do understand when content should be sent securely or unsecurely, and that is exactly what is happening in a sense. We have a website, basically static, sitting where it should, on an unsecure server. The images and style sheets are there, as they should be. We also have an application, which the client wants to look just like the website, using the same images and style sheets, but, for the right reasons, it is sitting on a secure server. There are links from the static website to the various secure applications. As a web developer, I don't want to have to maintain TWO copies of my images and style sheets; I don't want to have to remember nor take the time to make changes to two copies of images and style sheets when there may be changes to the style of the site, etc. SO, we link FROM the secure server/application to the unsecure server/website for the images and style sheets. Does that help? I know that this is done quite frequently, and is not ill thought of by most, although I am sure some may not think it ideal. I do understand that this can be iffy, but we are using the same domain, the secure sever is actually a subdomain of the website's domain; secure=sub.domain.com and unsecure=domain.com. That should count for something. As I mentioned before, it isn't like we are sending them to some off the wall domain, like joesbarandgrill.tv or the like! ;-) Now, with all that said, from your comments this last time, I should have two copies of all of the shared files. As the person maintaining those files, I say there has to be a better way to deal with this! grin Hope that helps. And with that, if you have other suggestions, they are most welcome! Thanks for your help, wisdom, and for being here for us, and thanks for the heads up on IE9. Thanks! Suzanne
Anonymous
September 12, 2010
@Suzanne: From your comment, it's plain that you don't understand what makes a server secure, and why mixed content has the effect of "tearing open" the secure envelope provided by HTTPS. I covered the topic a few years ago here: blogs.msdn.com/.../410240.aspx, and reiterated myself in this post. This has nothing to do with what the domain names are-- only what protocols are used to deliver content. If you want a HTTPS page to remain secure, you must include stylesheets and scripts from HTTPS sites only. Using HTTP content in a HTTPS page means that your "secure" page is not secure any longer. You don't need "two copies" of the shared files-- you can have one server that delivers both secure and insecure content, and simply have two urls (one HTTP and one HTTPS) that points to that same server and file.
Anonymous
September 13, 2010
The comment has been removed
Anonymous
September 13, 2010
The comment has been removed
Anonymous
September 13, 2010
Hi Eric - thank you for your help. The mixed content warning comes up on all our pages. It also comes up on www.drmyattswellnessclub.com/top_includeWCnew1PTABLED.htm which is a fundamental element to all our pages. This is as far back as I can track the problem - I don't know where the swflash.cab element is - it is not something that I have ever (knowingly) built into our page... I don't see where it shows up.
Anonymous
September 13, 2010
The comment has been removed
Anonymous
November 18, 2010
Hi Eric, i tryed the below example mentioned in the forum 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. but its not working bro as you said it was going to https:// but i still receive the same bug. if any solution that would make my client happier. D.Naveen Rahul
Anonymous
November 18, 2010
@Naveen-- if changing a http link to a protocol relative link didn't get rid of the message, that simply means that you have other HTTP links still in the page. If you use IE9 or another browser, you can easily find them by opening the developer tools. Or you can email me the URL of the site and I'll help you find it.
Anonymous
November 21, 2010
I've tried to find the answer to a problem I suddenly found myself having today, but couldn't: If I've (by mistake or otherwise) clicked either yes or no for a particular page, but really wanted the opposite, is there any way to get the question again? We're running XP here, if that is of any importance.
Anonymous
November 21, 2010
@Martin: I'm not sure I understand the question. If you close and restart the browser, your choice in the "Allow mixed content" prompt is reset.
Anonymous
November 21, 2010
That's OK, I'm not sure I'm phrasing it correctly. As I currently don't get the question, I'm not able to be too precise. The first time I visited the mixed content (unfortunately not publicly available) in question, I was prompted as to whether I wanted to view only the secure content or not. I answered with "No", and got to see all the content. I then wanted to test the page using "Yes", but I can't trigger the prompt again. Restarting the browser doesn't trigger it, neither does emptying the cache or restarting the whole computer. My answer seem to be cached and remembered somewhere. Judging from your response, this is not how the answer to that prompt is normally handled?
Anonymous
November 22, 2010
The comment has been removed
Anonymous
November 22, 2010
The comment has been removed
Anonymous
December 09, 2010
@EricLaw - Are there ANY solutions for the src of an iframe in IE6 to avoid this warning dialog if there is no desired source? e.g. Often iframes are use in IE6 as a shim to insert under floated content to overcome the IE6 z-index bug. [[ webbugtrack.blogspot.com/.../bug-111-ie-broke-web-20.html ]] The iframe needs no actual source and we don't want to add another hit to our server (for each and every iframe we use) for a dummy file. Unfortunately as you've noted above, we can't use "about:blank" because that triggers the warning in IE6 (a major bug in the implementation IMHO) and we can't leave the src attribute blank, or exclude it because the default is "about:blank"!!!! (adding insult to injury!) Are there any other options (even if un-sanctioned, un-endorsed, back-door-trickery) to avoid this warning? e.g. does the old "gopher:" or "ftp:" scheme trip up the warning? or would a reference to the already requested ROOT/favicon.ico file cause the warning to go away? e.g. <iframe src="/favicon.ico">? Or would this work... but show the image in the frame if the iframe's content is visible (e.g. if used as a shim, would it hide the icon and skip the warning?) What about the old "about:mozilla"? or is the whole "about:" scheme considered insecure across the board? I kind of wish there was a "null:" or "noop:" scheme now just to avoid all this mess. Gah, I just thought about this... if I have/use a custom protocol, e.g. "icq:12345678"... but there is no "handler" registered for this protocol,... will this work or is IE going to popup the "unknown protocol/handler" dialog now instead?
Anonymous
December 10, 2010
@Gary: I think that by-far your best bet for the dwindling number of IE6 users is to point to a dummy blank page on your server, served via HTTPS. You can set the headers on the page such that it's stored in the user's cache and not redownloaded from the server, so you'd see a max of one additional hit per user.
Anonymous
December 13, 2010
Eric, Regarding the mixed content problem, Would you mind looking at https:secure.exposites.com/bridalbazaar.com/shows.html?show.id=1056&variables.panel=tickets and help me understand what I'm doing wrong? Thanks, Steve Kramer
Anonymous
December 13, 2010
The comment has been removed
Anonymous
December 19, 2010
Hi Eric! We have a little different problem than the others here. We want the webshop on our site to be under https, everything is working fine but we get the mixed content warning and I can see (using httpWatch or you scriptfreesetup.exe) that it is the thesite.com/WebResource.axd thesite.com/ScriptResource.axd thesite.com/ScriptResource.axd that generates the warning. In httpWatch I can see that these files are first called with https but are then redirected to http. Any idea on this? I've been at it for weeks now and I am no closer to a solution. I'm getting really desperate and would appriciate any help or hints at all. Unfortunally I can't give you a link since it is on our test servers.
Anonymous
December 19, 2010
@Andreas: I'm not sure what you're asking. If the server is redirecting from HTTPS to HTTP, you'll need to prevent that.
Anonymous
December 21, 2010
Eric: Would you please look at my website as well (url removed)? I am not sure what is causing the mixed content problem. Please advise.

With Thanks!
Anonymous
December 22, 2010
@Sam: If you're referring to the warning on the page when you click the misspelled "Earings" link-- the mixed content appears to be caused by the malicious content that has been injected into your page. So either you're a bad guy (I hope not) or someone else has stolen your password and is trying to use your server to spread malware. Search your page's source for the word "unescape" to see the malicious content.
Anonymous
December 29, 2010
Eric: Here's a stumper for you... harmony.request.com/.../scott.asp The page pulls in draw2d.js (http://www.draw2d.org). Fiddler, Httpwatch, and Firebug (on Firefox) all report NO unsecure HTTP traffic. There is no indication of any removeChild for elements with a background. We're not even asking the classes for any objects, just the mere loading of the classes is triggering the mixed content warning in IE8. It may be the programmatic addition of a form button via DOM or some other item, but my team of engineers is stumped.
Anonymous
December 29, 2010
The comment has been removed
Anonymous
December 29, 2010
@EricLaw: That has to be the speediest response from anyone I have ever seen. That was the clue we needed. Buried in that JS were indeed many things like this.Hslide.style.background="url(slideHue.gif)";. We added some JS to figure out the host protocol and paths, replaced everything with this.Hslide.style.background="url("+hostURL+"slideHue.gif)"; and all is well. Thank you! Thank you! I will let the people we bought draw2d.js from know how to fix it.
Anonymous
January 09, 2011
@EricLaw: Can u plz have a look at the home page of this site https://www.axisdirect.co.in . When u click on opinion polls i get a https prompt. I've checked in httpwatch no http request is going from there. i've looked at all the above discussed scenarios but am not able to figure out the reason for this.Can u plz help me on this. Also when u click on refresh button of market mood same prompt comes.
Anonymous
January 09, 2011
@Dhaval: You have the same general problem as the last few folks; URLs are being combined incorrectly with the ABOUT: protocol. SEC7111: HTTPS security is compromised by about:../framework/images/special_offers.jpg SEC7111: HTTPS security is compromised by about:../framework/images/tools_and_features.jpg Also, your homepage shows one other configuration problem: HTML1114: Codepage utf-8 from (HTTP header) overrides conflicting codepage iso-8859-1 from (META tag)
Anonymous
January 10, 2011
@EricLaw: Thanks a lot for ur suggestion but can please explain me the last problem that u have mentioned. Do i have to set the header as utf-8 or iso-8859-1 and whether this can also cause the https prompt to occur?
Anonymous
January 10, 2011
@EricLaw: Thanks a lot for ur suggestion but can please explain me the last problem that u have mentioned. Do i have to set the header as utf-8 or iso-8859-1 and whether this can also cause the https prompt to occur?
Anonymous
January 10, 2011
@Dhaval: The codepage issue won't cause HTTPS problems. You can fix it by changing your META HTTP-EQUIV tag so that it properly indicates your charset is UTF-8, or by removing that META tag already. The HTTPS problem is the same problem as encountered by the last few comments (read the comments before yours). It's a bug in IE that you can work around by using a fully-qualified path in your markup... instead of using e.g. SRC="../framework/images/special_offers.jpg" instead use SRC="www.axisdirect.co.in/.../special_offers.jpg", etc.
Anonymous
January 25, 2011
Hi Eric, With regards to the silent removal of the padlock (discussed earlier). I am getting this sympton on a Hilton Hotels web site. The site is www.glasgow.hilton.com/glasgowgiftvoucher After picking dates and room etc. the last page is the page where I have to enter credit card details. As well as the padlock disappearing I notice that the site is trying to load content from px.admonkey.dapper.net, ad.yieldmanager.com, fls.doubleclick.net and many others. I have complained to Hilton and asked if they would take my booking without a credit card but they insist that the site is secure, they say that the padlock not being there is irrelvant and the https shows it is secure. They say I must provide my card details or they will not take my booking. My question is, in your opinion, is this site safe? If not can you give me some information as to why so that I can go back to them or my local Trading Standards office with a more detailed complaint? Many thanks for any help or advice you can offer on this. Derek
Anonymous
January 25, 2011
@Derek: If the lock isn't there, that means that not ALL of the content was delivered securely. Many websites make this mistake, which I first explained over five years ago in this post: blogs.msdn.com/.../410240.aspx. In the Hilton case, yes, it looks like the reservation page pulls in many different tracking/advertising URLs from insecure sources. I definitely wouldn't want to use this page from a public network.
Anonymous
January 25, 2011
Many thanks Eric this feedback is greatly appreciated.
Anonymous
February 01, 2011
The comment has been removed
Anonymous
February 01, 2011
The comment has been removed
Anonymous
February 01, 2011
Looks like I might have it - there was another instance buried in a .js file So far so good...This certainly is an exquisitely frustrating issue for anyone trying to put together a website! Thanks for your help. - Mark
Anonymous
February 01, 2011
@Mark: You'll be happy to know that IE9's F12 Developer tools show the exact insecure URL in the console.
Anonymous
February 01, 2011
>You'll be happy to know that IE9's F12 Developer tools show the exact insecure URL in the console.< That will be really handy! When can we look forward to seeing it? Mark
Anonymous
February 01, 2011
@Mark: The IE9 Beta is out now: http://www.beautyoftheweb.com/
Anonymous
February 07, 2011
Hi I have stumbled upon an even weirder issue with mixed content warning. Check out the site https://ebankbps.pl everything is fine when i enter the url to the address bar or refresh the page. However when you go to http://www.bankbps.pl/bps24/ then click the second link in the center of the page, https://ebankbps.pl opens up in a new window. Now hover your mouse over the login text field and mixed content warning comes up. I would blame the popup script, however it does not happen when i enter the url normally or in any other browser.
Anonymous
February 08, 2011
@Karol: I'm not able to reproduce that problem in current builds of IE9. Using the "ScriptFree" plugin described in earlier comments, I see that the URL which is being treated by IE8 as mixed content is "about:blank".
Anonymous
February 08, 2011
Thanks for looking into it, i tried using ScriptFree but it crashed my browser when mixed content warning was about to show. And i also tried ie9 which works fine. [EricLaw: Yeah, ScriptFree sometimes encounters this problem, which is one reason it's not a released project. If your machine is configured the same as mine, running IE as Administrator for debugging will allow ScriptFree to run without a crash]
Anonymous
February 14, 2011
Eric, first of all thanks for your post, it's of great use! And also thank you for answering to all our question. I tried most of the thing, and can't get where something is wrong. It happend immidiatly in the login page, and with Fiddler there aren't any HTTP non-connect messages. here's the public address: www.regione.lazio.it/accreditamento any hint or tip?
Anonymous
February 14, 2011
@Marco: You hit exactly the same issue as the last few folks; IE8 is constructing the following URL, which it believes is insecure: about:/accreditamento/theme/com/sun/webui/jsf/suntheme4_2-080320/images/other/combinedImage.png This is fixed in IE9. To fix for IE8, change that URL from a relative URL to an absolute URL.
Anonymous
May 10, 2011
Eric, I am developing an intranet site for a client using struts2 and I am running into Mixed Content Warning in IE8. I have run your "Script Free" tool and it is pointed the mixed content to about:<path>/tab_close.gif. Can you please suggest a way to overcome this warning. I am using struts dojo tags to load the div in the jsp. Thanks in advance
Anonymous
May 10, 2011
@viswa: As stated in virtually all of the comments, including the one that immediately precedes yours, the bug in question is fixed in IE9. To fix for IE8, change your image reference such that instead of using a relative URL, it uses an absolute URL.
Anonymous
September 01, 2011
The comment has been removed
Anonymous
October 07, 2011
Eric, Thanks to your "scriptfree" tool I found that my issue was being caused by a reference to a local file from the web page. The message shows that the block mixed content refers to file:///C:/xyz/Temp/abc.jpg Is there any way of referencing and displaying a local file on this page without the mixed content message appearing?
Anonymous
October 26, 2011
Eric, We've run into an interesting variation on this problem that doesn't obviously involve "about". Try visiting www.stewart.net/.../bug.html. No warnings, right? Open the F12 panel and navigate away from the page using the link. Now click the back button. We've been seeing spurious mixed mode warnings like: SEC7111: HTTPS security is compromised by www.stewart.net/.../bg.png That resource is referenced by an inline stylesheet: It's not reliable. Sometimes it fires, sometimes it doesn't. Perhaps more importantly, the on-screen indications of mixed mode content do not appear. We only noticed this because we were watching the console. And on a few occasions, we've then seen javascript be disabled on the page. It's very strange. Obviously that resource is secure. It's a CSS background image loaded from a relative URI.
Anonymous
October 26, 2011
@Jeff: There's a known bug in the IE9 F12 console where it shows a mixed content warning for a resource that wasn't actually blocked. You can tell that it wasn't blocked because there was no user-notification and the resource in question wasn't an image. The warning is innocuous as it's only in the console and doesn't affect functionality. I believe it's getting fixed in IE10. Now, as to the "javascript disabled on the page"-- I have no explanation for that, nor have I heard of anyone encountering a problem like that.
Anonymous
January 21, 2012
I am facing this Mixed content warning in a web page generated by a third party ERP system. The generated html has a iframe with its source attribute src=about:blank. We tried assigned a https url to the iframe src with javascript on page load. Also tried removing src attribute. But even before our javascript code gets executed the Warning message appears. We dont have control over the page generation logic of the ERP system.Considerable number of our customers client machines are still IE 6. Please advise on suppressing this warning. It would be better to find a fix in javascript. we will not be able to set the Security settings for the whole corporate environment because of this site alone. At the same time, we are not sure when the ERP system can provide the fix. Thanks in advance
Anonymous
January 21, 2012
@Nagaraj: Why are you convinced that the frame is the problem?
Anonymous
January 23, 2012
@Eric: There is no http reference in fiddler logs. We are getting 200 as http response for all request for this page. All request and response are through https only. Further the site throws no warning message when we work over http. The only suspect is about reference, about:blank. we zeroed in to this place after trying all options
Anonymous
May 01, 2012
Hi Eric, We have some html pages delivered using a custom protocol. When these pages contain <IMG> tag with image source as http url, IE is showing Mixed mode warning. I'm not able to figure what is delivered using HTTPS here! I feel there a bug in IE which flags content delivered using custom protocol as HTTPS. Can you comment on this?
Anonymous
May 01, 2012
@Suhas: Very interesting. Please provide more details about your protocol (email me). For instance, does it respond True to the QueryIsSecure in IInternetProtocolInfo?
Anonymous
May 02, 2012
My protocol handler implements QueryInfo method of IInternetProtocolInfo and responds TRUE for QUERY_IS_SECURE option. This is causing mixed mode warning. Thanks Eric. You were spot on!
Anonymous
May 31, 2012
The comment has been removed
Anonymous
October 04, 2012
I can't get rid of that annoying, every few seconds, every few clicks pop up about only secure content being displayed, what's the risk?, and show all content. I click "X", it goes away, then comes back. I am NOT a technical person, and simply want to know (1) How do I hide/suppress this constant pop up, and (2) If I do get rid of the pop up visually, will it compromise any security concerns? So please, in as non-technical terms as possible for this old fellow, help me know how to get rid of it, and whether it will compromise security if I do. Thanks. [EricLaw] You should upgrade to Internet Explorer 9.
Anonymous
October 11, 2012
Hi Eric, I read all the posting with interest, but this error message in IE9 still doesn't make any sense to me: "SEC7111: HTTPS security is compromised by https://hostname/saas/spring/img/kyn/KYN_TopLeft.png " It's not an 'about ' issue as stated previously. There is no mixed content here since we are calling a secure URL from a secure location. What am I missing? Here is the html: <img width="95%" height="59" src="/saas/spring/img/kyn/KYN_TopLeft.png" border="0"/>. Why does IE9 believe the URL is unsecured?
Anonymous
April 10, 2013
Here's a nice post from the Mozilla team on blocking Mixed Content in Firefox 23+: blog.mozilla.org/.../mixed-content-blocking-enabled-in-firefox-23
Anonymous
May 06, 2014
FYI, I got the warning while trying to display XML from an HTTPS page. Scriptfree shows that the problem was in res://mshtml.dll/xmltreeview.js.

Compartir a través de