search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
207 stars 78 forks source link

CSP 4 Feature Request: add new 'default' keyword to compose default-src sources into other directives #321

Open Jach opened 6 years ago

Jach commented 6 years ago

The CSP 2 spec makes clear that when you specify some directive explicitly, e.g. img-src, there is no inheritance with the sources in default-src. What about allowing composition?

A new keyword-source in the grammar, for example 'default', could be used to have a CSP like: default-src 'self' example.com; img-src 'default' data: blob: This would result in an effective img-src of 'self' example.com data: blob:.

The use case is that some directives end up sharing many trusted domains (img-src, font-src, style-src, media-src...) but then need a few oddball sources tacked on at the end (e.g. data: for img-src, or 'unsafe-inline' for style-src, or just some video CDN for media-src) that prevent simple inheritance sharing via default-src and leaving the rest unspecified. Since HTTP headers are not compressed (unless using HTTP 2.0), having a sizable number of whitelisted sources repeated multiple times for each request can end up contributing a lot to bandwidth costs, especially if there are many violations when using the Content-Security-Policy-Report-Only header which get reported back to the server along with the original big CSP with report-uri.

In the event of conflict (e.g. default-src 'none') I think resolution should follow the existing multiple policies behavior in section 3.4.

Maybe instead of a new keyword like 'default', maximum composition flexibility is enabled where simply specifying the directive name in single quotation marks creates the reference? (Leading to the possibility of CSPs like default-src 'self'; font-src 'self' example.com; img-src 'default-src' 'font-src' blob:)

Apologies if this has been brought up before and the conclusion was "just put your CSP in a <meta> tag and report violations via the JS event hook if you're concerned about bandwidth". If so I'd appreciate a link to that discussion as I didn't find one.

chrisgraham commented 1 year ago

This is important. Some HTTP proxies define a maximum response header length to avoid exploit scenarios. It is easy for the CSP header to get very long. In Composr CMS with some official addons installed (Facebook integration etc), we are at 1278 bytes. Here's a proxy that defines a 2kb limit: https://docs.apigee.com/private-cloud/v4.18.05/setting-http-requestresponse-header-limits We are still within the realm of being able to optimize around this problem, but the biggest optimization would be to avoid the copy and pasted values between e.g. default-src and script-src.