Currently the evaluator believes that a bypass via www.googletagmanager.com requires unsafe-eval.
However, this endpoint hosts AngularJS: https://www.googletagmanager.com/debug/badge
Also, this endpoint returns JSONP: https://www.googletagmanager.com/debug/api/vtinfo?gtm_auth=xFSd[...]&env_id=env-3&public_id=GTM-[GTMID_HERE]&templates=&callback=element.click
Therefore, actually unsafe-eval is not needed.
Since Google Tag Manager is a very popular tool, I think it would be better if this bypass was detected.

A new CSP keyword for speculation is being standardized, and has shipped in Chromium v110.

• Draft specification link
• Chromestatus feature page

The evaluator shouldn't error when encountering 'inline-speculation-rules' as an argument to script-src, script-src-elem, script-src-attr, or equivalent.

Directive "require-sri-for" is not a known CSP directive.

There are probably more directives not yet added to the known ones, but I haven't gone through all of them. Also, not sure what's the policy is, i.e. you wait for WD status or not.

There seems to be a problem with the new version of csp-evaluator, I keep getting this error now:

As described on MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors#sources), any wildcards used in a source for the frame-ancestors directive must be leading. However, CSP Evaluator does not flag when a non-leading wildcard is used, and instead says it is all good:

If a CSP has script-src: none or equivalent to forbid script loading, or if it has a sandbox directive to forbid script execution, the CSP evaluator shouldn't recommend requires-trusted-types-for: script because there is no script execution happening in the first place.

The endpoint referenced at

Maybe this should be removed or updated for new endpoints?

Intro

This might be controversial because RFC 2616 states "each separated by a comma":

It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.

but I figured that it would be good to create such issue anyway so that you are aware and can decide

Steps to reproduce

lets assume that https://example.com responds with this headers:

Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: object-src 'none'
Content-Security-Policy: script-src 'self' 'sha256-ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qctBD/YfIAFa0='

put https://example.com into textarea of https://csp-evaluator.withgoogle.com/

Actual result

in textarea of https://csp-evaluator.withgoogle.com/ they will be parsed as:

Content-Security-Policy: frame-ancestors 'none', object-src 'none', script-src 'self' 'sha256-ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qctBD/YfIAFa0='

(notice , instead of ;). Because of commas object-src + script-src will be marked as missing

Expected result

headers from steps to reproduce are parsed as

Content-Security-Policy: frame-ancestors 'none'; object-src 'none'; script-src 'self' 'sha256-ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qctBD/YfIAFa0='

Additional info

google chrome 87 interprets headers from Steps to reproduce in a way that object-src and script-src are respected

Proposed solution

Multi value headers should be joined by using ; instead of ,

Similar to issue #2, the disown-opener is a valid CSP-3 directive:

https://www.w3.org/TR/CSP3/#directive-disown-opener

Per w3c/webappsec-subresource-integrity#82.

https://www.w3.org/TR/CSP3/#unsafe-hashes-usage

Like stated in #54 and #56 there are some additions to CSP that the evaluator does not recognize, which makes it inaccurate in analyzing most up-to-date policies. The directives that aren't supported include but aren't limited to:

1. wasm-unsafe-eval #54, Mozilla
2. inline-speculation-rules #56
3. unsafe-hashesCSP.com, Mozilla
   Also, the evaluator gets the some keywords wrong , for example hashes, and autocompletes to sha-512- and sha-384- in stead of sha512- and sha384- which breaks the policy by prodiving inaccurate keywords.

Hello hello! Would it be possible to move the whitelists to external json files, instead of having them in the code? It would make it much easier for other projects that might use the data to consume. :)

Thanks so much!

The evaluator should note that the directive has been deprecated, see w3c/webappsec-csp#327.

"data" URL schemes can contain a ; when using the base64 extension.
When such scheme is used as a directive source, it seems that this ; trips the current CspParser, which wrongly splits the directive, as shown in the example below:

import { CspParser } from "csp_evaluator/dist/parser.js";

const example = "script-src 'nonce-xyz' data:image/png;base64,SGVsbG8sIFdvcmxkIQ== 'strict-dynamic'";
const { csp } = new CspParser(example);

console.log(csp)

Csp {
  directives: {
    'script-src': [ "'nonce-xyz'", 'data:image/png' ],
    'base64,sgvsbg8sifdvcmxkiq==': [ "'strict-dynamic'" ]
  }
}

I don't think I need HTTPS when requests will stay within my computer. w3c agrees, considering http://127.0.0.1 "potentially trustworthy", and therefore most modern browsers wouldn't warn of mixed content. Please could this tool be tweaked?

