5 ms·

Can you specify domain wildcards in Content-Security-Policy script-src? For example: Content-Security-Policy: script-src 'self' *.somedomain.com Also, whi

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

falcolas 13y ago
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.
- UnoriginalGuy 13y ago
  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).
eCa 13y ago
> Can you specify domain wildcards in Content-Security-Policy script-src? Yes: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#implementation-details http://www.html5rocks.com/en/tutorials/security/content-secu...
darrhiggs 13y ago
To answer your first question: yes[1] [1] http://www.w3.org/TR/CSP/#matching http://www.w3.org/TR/CSP/#matching
yeukhon 13y ago
Can you specify domain wildcards in Content-Security-Policy script-src? Yes. You may. http://www.w3.org/TR/CSP/#source-list 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/csp-specification.dev.html#nonce-usage-for-script-elements http://w3c.github.io/webappsec/specs/content-security-policy... Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=855326 https://bugzilla.mozilla.org/show_bug.cgi?id=855326 https://bugs.webkit.org/show_bug.cgi?id=89577 https://bugs.webkit.org/show_bug.cgi?id=89577 http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0059.html 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 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.
- michaelmior 13y ago
  Awesome. Thanks for the note about version 1.1 of the standard. Wasn't aware nonces and hashing were added.
kyrra 13y ago
It looks like you can enable inline and eval stuff. Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'
- amenod 13y ago
  But in that case you don't benefit much from it... (afaik)
treve 13y ago
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.
al2o3cr 13y ago
"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.
theboss 13y ago
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

falcolas 13y ago

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.

UnoriginalGuy 13y ago
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).

eCa 13y ago

> Can you specify domain wildcards in Content-Security-Policy script-src? Yes: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#implementation-details http://www.html5rocks.com/en/tutorials/security/content-secu...

darrhiggs 13y ago

To answer your first question: yes[1] [1] http://www.w3.org/TR/CSP/#matching http://www.w3.org/TR/CSP/#matching

yeukhon 13y ago

Can you specify domain wildcards in Content-Security-Policy script-src? Yes. You may. http://www.w3.org/TR/CSP/#source-list 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/csp-specification.dev.html#nonce-usage-for-script-elements http://w3c.github.io/webappsec/specs/content-security-policy... Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=855326 https://bugzilla.mozilla.org/show_bug.cgi?id=855326 https://bugs.webkit.org/show_bug.cgi?id=89577 https://bugs.webkit.org/show_bug.cgi?id=89577 http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0059.html 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 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.

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

kyrra 13y ago

It looks like you can enable inline and eval stuff. Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'

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

treve 13y ago

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.

al2o3cr 13y ago

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

theboss 13y ago

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