Closed mbrodesser-Igalia closed 4 months ago
The CSP spec itself doesn't always respect the report-sample
keyword, see https://github.com/w3c/webappsec-csp/issues/669.
That's a good point both trusted-types and require-trusted-types-for currently report a sample regardless of that header existing (at least in the spec).
See https://w3c.github.io/trusted-types/dist/spec/#should-block-sink-type-mismatch step 2.7 and https://w3c.github.io/trusted-types/dist/spec/#should-block-create-policy 2.10
I'm not sure if the implementations actually follows this. I believe there are WPTs that make use of sample so it's worth checking them.
A quick look at WebKit suggests it's only reported when that header exists. Wouldn't know where to check for Chromium. But I suggest we update the spec to match how others are working?
A quick look at WebKit suggests it's only reported when that header exists. Wouldn't know where to check for Chromium. But I suggest we update the spec to match how others are working?
To be precise, with "that header" the report-sample
keyword is meant?
Yeah sorry I meant report-sample keyword. WebKit also passes that test, despite it seemingly not including a report-sample keyword in the headers file. Definitely going to need to do some more digging on this one.
I guess if you're implementing see if you can require the header and still pass the test suite?
As discussed elsewhere, the sample-data contained in CSP violations of trusted types directives (https://github.com/w3c/trusted-types/issues/531#issuecomment-2191641883) is more limited than those of others CSP directives. I.e. it may contain policy names, sink-names and some trimmed source. Therefore it seems preferable to always report the sample for the trusted-types directives.
Closing this ticket given:
See https://w3c.github.io/webappsec-csp/#changes-from-level-2 point 11.
CC @koto, @lukewarlow