

Content Security Policy - xPaw
https://github.com/blog/1477-content-security-policy

======
dmethvin
Its great to see a large site like GitHub start work on deploying CSP. I don't
know how many times I've had to argue with people about bad practices like
inline event handlers. With CSP there's a way for a site to prevent them from
being used.

------
pfraze
You can also specify a CSP using a document's meta tags:

    
    
      <meta http-equiv="Content-Security-Policy" content="default-src *; script-src https://assets.example.com; style-src https://assets.example.com"></meta>
    

I'm not sure if that introduces any additional attack vectors (other than
somebody modifying the document in an unencrypted connection) but it's useful
for when hosting statically.

EDIT: updated to mimic example in post

~~~
ushi
> it's useful for when hosting statically.

You can configure your webserver to add those headers, when hosting
statically. There is no need to include it in all your pages.

nginx: add_header Content-Security-Policy "...";

~~~
joshpeek
If your site is a simple static blog or whatever, there probably is no XSS
vector. So you probably don't need CSP.

------
mh-
This entire post is like a "why CSP is broken in the real world", yet they're
going ahead with deploying it?

~~~
abarth
Their feedback is very useful to us as we iterate on the specification and
implementation of CSP. (Disclosure: I'm an editor of the CSP specification.)

~~~
dmethvin
Thanks for your work! I'm a fan of CSP's goals.

------
rachelbythebay
CSP is great stuff. I'm using it to view RSS/Atom posts without having to go
through the usual hoop-jumping to sanitize content. Why sanitize content when
it's unable to do anything evil in the context of a page?

I would recommend using some kind of test in your scripting to see if it's
actually working. I purposely attempt to inject a <script> tag to fiddle with
a variable. If it works, I know CSP isn't functional in the browser and avoid
the dangerous stuff (rendering user-generated content). Otherwise, it's full
speed ahead, detailed here: <http://rachelbythebay.com/w/2011/10/31/csp/>

------
byroot
This change broke our chrome extension a few weeks ago. We were able to
workaround it using a trick inspired by this blog post:
[http://brianmayer.com/2012/12/defeating-chromes-content-
secu...](http://brianmayer.com/2012/12/defeating-chromes-content-security-
policy-header-via-a-chrome-extension/)

Hope it help someone.

~~~
mikewest
Does a page's CSP break your extension in Chrome Canary? We've done quite a
bit of work to allow extensions to transparently bypass a page's policy, and
I'd much prefer to fix the bugs in Chrome than for you to kill a page's policy
via the WebRequest API.

I'd very much appreciate it if you could point me at things that aren't
working in Canary. :)

------
lone-star
Here is an easy way to bypass it when you have a Chrome extension:
[https://www.planbox.com/blog/development/coding/bypassing-
gi...](https://www.planbox.com/blog/development/coding/bypassing-githubs-
content-security-policy-chrome-extension.html)

