Hacker News Reader

Comment by nodesocket | Hacker News Reader

Can you specify domain wildcards in Content-Security-Policy script-src? For example:

    Content-Security-Policy: script-src 'self' *.somedomain.com

Also, while it looks great, usually its very difficult to integrate this header, without breaking existing JS functionality. For example, if you set this header, inline JavaScript will not be executed, this includes added event methods directly on DOM elements. Also eval() and writing setTimeout() and setInterval() like:

    window.setInterval("alert('hi')", 10);

Are forbidden from executing as well. Finally, using 3rd party libraries (Mixpanel, Google hosted libraries, Intercom.io) becomes nearly impossible without explicitly whitelisting domains in the header (a huge hassle to maintain).

View on HN

Can you specify domain wildcards in Content-Security-Policy script-src?

Yes. You may. http://www.w3.org/TR/CSP/#source-list See the host ABNF grammar.

while it looks great, usually its very difficult to integrate this header, without breaking existing JS functionalit

I haven't read much about 1.1 but as far as I know nounce and hash added to 1.1 is to deal with whitelisting inline scripts.

Please see http://w3c.github.io/webappsec/specs/content-security-policy...

Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=855326

https://bugs.webkit.org/show_bug.cgi?id=89577

http://lists.w3.org/Archives/Public/public-webappsec/2013Jun...

Also, if you are interested in client-side security, Mike West (from Google, one of the editors of CSP) has given a talk recently. http://www.parleys.com/play/529bee0be4b039ad2298ca0b

edit remember that the support of 1.1 is relatively low and incomplete as the webappsec group is voting on whether moving it to WD (working draft or not). So for cross-browser compatibility, you are still better off with 1.0 which is at this point very stable in major browsers.

Awesome. Thanks for the note about version 1.1 of the standard. Wasn't aware nonces and hashing were added.

The inline restriction burned us as well when we tried to implement this.

The solution is, of course, to do everything in separate script files, but it's not a trivial migration effort.

I definitely see it as being the biggest roadblock for most sites. The report-only mode is useful for getting a work list of what needs fixing.

Plus long term moving inline JS to separate files must improve maintainability, version control, and also means your caching might work more effectively. So there is a little gain for the pain (aside from just the content policy).

It looks like you can enable inline and eval stuff.

    Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'

But in that case you don't benefit much from it... (afaik)

"For example, if you set this header, inline JavaScript will not be executed, this includes added event methods directly on DOM elements. Also eval() and writing setTimeout() and setInterval() like: window.setInterval("alert('hi')", 10);"

Sounds like a feature, not a bug.

> Can you specify domain wildcards in Content-Security-Policy script-src?

Yes: http://www.html5rocks.com/en/tutorials/security/content-secu...

While it may be hard to migrate existing applications, since about 2 year I've started building all applications with externalized javascript.

So sticking to that rule for new stuff can greatly increase security.

it isn't that difficult to white list a few domains.. It's a grand total of 1-5 lines of code that contains a string you can change...

CSP is super valuable and it's worth the few extra lines

To answer your first question: yes[1]

[1] http://www.w3.org/TR/CSP/#matching

Reply on news.ycombinator.com