More Content Security Policy work

Firefox seems to be the only browser strictly enforcing the X-Content-Security-Policy header at the moment. This is both good and bad: good because it doesn’t adversely effect me here in my Chrome bubble, and bad because it seems to effect some of my readers. I installed Firefox 9 to debug the issue, and ended up with this policy:

[gist id=”1653770″]

The only problem with this is I had to whitelist all of github. This is a problem, because provided one could post script tags in comments on here, they could just link to a raw script in their repository and the policy is meaningless. Without path support in the standard grammar, I can’t properly integrate with github. I hope they add this support so I can do something like the following:

[gist id=”1653778″]

That would at least make it a little harder to do XSS. Of course, they offer subdomains, so this still doesn’t fix the problem. The only way to fix it is to whitelist explicit paths without wildcards. This is more verbose, but it would be better.

In closing, I like CSP, and I think it’s a good idea, but it’s still in early stages after a couple years, and needs a bit of work.

2 thoughts on “More Content Security Policy work

  1. d9ping

    I moved to using a policy file then i set the content security policy header with policy-uri. The advantage this is that the content security policy is then cache able. Because resending the compleet content security policy header on every request is not so good for speed if you set it up verbose and tight.
    Caching the CSP can also be slightly better against hacking. If the CSP file is not revalidated(expires, no ETag) a regular visitor, with cache, will be secured against a hacker modifying the CSP too.

  2. Erik Post author

    Thanks! I’ll probably switch to that. I’m not sure if they had the policy-uri option when I wrote the post – it was a long, long time ago. Cheers!

Comments are closed.