Declaring Security

Recently, a number of people have asked me what I think about Mozilla’s Content Security Policy draft spec.  Back in January, I went on record as being someone who thinks that CSP is a good idea. 

CSP is a mechanism for declarative security, whereby a site communicates its intent and leaves it up to the user-agent to determine how to enforce it.

There are a number of benefits to declarative security mechanisms:

  1. Reduced compatibility risks. Because sites must opt-in and declare what, if any, restrictions they want, new security features may be added to the user-agent with decreased compatibility fallout.
  2. Clear intent. By plainly declaring which restrictions are desired, browsers need not try to “guess” the site’s intent.  For instance, when explaining that frame-breaking JavaScript cannot be relied upon to prevent ClickJacking, Kymberlee noted:
    If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it.

    Because declarative security features are designed solely to mitigate security threats, browsers may implement the restrictions however they want, and can patch any holes found in the restrictions without unexpectedly breaking unrelated functionality.

  3. Usability. By allowing a site to declare its security policy, browsers can make some security decisions on the user’s behalf.
  4. Auditability. It is straightforward to build tools that scan content for policies and determine if they meet the publishing organization’s expectations.

Internet Explorer has a rich history in this space: HTTPOnly, SECURITY=RESTRICTED frames, X-Content-Type-Options, X-Download-Options, X-Frame-Options are all declarative security mechanisms first implemented in IE, and now supported by other browsers to varying degrees. 

The ideas behind the CSP draft are not new, and it is but one of many proposals for declarative security, from BEEP to HTML5 sandboxing.  In some respects it overlaps with other mechanisms for restricting script, although if CSP is successful, new directives will likely be created to provide uniform specification of the available policies.

While valuable, declarative security mechanisms are not without their challenges:

  1. Plugins. Unless plugins have been blocked outright, they must be aware of, and enforce, the declared security policies.  Because plugins are provided by many different vendors, this requirement may prove challenging in real-world deployments.
  2. Misconfiguration.  CSP is only as valuable as the policies configured by the developer or administrator, and a number of major sites have suffered breaches due to misconfiguration of security policy files. Ira Winkler claims [p143] that government studies indicate that 70% of computer intrusions are a result of configuration problems.
  3. New attack surface. The very mechanisms used to implement CSP will be probed by hackers, and comprehensive fuzzing and penetration testing will be required to help mitigate the attack surface added.  Furthermore, if a hole is found that enables an attacker to circumvent a given policy within a given user-agent, that user-agent’s reputation may be harmed-- even if other user-agents do not attempt to support that policy.
  4. Debuggability. Web developers already face significant challenges in developing their pages, and introducing new security policies will require that tools be updated to clearly indicate when content has been blocked due to security policies. Sites might inadvertently set overly restrictive policies and failure to catch mistakes via comprehensive testing could lead to a confusing user experience.
  5. Dynamic content. It may prove difficult to author workable policies for some dynamic-content scenarios (e.g. email composition, blog authoring, etc) because the user may herself add content to a given page from origins unknown to the web developer.
  6. Adoption. Perhaps the biggest challenge for CSP and competing proposals is related to the fact that they offer “off-by-default” security.  While this is great for compatibility, it’s not-so-great for protecting sites and users, because benefits are only attained after web developers update their sites.  To succeed, CSP must balance power/flexibility against simplicity/understandability.

No security technology is a panacea, and for comprehensive protection, I think browsers need to offer both:

  1. Rich security APIs that enable sites to prevent XSS attacks.
  2. Automated protections to shield sites that can’t/won’t update their code immediately / ever.

To combat XSS attacks, IE8 introduced a number of attack-surface-reductions, a few new APIs, as well as the declarative security mechanisms (X-* headers) mentioned above. But we knew that sites wouldn’t immediately adopt these APIs and declarative security features, so we built the XSS Filter, an on-by-default, no-questions-asked, no-code-changes required mechanism which helps mitigate the most common types of XSS attacks in the wild today.

I’m eager to see the progress on CSP, which I believe is a promising approach to helping websites secure themselves against the growing alphabet soup of web threats.  You can provide feedback on the CSP draft spec using Mozilla’s Talk page.

-Eric Lawrence

