Rely on Declarative Security Features in the Browser

Cutting edge web applications push the boundaries of the web development model. In the security space, this raises an interesting question – who owns security for a web application built on a complex platform hierarchy? Is it the application at the top of the stack, the intermediate platform component, or the browser itself?

We believe that web application security is a shared responsibility between the browser client, web platform components (such as ASP.Net), and web applications themselves. Any shared security responsibility can potentially lead to finger-pointing whenever a vulnerability is encountered. This is why we endorse the application of declarative security features that clearly assign responsibilities at design-time.

An Example

A recent paper by UC Berkeley researchers demonstrates some very interesting flaws affecting highly complex new web platforms. One of these issues involved the use of the postMessage API supported in IE8 to post a cross-domain message with the use of a wildcard targetOrigin parameter. A targetOrigin parameter configured as a wildcard allows the message being passed to leak out to any target, without validation. This potential information disclosure threat is why the developers of the specification required targetOrigin to be explicitly set by the caller:

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.


One reason Microsoft helped participate in the working group developing the HTML5 Web Messaging specification was to ensure that the result could be implemented “secure-by-default” in products such as Internet Explorer.

We have updated our postMessage API documentation to better reflect the security implications of the targetOrigin parameter.

In this example the browser provides a primitive that, if used correctly, enables a secure platform feature. A more pointed observation is that the techniques predating the postMessage API just do not provide a reliable way to ensure messages are delivered securely.

How Declarative Security Guarantees Help

Used appropriately, declarative security features in the browser enable new scenarios while allowing web application developers to avoid potentially unreliable application-level hacks. These features ultimately help reduce some of the uncertainty and complexity around securing web applications. Rather than relying on incidental browser behavior to achieve a security objective, the browser itself explicitly provides a solution.

There are numerous declarative security features offered in modern browsers. Here is a list of a just a few:


IE Versions



IE8 and up

Prevents a page from being framed, mitigating ClickJacking attacks

The “secure” bit on cookies

All supported versions of IE

Prevents cookie leakage to non-secure sites, mitigating man-in-the-middle cookie disclosure attacks

HTTP-Only cookies

IE6 and up

Prevents direct theft of cookie-based session IDs in the event of a cross-site scripting vulnerability


IE8 and up

Enables web apps to strip potentially malicious script from HTML on the client-side


IE6 and up

Disables script execution in a frame, allowing safer hosting of external content

To summarize, it is important to take full advantage of the declarative security features that the browser provides. Proper configuration of the targetOrigin parameter when using postMessage is one example. As you create and threat model web applications, rely on underlying platform technology as much as possible to help mitigate threats. Just take care in using these technologies to ensure that your security goals are ultimately met.

David Ross
Principal Security Software Engineer
Microsoft Security Response Center

Comments (15)

  1. Curious in Seattle says:

    Is there a column for what the other browsers support?

  2. EricLaw [MSFT] says:

    @Curious: The "Secure" bit and HTTPOnly are supported by all modern browsers. X-Frame-Options is everywhere except Firefox (…/combating-clickjacking-with-x-frame-options.aspx). I believe toStaticHTML has yet to be implemented by others. Non-IE browsers don't have a "Restricted" Sites zone, so they don't offer the SECURITY=restricted attribute (HTML5 frame sandboxing is the closest analog, but it has significant differences).

  3. Stable Chrome says:

    Why are you still using old stable Google Chrome 4.1 on Windows Internet Explorer Testing Center? Newest 5.0.375.70 version have been available for a long time now.

  4. Mitch 74 says:

    @Curious, EricLaw: in Firefox, NoScript provides both features:

    – respect for toStaticHTML: not exactly, but an unknown domain sees its scripts disabled by default – to the same effect – and XSS is blocked

    – X-Frame-Option is supported (as pointed out in the blog post Eric pointed to)

    Additionally, only specified domains get script execution rights.

    Of course, NoScript isn't built-in by default, and is a bit of a drag; however, I've yet to find anything coming close to it in matters of XSS protection, hidden handlers and stuff. The fact that it's an extension allows it to be updated out of band, which is rather a plus.

    But then, you know the saying: security is inversely proportional to convenience – and NoScript is rather more inconvenient than any browser's security settings convenience.

    Still, this post does give some useful information on how one can issue settings to tighten security server-side; a framework allowing easy detection of user agent security features would be useful too, though. I winder what's up with that in the HTML5 WG.

  5. steppres says:

    It makes me feel safer knowing that when I view lolcats I won't get hacked.

  6. Matt says:

    Statistically, no one has NoScript installed *and* configured properly, so it's a bit of a moot point. And the "false positive" rate is so absurdly high that this is not likely to change.

    By allowing the server to declare its own security policy, it can help mitigate many types of attacks without false positives.

  7. David says:

    I would like to make a suggestion for IE9. I've tried putting it on Microsoft Connect but it seems that only feedback on bugs are accepted.

    This may seem like a no brainer but 9 out of 10 times when I want to delete cookies it is only for a single domain. I would like the ability to right click on a page and delete all cookies for that domain. I shouldn't have to delete all my cookies (or search my cookies for one file) because of one annoying website.

    Another suggestion. I noticed in the Test Drive Suite (DOM Range & Selection) demo there is the ability to highlight and translate text. Shouldn't this be a global browser functionality and not something for individual developers to create? IE9 should let the user highlight any text and translate it directly in the DOM.

  8. Wurst says:

    The HTTP-Only implementation of Firefox is better than the one of IE:

  9. Wurst says:


    I believe people are not changing the default configuration in most cases or are you saying that the default settings are not strict enough?[*]

    And even if you have NoScript in opt-out mode with the XSS filter activated you will still have X-FRAME-OPTIONS support.

    [*] I would even agree with you on this point. IMHO, plugin content should be blocked even on whitelisted sites per default, also it's a shame to see people who have unnecessarily NoScript and Flashblock installed

  10. Neil Dunensach says:

    @Matt – "Statistically, no one has NoScript installed *and* configured properly"

    So you have access to every single installation of NoScript world wide and know for a fact NO-ONE has it configured right?  That's a hell of a job you got there buddy.

  11. EricLaw [MSFT] says:

    @Wurst: I'm not sure I understand your statement? If you're saying that you can use XHR to retrieve a Set-Cookie2 header, that is true, however IE doesn't support Set-Cookie2 (I don't even know that FF does either) and hence almost no sites ever send that header.

    The HTTPOnly token was never defined for the Set-Cookie2 grammar in RFC2965, so complaining that a browser that doesn't support Set-Cookie2 also doesn't restrict access to that header based on a token not even defined for that header seems a bit silly.

  12. Wurst says:

    @EricLaw: It's not specifically about Set-Cookie2, IE allows the retrieval of cookies marked as HTTP-Only through certain Javascript functions.

  13. EricLaw [MSFT] says:

    And to which "certain Javascript functions" do you refer? (Mozilla's bug database isn't always a good source of reliable information about IE.)

  14. =O( says:

    IE is like the BP oil spill of the internet

  15. Neil Dunensach says:

    @Eric – "Mozilla's bug database isn't always a good source of reliable information about IE"

    Nice one 🙂

Skip to main content