Content Security Policy | Hacker News Reader

Content Security Policy

github.com

43 pointsxPaw12 comments

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:

  <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

> 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 "...";

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

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

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.)

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

"You must be the change you want to see in the world." - Gandhi

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/

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...

Hope it help someone.

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. :)

Here is an easy way to bypass it when you have a Chrome extension: https://www.planbox.com/blog/development/coding/bypassing-gi...

Reply on news.ycombinator.com