1944479 - Use source map's "source origin" as the "source file" in CSP violation reports

Status: NEW

(Core :: DOM: Security, enhancement)

Description

[Frédéric Wang (:fredw)]

This is the behavior expected by content-security-policy/securitypolicyviolation/source-file.html.

It's a bit unclear to me in which spec this behavior is defined, but here are some definitions:

• Source origin: https://tc39.es/ecma426/#linking-generated-code (source map spec)
• Source file: https://w3c.github.io/webappsec-csp/#violation-source-file (CSP spec)

Note that this test assumes Trusted Types support, which we are implementing in bug 1508286. However, I believe this was just one way to generate a CSP violation that was chosen for this test. My understanding is that any CSP violation report should use the source origin of the script it originates from. It would be good to add more WPT tests to make sure we cover the different CSP violations.

Comment 2

[Tom Schuster]

So the test expects the source map to influence the CSP's source file? That was not clear to me before and I am also not sure if the CSP specification actually says to do that. Unfortunately, the CSP specification text "extract a source file's URL" does not link to a definition.

Comment 3

[Frédéric Wang (:fredw)]

Right, as I said I was not able to figure out where this behavior is specified, but that's how I understand the test.

The test was originally added for Chromium here: https://chromium-review.googlesource.com/c/chromium/src/+/3263879

Comment 4

[Daniel Veditz [:dveditz]]

Can one of you file an issue against the w3c/webappsec-csp repo about this, and link to it here. We need to clarify the spec or remove the test if there's no textual backing for its assumption.

The test probably shouldn't have used TrustedTypes to trigger the error unless it was a trusted-types test (explicit in the test name or path) because TrustedTypes is currently a separate spec, but that's nitpicking. I'm sure other script errors would show the same behavior difference between Chrome and Firefox.

Comment 5

[Daniel Veditz [:dveditz]]

To be clear, this is a CSP spec problem because that's where the violation contents are under-specified.

Comment 6

[Frédéric Wang (:fredw)]

Can one of you file an issue against the w3c/webappsec-csp repo about this, and link to it here. We need to clarify the spec or remove the test if there's no textual backing for its assumption.

mmh, sorry I think I forgot about this. Not sure if Tom did it. adding needinfo flag to remember about it