Handling Mixed (HTTPS/HTTPS) Content

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.

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


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:


    <script type="text/javascript" id="contentloadtag" defer="defer" src="javascript:void(0)">


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 (128)

  1. Whiner says:

    Why you can’t turn off this warning for trusted sites.  Time to switch to Firefox…

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

  3. Trent Harvey says:

    So, basically the only option was to be royally annoying to anyone who visits many major sites?… Google included.  I understand the security concerns, but this new message box is actually more misleading than any of the previous ones.  Additionally, there shouldn’t be an all or nothing when considering this option.

    The box is misleading in the sense that when you read the warning, it is inverse to most warning-prompts where they ask you "Do you want to show the content?" and you click yes, here, its "Do you want to block the content?" and you have to click No.  So when you see "Mixed Content", your initial response is to say "yes! show that content to me" (if you understand the risks and don’t want the page to break).  However, when users click that, the page breaks anyways.

    Furthermore, when you consider what to do to get rid of this sometimes very annoying pop-up, you can either go "Totally Accept", "Totally Reject", or "Annoying Pop-Up".  What would, perhaps, be more appropriate would be a sort of "Whitelist" that will automatically accept traffic from certain websites.  This way, users who frequent certain sites and trust them can disable the prompt on that site only, but still get the prompt if they visit a new site which has the vulnerability.  Users could add sites to the whitelist directly from the prompt and then remove sites at a later time from the Internet Options dialogue.

    This just seems like a much more practical solution than creating a terrible browsing experience on major websites which haven’t bothered to upgrade to standards, potentially only in the sense of their banner ads display from HTTP instead of HTTPS.

  4. If a major site isn’t using HTTPS properly, blame should properly accrue to that site, and the site should be fixed.

    As to the "polarity" of the dialog box, this is something which had a lot of internal debate. However, the complaint that "Users will unthinkingly make the secure chioce" isn’t really a criticism from a security point of view.

    As to the idea of creating an "Allow list of sites that don’t use HTTPS properly"– sure, you could do that, but users would likely (legitimately) wonder "Why don’t I see a lock icon on this HTTPS site?"  We know (from asking users) that they assume this is a browser bug, not a site problem. Opera chose to allow this insecurity but puts up a snarky "This page tried to use security measures, but failed" message which makes me laugh every time I see it.

    Older versions of Chrome used to silently allow Mixed Content, putting the integrity of the page at risk without permission of the user. However, Chrome 2.0’s Dev branch has a cool new feature, whereby they block executable content (e.g. script) by default and overlay all insecurely-delivered images with a "not secure" layer.  It’s a cool idea, and it will be interesting to see if the research community is able to poke holes in it.

    Personally, I take the stance that "HTTPS should mean that this page was delivered securely" and thus I choose the "Disable mixed content" option. There’s no sense locking the front door and leaving the window open.  

  5. Chris Deel says:

    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.

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

  7. Ben Stragnell says:

    @eric: Thanks for the quick response!

    I’ve set up a test page that exhibits the problem:


    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!



  8. Fascinating. This is a race condition.

    The debugger reports that the following is the URL that is triggering the prompt:


    Of course, that URL doesn’t actually exist in your markup.  It looks like there’s dynamic creation of an IFRAME and injection of content into that frame. The default URL for an empty frame is about:blank, which leads to the prompt.

    As a workaround, using an absolute URL would probably work, or by initializing the IFRAME with a the SRC of a blank page on your server (this should also fix the Mixed Content problem with IE6).

  9. Ben Stragnell says:


    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.



  10. ACHecht says:


    >If a major site isn’t using HTTPS properly, blame should properly accrue to that site, and the site should be fixed.

    I read this blog post after spending countless hours with end users who were experiencing an issue with web content we create.  However, our firm does not have direct access to the secure server.  Instead, we leverage that server to distribute our own content to end users.  So while the above sentiment would be nice in an ideal world, the current world is not always ideal.

    What bothers me the most about the change to IE’s security warning — apart from the fact that it has single-handedly cost us significantly in terms of recent help ticket resolution — is this:

    1. There was no vetting or advanced notice of the change to IT firms or the IE community at large…no way to prepare or even be aware of the chagne in advance.  It was actually quite difficult to even find this blog post after the issue was identified by our team.

    2. It takes an existing process (clicking "Yes" when the user visits the same web site he or she has been visiting successfully for the last 6 or more years) and inverts it.  For many users, clicking "Yes" on the previous security warning had slowly come to mean "Yes, show me the damn page already!"  Now the process of "agreeing" with IE with an affirmative response was breaking the website.  In the very least, the first time the new browser had this instance, it should have delivered the message in a different way — other than a too-familiar dialog box method — that the question polarity had changed.  Or add the explanation, "If you are visiting a familiar website and are unable to see all the content, consider answering the security question differently."

    As it is, my department now has literally hundreds of users to educate on the polarity difference and retrain a behavior that has become ingrained over the last few years — all due to the whim of a dialog box and the programmers that made it.  We would love to just abandon IE in favor of another browser, but sadly that is not always an option for some of our constituents.

  11. Chris says:

    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?

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

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

  14. Sam says:

    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!

  15. EricLaw [MSFT] says:

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


  16. EricLaw [MSFT] says:

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

  17. Odinhaus says:

    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?

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

  19. Rene F. says:

    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.

  20. EricLaw [MSFT] says:

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

  21. Nachiket Joshi says:

    Hi Eric,

       I have this problem on my site. I know it is being caused by an ad.doubleclick URL which is happening over HTTP. But I cant locate this in the code.

       Do you have any thoughts on this.

    Thanks already since your post here was very informative.

  22. @Nachiket: If you post the URL of your site, I can easily tell you where the insecure request is coming from.

    The simplest way to find an insecure HTTP reference is to clear your cache, run Fiddler, capture the complete load of your site, hit CTRL+F, tick the "Decode Compressed Content" box, and then type in the hostname of the insecure reference in the Find box.

  23. Jason Southwell says:

    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?


  24. EricLaw [MSFT] says:

    @Jason, you have exactly the same problem as Rene above.


    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.

  25. Jason Southwell says:

    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.

  26. Jason Southwell says:

    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.

  27. @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:






  28. Miki says:

    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)


  29. Ralph Manis says:

    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!


  30. @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>)

  31. Bryan says:

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

  32. EricLaw [MSFT] says:

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

  33. Rock T-shirts says:

    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!


  34. EricLaw [MSFT] says:

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

  35. Rock T-shirts says:

    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.


  36. Rock T-shirts says:

    Success! Thanks for all your valuable research and information!!

  37. Nick says:

    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?

  38. Nick says:

    And obvisuoly I forgot the link: http://www.restaurantfurniture.net

    The home page is completely clean but still alerting with insecured content.

  39. EricLaw [MSFT] says:

    @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?

  40. Nick says:

    I’m using IE8 and also tried it on IE7.

    I’m not sure what you mean by "ScriptFree" extension.

    I appreciate the help.

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

  42. Nick says:

    I get the javascript:void(0), the thing is there is nothing in the code..

  43. EricLaw [MSFT] says:

    @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>");

  44. Martin says:

    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!

  45. Kyle says:

    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?

  46. EricLaw [MSFT] says:

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

  47. Tabba says:

    Hi Eric, thanks for the post and of course thanks for fiddler! May I suggest that the MoreInfo button on the dialog would be alot more helpful if it actually listed the path of the resources that were insecure (then it could have the help-file button on that dialog). This information is not only incredibly useful to developers trying to secure their sites (witness the posts here!) but it is also pertinent to *any* user who encounters this message and allows them to take a slightly more informed choice of the risks. Besides each file listed there could even be specific security info for the file-type (e.g. low-risk images, high-risk forms etc). For developers, it's great that tools like Fiddler & the EnhanceIE script exist, but the answers should simply be revealed in IE; at the moment it feels like IE knows the answer but purposefully withholds it so that developers have to embark on a sort of insecure-resource-treasure hunt (that isn't actually that much fun)! Thanks again for fiddler, can't say it often enough!

  48. EricLaw [MSFT] says:

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

  49. Tabba says:

    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

  50. TD says:

    I have tried the option that is mentioned above. But even after allowing the Mixed content, I'm still getting the prompt. Any ideas?


  51. EricLaw [MSFT] says:

    You likely set the option for the incorrect zone. Do you have a repro URL?

  52. Mixed Content Misery says:

    Eric, I've got a web app that should run over HTTPS.  However, we as many other have, are running into the mixed content issue.  The application in question is Activ-x-based and uses java scripting.  Via Fiddler I can see no calls to any other web site other than the proper URL.  However, our developers seem to think that the issue is casued by the Active-x component accessing files that are stored on the local PC's file system, outside of the Browser's cache.  The app allows users to select a batch of documents that has been scanned and stored on the server for review.  The client downloads a set of thumbnail representations of the full sized images and stpres them in a set of applciation-specific folders.  We believe that IE is viewing the locahost's file system as a zone separate from Internet, Intranet or Trusted.  Any thoughts?

  53. EricLaw [MSFT] says:

    @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?

  54. Mixed Content Misery says:

    @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?


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

  56. Mixed Content Misery says:

    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.

  57. EricLaw [MSFT] says:

    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.

  58. Mixed Content Misery says:

    I wish I knew what they are doing.  I'm just the services guy who is trying to prevent a huge customer sat issue.    However, the client is segmented into components (from a UI point of view) and I could easily see the Active-x controls working in some sections and not in others.  While I can't fix it, you've given me invalueable information that really pin-points the issue and removes any argument that IE is not working as it should.  Thanks again.

  59. Suzanne says:

    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?



  60. EricLaw [MSFT] says:

    @Suzanne: Please provide a repro page.  Thanks.

  61. Suzanne says:

    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.  



  62. Suzanne: A URL without a scheme (e.g. "http:") specified at the front is considered "protocol-relative." In HTML pages, the URL is relative to (and hence combined with) either the URL of the containing page, or to the URL specified in the BASE tag, if such a tag is present in the HTML HEAD. So, if you're on https://foo/ and you have a reference to //bar/, then that URL is really "https://bar/&quot;. However, if you load the same page on http://foo/, then //bar/ then refers to "http://bar/&quot;.  So, yes, generally speaking, if you want to use protocol-relative URIs, then you must ensure that your destination resource is available using the same protocol(s) as the HTML page that uses those resources.

    You can use a Web Debugger like Fiddler (www.fiddler2.com) to understand what your HTTP/HTTPS requests are returning from the server.

    In your scenario, the server in question is not "same-origin." You should read blogs.msdn.com/…/private-domain-names-and-public-suffixes-in-internet-explorer.aspx to understand why that is.

  63. Suzanne says:

    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,


  64. EricLaw [MSFT] says:

    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.

  65. Jasmel says:

    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.

  66. EricLaw [MSFT] says:

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

  67. Alun Jones says:

    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?

  68. EricLaw [MSFT] says:

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

  69. Suzanne says:

    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.



  70. EricLaw [MSFT] says:

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

  71. Mark says:

    I have been tearing my hair out trying to correct whatever is causing this mixed content warning – I have looked high and low for any instance of a http path, and also looked for anything untoward re: src= problems as has been described in your article. I can find nothing amiss… but perhaps I'm just missing it. I would be grateful if you would look at http://www.drmyattswellnessclub.com and tell me what I am missing. I am a nurse, not a code-writer. This kind of problem makes us crazy here and takes vital time away from my real job – patient care! Your (or anyone's) help will be appreciated.

  72. EricLaw [MSFT] says:

    On which page specifically do you see a warning– the homepage itself?

    SEC7111: HTTPS security is compromised by download.macromedia.com/…/swflash.cab

    You should remove the VERSION attribute on that URL and change the HTTP to HTTPS.

  73. Mark says:

    Hi Eric – thank you for your help. The mixed content warning comes up on all our pages. It also comes up on http://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.

  74. EricLaw [MSFT] says:

    @Mark: The content in question is the installer for Adobe Flash. It's used in your "peel corner" OBJECT tag which you've named "eselcornerSmall"

  75. Naveen says:

    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

  76. EricLaw [MSFT] says:

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

  77. Martin says:

    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.

  78. EricLaw [MSFT] says:

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

  79. Martin says:

    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?

  80. EricLaw [MSFT] says:

    @Martin: Correct, there's no persistent cache of that decision. It's possible that you hit a timing-related race condition (bug). You might try deleting your browser history (cookies and temp files) and then try loading the page again.

  81. Martin says:

    Some kind of race condition does seem plausible, as the page is a bit complex, mixing protocols and servers in various ways.

    For some reason, I got the prompt again today, once. Once was all I needed for the testing.

    Thanks for your time and effort!

  82. Gary says:

    @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?

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

  84. Steve Kramer says:


    Regarding the mixed content problem, Would you mind looking at


    and help me understand what I'm doing wrong?


    Steve Kramer

  85. @Steve: You've hit the same problem that many folks seem to be hitting; there's a race condition where a relative URL is combined with the "about" protocol and is being deemed insecure.

    SEC7111: HTTPS security is compromised by about:Content2Background.png

    SEC7111: HTTPS security is compromised by about:ShowsPhoto.PNG

    Are you using the latest version of any script libraries you're using? I assume your code creates a new frame at "about:blank" and injects content into that?

  86. Andreas Ljung says:

    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




    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.

  87. @Andreas: I'm not sure what you're asking. If the server is redirecting from HTTPS to HTTP, you'll need to prevent that.  

  88. Sam says:

    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!

  89. EricLaw [MSFT] says:

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

  90. Scotty B says:

    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.

  91. EricLaw [MSFT] says:

    @ScottyB: You've hit the same problem that many folks seem to be hitting; there's a race condition where a relative URL is combined with the "about" protocol and is being deemed insecure.

    SEC7111: HTTPS security is compromised by about:window_toolbar.png
    SEC7111: HTTPS security is compromised by about:window_bg.png
    SEC7111: HTTPS security is compromised by about:slideHue.gif
    SEC7111: HTTPS security is compromised by about:slide.gif
    SEC7111: HTTPS security is compromised by about:SatVal.png

  92. Scotty B says:

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

  93. Dhaval D says:

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

  94. @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)

  95. Dhaval says:

    @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?

  96. Dhaval D says:

    @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?

  97. @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="http://www.axisdirect.co.in/…/special_offers.jpg&quot;, etc.

  98. DerekT says:

    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 http://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.


  99. EricLaw [MSFT] says:

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

  100. DerekT says:

    Many thanks Eric this feedback is greatly appreciated.

  101. Mark says:

    Hi Eric, This mixed content warning is making me crazy! Here is the page that is giving me fits: http://www.drmyattswellnessclub.com/…/indexTEST.html


  102. Mark says:

    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

  103. @Mark: You'll be happy to know that IE9's F12 Developer tools show the exact insecure URL in the console.

  104. Mark says:

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


  105. EricLaw [MSFT] says:

    @Mark: The IE9 Beta is out now: http://www.beautyoftheweb.com/

  106. Karol Rybak says:

    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.

  107. EricLaw [MSFT] says:

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

  108. Karol Rybak says:

    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]

  109. Marco L.C. says:

    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: http://www.regione.lazio.it/accreditamento

    any hint or tip?

  110. EricLaw [MSFT] says:

    @Marco: You hit exactly the same issue as the last few folks; IE8 is constructing the following URL, which it believes is insecure:


    This is fixed in IE9. To fix for IE8, change that URL from a relative URL to an absolute URL.

  111. viswa says:


    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

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

  113. rsbrux says:

    As Whiner stated, I too am unable to fix this for trusted sites only.  I use MSIE 8 under Win7 Enterprise x64 (not my choice) and have "enable mixed content" for my "trusted" zone.  Nonetheless, many sites in this zone produce th "mixed content" prompt dialog.  I don't wish to allow mixed content on all sites.

    [EricLaw: As noted, the setting applies to the zone of the source of the insecure content, not the page that contains the references to that insecure content. You've reconfigured the wrong zone. Also, as I pointed out, the notion of using Trusted Sites as a cue to ignore mixed content misses the entire threat of how mixed content actually gets exploited.]

  114. Paul says:


    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?

  115. Jeff says:

    Eric, We've run into an interesting variation on this problem that doesn't obviously involve "about".  Try visiting http://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 http://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.

  116. EricLaw [MSFT] says:

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

  117. Nagaraj says:

    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

  118. EricLaw [MSFT] says:

    @Nagaraj: Why are you convinced that the frame is the problem?

  119. Nagaraj says:

    @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

  120. Suhas says:

    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?

  121. EricLaw [MSFT] says:

    @Suhas: Very interesting. Please provide more details about your protocol (email me). For instance, does it respond True to the QueryIsSecure in IInternetProtocolInfo?

  122. Suhas says:

    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!

  123. Pete says:

    Hi Eric, lots of fantastic information on this page. I'm currently struggling with an AJAX application which is intermittently generating mixed content warnings on IE 8. The vendor for the application is stating that they will not fix the problems since they would like all clients to move to IE 9 or some other modern browser, but unfortunately our industry is rather conservative so that isn't really a good answer for us.

    I've debugged the vendor's JavaScript (thanks to Fiddler's autoresponder feature) and fixed quite a few places where the code manipulates the DOM causing the mixed content warning to appear. In no situation are we actually issueing HTTP requests – the warning is generally caused by issues such as removing DIVs with background image tags (which I believe is a known IE 8 issue).

    Sadly, I'm still seeing issues so was looking for advice as to how I can find out which piece of JavaScript is causing the problem. I've tried installing the Scriptfree addin, but it's not telling me anything – would I expect Scriptfree to pop up a window whenever the mixed content warning appears? Or does it indicate the URL in some other way? Is there perhaps some other mechanism for debugging and intercepting the line of JavaScript that's causing the error? Would I be able to make sense of anything if I used Visual Studio to debug IE itself?

    Sorry I can't point you to an example site with the problem – as I say, it's a third party application (which I'd rather not name :)) and is running on servers within our corporate LAN.


  124. Larry L says:

    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.

  125. Cyril N says:

    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?

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

  127. John Saunders says:

    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.

Skip to main content