Open briansmith opened 5 years ago
Thank you for reporting Brian. We're aware of the issue (we actually do use and recommend double policies [1]), but we currently don't have the bandwidth to implement support for multiple policies in the CSP Evaluator. This would require intersecting findings across policies which would need a complex rule set for matching hosts/paths/wildcards/protocols/etc. E.g. Findings for entries like https://www.google.com/, *.google.com/, https://www.google.com/bar and https:// would need to be matched across policies and potentially across different directives (default-src/script-src) to determine, if the intersection would still allow a CSP bypass.
For simple cases like the one you posted above, you can evaluate policies individually and manually intersect results.
There are multiple aspects of this, some of which are easier to fix than others:
Consider the input:
That passes the evaluator just fine, with no warnings.
Now, consider this stronger combination of two policies:
The intent of this second input is to require that a script be loaded from
self
AND match the given hash, if the browser supports CSP hash, by asking for the intersection of two policies. This is a stronger policy than the original policy. However, the evaluator complains that "'self' can be problematic if you host JSONP, Angular or user uploaded files" because it doesn't notice thescript-src
. It also complains about thestyle-src
directive because it doesn't recognize the comma that separates the two policies.Ideally, the evaluator should be extended to understand multiple policies joined using
,
.This example uses CSP hash, which is rare. However, I believe several people have advocated for a similar technique of combining multiple policies that uses CSP nonce instead of CSP hash, so it would be good to support this pattern.