Mozilla Security Blog
Categories: Firefox Security

Creating a Safer Web with Content Security Policy

Al Billings

6 responses

One of the new features in Firefox 4 that we are very excited about is Content Security Policy, which is a mechanism that works behind the scenes to prevent some of the more severe web-based attacks against users and websites.

Firefox users don’t have to do anything in order to gain this protection. Simply install Firefox 4 and you will instantly receive all of the benefits that Content Security Policy has to offer. Easy!

If you are a web developer who wants to learn how to deploy this feature on your site, head over to the Mozilla Developer Center and see how easy it is to write a policy.

We expect Content Security Policy to be widely adopted very quickly. There are popular commercial websites like Twitter who are already using it, and there are CSP plugins for many of the popular content management systems like WordPress, Django and Drupal. If this works out according to plan, the curtain will soon be coming down on a broad range of nasty web bugs!

Brandon Sterne
Man-in-the-Middle

6 comments on “Creating a Safer Web with Content Security Policy”

  1. Glaserei Hamburg – Schauer wrote on

    Thanks a lot for this post, it helped my a lot to understand the new Firefox ability.

  2. PK wrote on

    This is a Great Feature. But i was just wondering this method puts the onus of configuring the policy with the site owner. Just like crossdomain.xml of flash security many users would rather change the setting to wild card over a period of time to support new scripts and features.

    this was just a thought sorry if was rude.

  3. Daniel Veditz wrote on

    PK: this absolutely puts the onus on the site author — only the site author knows what should and should not appear on their site. Browsers are designed to parse and render what they find, and if what they find is an attack then that malicious content will be included — it all looks the same to the browser.

    The feature is completely optional. If the site author was just going to use wildcards then they should skip CSP. But if they want to do the work to specify their policy then the browser can cooperate with them in enforcing those restrictions.

  4. Berufsmoden MST wrote on

    I think it was about time for this future, i really like to see how its working

  5. Daniel Bachfeld wrote on

    Hi!

    Your doc center states that CSP can mitigate clickjacking. Does that mean that if Facebook delivers the header “X-Content-Security-Policy: allow ‘self’ *.facebook.com; frame *.facebook.com” this will prevent loading Facebook into an iframe if an external site tries to open it?

    Or does it mean that Facebook only is allowed to open Facebook-Content in frames? Compared to that the header “X-FRAME-OPTIONS: DENY” will always prevent to open content in an iframe.

    1. Brandon Sterne wrote on

      @Daniel,

      The policy you stated (modified slightly to allow 'self' *.facebook.com; frame-ancestors *.facebook.com) works as you first expected it: any page served with that policy is restricted to be framed only under *.facebook.com top-level pages. An external site trying to frame such a page would receive an error page in place of the iframe. (The frame-src directive controls what sites may be used as iframes inside the document, incidentally.)

      The frame-ancestors directive is similar to X-Frame-Options in that they both restrict frame embedding from the perspective of the framed site. frame-ancestors is a slight improvement over X-F-O, though, as it supports a list of trusted sites (rather than DENY|SAMEORIGIN), and it restricts every window in the document’s parent chain (instead of just the top window).

      That being said, there is some talk of improving and standardizing X-Frame-Options (probably including renaming it) to be more like the current frame-ancestors directive, in which case we could probably jettison it from the CSP standard, since it arguably belongs in a separate category of embedding restrictions rather than content restrictions within the protected document. All good fodder for discussion on public-web-security…