Comments (11)
  1. stefan says:

    @Eric – A good read and I’m glad to see folks are thinking about this stuff.

    I’m wondering if there is some way to manage this security top-down from a security=FortKnox by default design.

    e.g. if my site is a "social" site called: "", and I’d like to use jQuery as pulled in from Google’s cache, an iframe with GoogleMaps used for a mashup, and ads from "" that sometimes pulls content from ""

    If I had a tool that by default set the most strict of restrictions… but I could tailor it as needed, I could build a site, exposing only what I need as I need it)



    + [_] Can be loaded in another sites frame

          + (_) Any site

          + (_) Specific sites

                + [_] UserDefined 1

                + [_] UserDefined 2

                + [_] UserDefined 3

    Allowed Framed Site

    + (*) None

    + (_) Specific sites

          + [_] UserDefined 1

                + [_] Can initiate downloads

                + [_] Popups

                + [_] …

          + [_] UserDefined 2

          + [_] UserDefined 3


    Thus if I want to use jQuery off a shared server… and Google Maps, or advertising from X or Y… I need to declare it up-front to use it.

    All the site would need to specify at the start is 1 header, which indicates that "Security" is turned on. (off by default for back-compat), but once turned on everything is locked down until explicitly turned on.

  2. Keith Adler says:

    While this seems like a good idea on the surface, I think leaving it to users to try to comprehend what these settings widens the vulnerability surface of the browser.  It’s very likely this feature would be the next "Content Advisor" feature; something that exists and no one complies with or uses.  I would much rather see layer 7 proxies and appliances continue to worry about this.

  3. EricLaw [MSFT] says:

    @Keith: A key design point for declarative security is that it’s not the "user" making the security decision, it’s the site owner.  As I mentioned, there is the risk of misconfiguration, but that would be a mistake on the part of the developer/admin, not the end-user.

    A layer 7 proxy appliance could *enforce* a security policy, but only if it knows what the policy should be.  Declarative security directives enable user-agents to know what the policy should be.

    @stefan: In the CSP proposal, your site would simply describe your desired policy in a policy file; the CSP header would point to that policy file.  CSP currently does not seem to offer granularity to the level you’re looking for (e.g. down to the specific target URL) and this is probably feedback you should provide over on the "Talk" page.

    In terms of tooling, yes, I’d expect that if CSP is implemented and deployed, tools will be developed to help site owners author policy directives.  For instance, you could probably easily write a Fiddler addin that emits a "your current policy" file, based on what a crawl of an existing site turns up.

  4. EricLaw [MSFT] says:

    @Keith: While we’re on the topic, it’s interesting to contrast declarative security against Content Advisor (which, incidentally, is still in use in some parts of the world).

    Content Advisor is based on a system whereby either a site describes its own "Rating" or a trusted reputation service (called a "Ratings Bureau") provides a rating for them.  

    The first scenario suffers from the problem that a given site may not elect to comply and identify its content, and therefore a child/restricted user would be able to view the site.  Thus, you would be correct to note that, because a site may not describe its own policy via CSP, that site would find itself at risk of attacks possibly mitigated by CSP.

    I’m not aware of any broadly used "Ratings Bureaus" for Content Advisor (as this feature is basically now legacy, replaced by Windows Vista Parental Controls and Windows Live Family Safety products) though they may exist in other locales.

  5. Hi Eric,

    Thanks for the write-up, and I’m flattered to be credited as one of the sources for this idea.

    Your possible risks are important; here is how CSP has addressed some of them:

    * Plugins. Quite right – plugins are a law unto themselves. It’s a larger problem to solve but, in the mean time, you can use CSP to disable them entirely or restrict plugin content to whitelisted sites, neither of which has been possible for site owners up to now.

    * Misconfiguration. Always an issue. We hope CSP strikes a balance between being understandable and being flexible :-), and it "fails closed" if the policy is broken. Feedback on how to help people write better policies would be welcome.

    * New attack surface. Because CSP can only increase security, any holes in "CSP" would be holes in a non-CSP browser. Unless they can attack the CSP parser itself; although we hope that the language is simple enough that we can write a secure parser for it 🙂

    * Debuggability. We take this very seriously; policy parsing errors are reported to the Firefox console, and policy violations can be reported to a collector script. This means that even users of non-CSP-aware browsers benefit, because the site owner gets tipped off more quickly about the vulnerability.

    * Dynamic content. No security technology fits everyone. There are some complex pages, like these ones, for which CSP is difficult to implement. Fair enough. Trying to cover every scenario would come with a complexity cost.

    * Adoption. Being a server-side technology, we hope that large sites which embed user content or provide CMSes which do will adopt CSP, thereby deploying its benefits across the web. EBay, Facebook, WordPress, Moveable Type etc. I think memories of the last few Facebook worms will mean that Facebook Towers rejigs their site organization and adopts CSP pretty quickly.


  6. Dan Veditz says:

    We’ve argued ourselves about what the granularity of the policies should be. Origins felt like a workable chunk-size — easily understood, useful, and compact enough for a header-based policy.

    While it’s easy to imagine scenarios where you’d want to whitelist paths or specific resources, we don’t know if it’ll be a common-enough need to be worth the added complexity. Definitely something to think about once we have a beta implementation for sites to play with.

  7. I like CSP because it helps web developers and server administrators to define how content interacts on their sites. And it helps to detect attacks like XSS and data injection. But we need more improvement that helps site owners to prevent XSS attacks.

  8. hAl says:


    You said: "New attack surface. Because CSP can only increase security, any holes in "CSP" would be holes in a non-CSP browser. Unless they can attack the CSP parser itself;"

    But actually in many cases this might replace other security mechnisms and not nescesairily increase security but place it outside a site. And because the security is in a variety of browsers it adds attack surface if sites remove other security defences.

    Whereas security mistiakes in a site only harm the site and the visiters of that site a security issues in a browser is exloitable might wider.

    For websites considering security a extremely important feature to their site this is not good solution because they are unable to rely on all browsers implementing this flawlessly.

    CPS might provide additional security but also has its possible risks if sites start relying on it to heavily

  9. Thanks, Gerv.

    @hAl: That same complaint was made against IE’s XSS filter: "Hey, sites won’t bother fixing XSS holes because IE8 users are protected by the automatic XSS filter."

    The same line of thinking suggests that cars ought not have seatbelts and airbags, because they lead to careless driving.  While there’s some sense in such an argument, fatality rates since the introduction of such mitigations suggest that the benefits still far outweigh the downside.  I believe this will prove true for CSP as well.

    Defense-in-depth is a very well proven philosophy when it comes to software security, and the site operators I’ve spoken to all recognize that features like the XSS Filter and declarative security mechanisms are necessarily additive, particularly considering browser adoption curves.

  10. CLhandbook says:

    Very interesting and it’s nice to know that these benefits are implemented. This way we can search over the internet without much fear about XSS attacks. There are lots of web threats circulating now and it’s nice to know that Mozilla works in protecting their users from these attacks.

  11. EricLaw [MSFT] says:

    @CLHandbook: I think it’s important to understand that this is a *proposal* and not something that has been implemented by any browser at this point.  As described above, IE8’s XSS Filter provides protection against common XSS attacks without requiring changes to websites to "opt-in."

Comments are closed.

Skip to main content