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.
You can also specify a CSP using a document's meta tags:<p><pre><code> <meta http-equiv="Content-Security-Policy" content="default-src *; script-src https://assets.example.com; style-src https://assets.example.com"></meta>
</code></pre>
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.<p>EDIT: updated to mimic example in post
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?<p>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: <a href="http://rachelbythebay.com/w/2011/10/31/csp/" rel="nofollow">http://rachelbythebay.com/w/2011/10/31/csp/</a>
This change broke our chrome extension a few weeks ago.
We were able to workaround it using a trick inspired by this blog post: <a href="http://brianmayer.com/2012/12/defeating-chromes-content-security-policy-header-via-a-chrome-extension/" rel="nofollow">http://brianmayer.com/2012/12/defeating-chromes-content-secu...</a><p>Hope it help someone.
Here is an easy way to bypass it when you have a Chrome extension:
<a href="https://www.planbox.com/blog/development/coding/bypassing-githubs-content-security-policy-chrome-extension.html" rel="nofollow">https://www.planbox.com/blog/development/coding/bypassing-gi...</a>