A Security Prompt that makes you go “Huh?”…

Every few months, a Microsoft employee will send me an email complaining that Internet Explorer showed them the following dialog:

This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?
This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?

…and they don’t understand the question or how to answer.

This prompt is called the “Cross-domain data access” dialog, and it’s shown when a page makes a call that would violate same-origin-policy . The most common case where this occurs is when a site attempts to use the XmlHTTPRequest object to download data from a different origin, although there are a few other possibilities:

  • When loading and XML-document cross-origin using MSXML
  • When an OBJECT tag is pointed at an cross-domain HTML file (in legacy document modes)
  • When some other control is using an InternetSecurityManager to permit selective violation of same-origin-policy

This dialog is shown when a same-origin-policy violating request is made and URLACTION_CROSS_DOMAIN_DATA is set to URL_POLICY_QUERY. When a ProcessURLAction call returns Query, it means “Ask the user to decide.”

By default, this URLAction is set to URLPOLICY_ALLOW in the Local Computer Zone (Security Template: Low), to URLPOLICY_QUERY in the Intranet Zone (Security Template: Medium-Low) and to URLPOLICY_DISALLOW in the Internet, Trusted, and Restricted Zones (Security Template: Medium or higher). Therefore, in a default configuration, this dialog is only seen on sites in the Intranet Zone; in all other zones, access to cross-domain data is either allowed or blocked with no notice to the user.

As the clunky icon and ambiguously-phrased text suggest, this is a very old security prompt and it only still exists for legacy compatibility. If we had no legacy compatibility burden, we simply would set the URLACTION_CROSS_DOMAIN_DATA policy to URLPOLICY_DISALLOW for all zones and never ask the user to make such a decision. Of course, Group Policy can always be used to change the default setting to either Allow (strongly discouraged) or Deny (recommended) cross-domain data use in the Intranet Zone. It’s strongly discouraged to set this to Allow by default because if you do so, any webpage on your Intranet can make any request to any other server on your Intranet using the user’s credentials and without their knowledge.

If your Intranet applications rely upon cross-domain data, then it’s strongly recommended that you redesign them to utilize a better pattern and not subject users to this prompt. Alternatives include:

  • Have the web server itself make a back end webservice call (aka server-side proxy)
  • Download cross-origin data using the XDomainRequest object
  • If you trust the partner site, use the JSONP pattern
  • If you trust the partner site, embed an IFRAME, and use postMessage if needed


Comments (6)

  1. k3n says:

    I'm gettin deja vu…


    I think it's a shame that the hands-down best tool to troubleshoot this problem appears to only be mentioned on page 3 of the comments of that prior article — scriptfreesetup.exe [1]. The last time that I had to troubleshoot this issue I spent days and days and days trying to track it down, and then I installed that tool and found the problem in 30 seconds. I checked on enhanceie.com and could not find the tool mentioned or linked anywhere.

    Why hide such a great tool? Why can't IE have something of the sort built into the devtools?

    [1] http://www.enhanceie.com/…/scriptfreesetup.exe

  2. @k3n: ScriptFree is a plugin I wrote for an entirely unrelated purpose (as its name implies) and it's not production-quality by any stretch of the imagination. For instance, it tends to crash if you don't run IE as Admin.

    As I noted in the Mixed Content case, the IE9 Dev Tools *do* expose mixed content information in the console. Unlike the Mixed Content case, the issue described in this blog post is so rare that troubleshooting isn't really required for any meaningful number of developers. Furthermore, you can trivially see the root cause of this dialog using Fiddler; simply wait for the network to become idle, then choose "Yes", and the next HTTP request was the problem.

  3. k3n says:

    My mistake for only skimming the article, I thought this was simply new verbiage for the same old problem.

    Any reason you advocate Fiddler over IE9's network tab for this? I'm hoping to get away from Fiddler once we upgrade to IE9, not because it's bad but because it'd be 1 less tool to maintain. Speaking of finally updating, I hope someone realizes how much of a hindrance the OS requirement of IE9 is on user adoption. My company services some of the top companies in the U.S., and all of our software is IE-based…..for now…..things like the Win7 restriction and OS-dependency are pushing us away from that, though.

  4. The IE9 Network tab works just fine for this.

    I said Fiddler because:

    1> It works with any version of IE.

    2> I wrote Fiddler and thus *always* have it running.

    There is no "Win7 restriction" for IE9. It runs just fine on Windows Vista and Win2k8. Windows XP isn't in mainstream support any longer and will be exiting extended support before long.

  5. Andrew Myers says:

    In case this is helpful for someone running Visual Studio 2013. I had upgraded my Visual Studio from 2010 to 2013 and then started seeing the seurity message. Using Fiddler I found that VS 2013 kept sending arterySignalR requests.

    I turned this off by setting the following in the web.config under appSettings.

    <add key="vs:EnableBrowserLink" value="false" />

    the security error went away.

  6. cward@iimage.com says:

    Thank you, Andrew.  This was the issue we were having when upgrading to VS2013 from 2010 and enabling Framework versions 4.5+.  This error had caused a couple of javascript functions to stop working.

Skip to main content