CSP violations triggered by scripts: no 'source-file' or 'script-sample'?

[ureesoriano]

Given a CSP violation report triggered during the execution of a script, I was [maybe naively] assuming that it would always have one of the two following fields:

• source-file: if a source file URL can be extracted (based on Based on the algorithm to create a violation, point 2).
• script-sample: if the report-sample keyword is present on the CSP and if the violation was caused by an inline script or an event handler (based on violation sample, note).

The problem is: This does not match how browsers seem to behave (Counterexample at the bottom).

• A) Did I misunderstand the docs? Maybe script-sample only gets populated when the script is the actual resource triggering the violation?
• B) Or, are browsers not honoring this bit of CSPv3?

---

Counterexample to reproduce this behavior:

Given a CSP with the following directives:

img-src 'self';
script-src 'self' 'unsafe-inline' 'report-sample';

And the following page:

<div id="42"></div>
<script>
    document.getElementById('42').style.backgroundImage= "url('data:image/png;base64,...')";
</script>

When a browser interprets the HTML of the page, it sends the following CSP report:

blocked-uri: "data"
violated-directive: "img-src"
source-file: (empty)
script-sample: (empty)

I was expecting a sample of the inline script in the 'script-sample' field.

[dveditz]

From https://w3c.github.io/webappsec-csp/#deprecated-serialize-violation step 3:

Assert: If object’s "blocked-url" property is not "inline", then its "sample" property is the empty string.

...or a note earlier saying sample is just for inline scripts and styles that were blocked for being inline, not for resource loading.

You're probably on stronger ground expecting source-file to be non-empty, but https://w3c.github.io/webappsec-csp/#create-violation-for-global notes a couple of issues trying to define this.

[ureesoriano]

From https://w3c.github.io/webappsec-csp/#deprecated-serialize-violation step 3:

Assert: If object’s "blocked-url" property is not "inline", then its "sample" property is the empty string.

...or a note earlier saying sample is just for inline scripts and styles that were blocked for being inline, not for resource loading.

That was very clarifying: I now understand why the script-sample field wasn't populated in the described scenario. Thanks!

You're probably on stronger ground expecting source-file to be non-empty, but https://w3c.github.io/webappsec-csp/#create-violation-for-global notes a couple of issues trying to define this.

Thanks for the pointer! Still, I went through that bit of the CSPv3 docs a few times. As much as the CSPv3 docs are being extremely useful, that particular section was not as specific as my brain probably needs.

Inverting the problem at hand, what I was trying to infer is:

Given:

• A site without inline scripts
• And a set of scripts fetched on the site, without any redirect involved
• A violation triggered during the execution of a script

If the source-file field in the CSP report is empty, can I then safely assume that the violation was NOT caused by any of the scripts?