https://w3c.github.io/webappsec-trusted-types/dist/spec/ defines the CSP controls:

• trusted-types directive
• require-trusted-types-for directive
• 'trusted-script' keyword-source expression Removed in w3c/trusted-types@3b6d4fe

Hi, thanks for this website, it's very useful.

There are multiple directives that don't fallback to default-src.

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

Not setting them is the same as allowing anything for these directives.

Without some of these directive set, like form-action or base-url, it would be possible for a script to manipulate the DOM and allowing transmission of data to malicious websites.

Because of that, not setting these directives should be raised as a severity finding.

I would like to highlight the fact that the above policy is reported as safe. Is this intended? From what I understood 'unsafe-inline' could remove the defense. I would expect this reported as an High severity finding. Am I missing something? Thanks

default-src 'self';
script-src 'self' cdnjs.cloudflare.com www.google-analytics.com www.googletagmanager.com;
img-src 'self' www.google-analytics.com;
style-src 'self' 'unsafe-inline' fonts.googleapis.com cdnjs.cloudflare.com;
font-src 'self' fonts.gstatic.com cdnjs.cloudflare.com;
form-action 'self';
report-uri https://scotthelme.report-uri.com/r/default/csp/enforce

With this policy in place there is a warning for object-src [missing]. Is this desired functionality considering there is default-src directive?

Consider the input:

base-uri 'none';
default-src 'self';
object-src 'none';
style-src 'unsafe-inline';
script-src 'unsafe-inline' 'sha256-HEtTzbIgu0I33A3DZbJTheKFftQg+kS2n0OFuHExFuc='

That passes the evaluator just fine, with no warnings.

Now, consider this stronger combination of two policies:

base-uri 'none';
default-src 'self';
object-src 'none';
style-src 'unsafe-inline',
script-src 'unsafe-inline' 'sha256-HEtTzbIgu0I33A3DZbJTheKFftQg+kS2n0OFuHExFuc='

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 the script-src. It also complains about the style-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.

The csp-evaluator returns this message:
'wasm-unsafe-eval' seems to be an invalid CSP keyword.

However it seems to be implemented by most:
https://caniuse.com/?search=wasm-unsafe-eval
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_webassembly_execution

While not currently enabled on Chrome or Firefox, CSP3 does define the navigate-to directive:

https://www.w3.org/TR/CSP3/#directive-navigate-to

I think it just needs to be added to the Directive enum:

And maybe FETCH_DIRECTIVES, even though I don't think it's technically a fetch (returning for this document), it's still a serialized-source-list:

Hi there, just small feature request.

It would be nice to have a button in https://csp-evaluator.withgoogle.com/ that creates a text file (possibly in markdown format) with the CSP that was submitted for evaluation and the findings. Also possibly the date when the evaluation was done and the parameters used (e.g. CSP version).

The evaluator should note that the directive has been deprecated, see w3c/webappsec-referrer-policy#14.

The evaluator should note that the directive has been deprecated, see w3c/webappsec-csp@7268ca0 ("deferred to CSP3", which is unlikely to ever implement this).

https://www.w3.org/TR/CSP3/#directive-prefetch-src

Is this true? I'm pretty sure that I've seen a lot of sites with GA + CSP, but without eval(). I don't think that's the case for GTM, but I'm pretty sure it is for GA.

There's no contact information for https://csp.withgoogle.com/, do you know if it is maintained for new CSP directives etc? Also, the site is not mobile-friendly, and there's no github repo so I can't PR.

Trusted Types uses the keyword 'none' to show that no policies are allowed:

https://w3c.github.io/webappsec-trusted-types/dist/spec/#trusted-types-csp-directive

This is used to enforce Trusted Types restrictions (disabling unsafe APIs), without needing a policy to bypass these restrictions.

if (value === '\'allow-duplicates\'' || value === '\'none\'') {

I believe this would fix the issue where LightHouse shows the error message 'none' seems to be an invalid keyword.

Hi! I try to install the csp-evaluator .
I have java 11 and ubuntu18
When i try to build (./do.sh build) the project ,i have the error in photo. Any ideas?

Thank you very much

GoogleChrome/lighthouse#12804 (comment)

Hey folks, we had some useful feedback about the CSP XSS audit in Lighthouse. I think the changes needed to be made here are pretty simple:

• Only report a high severity finding on object-src if it is missing (i.e. object-src does not need to be 'none')
• Remove the report-uri requirement and rely on the docs to recommend configuring a reporting destination.

I'm happy to work on this in g3 if you are on board with the changes :)

The deployed CSP evaluator at https://csp-evaluator.withgoogle.com/ does not seem to recognize the 'wasm-unsafe-eval' CSP keyword.