A Content-Security-Policy violation report gives blocked-uri as inline with an empty script-sample, so what does it tell you?

## blocked-uri does not always hold a URI The field name invites the assumption that a violation record always names a location, and it does not. A policy governs two different kinds of thing: resources the document fetches, and code or style the document carries inline. When the refused thing was a fetch, `blocked-uri` holds the URL. When it was inline, there is no URL to hold, so the specification puts a **literal marker** there instead. | `blocked-uri` value | What was refused | |---|---| | an absolute URL | a fetch of that resource | | the literal string `inline` | inline content in the document itself | | the literal string `eval` | a string being evaluated as code | The `inline` marker covers several distinct things: an inline script element's text, an inline event-handler content attribute, and an inline style. All of them report the same literal, which is why the marker alone never tells you *which* inline construct fired. ## Why the sample is empty by default The field that would tell you which construct fired is `script-sample` in the legacy `csp-report` body, spelled `sample` in the `CSPViolationReportBody` the Reporting API delivers. It is empty unless **both** of the following hold: 1. The directive that was violated carries the `'report-sample'` keyword-source in its source list. The sample is opt-in per directive, not a global setting. 2. The violation was an inline one. There is no sample to take from an external resource that was never executed. Even then, the value is a short truncated prefix of the offending content, not the whole thing. The default is not an oversight. Inline content in a page is page content: on a prescription-status lookup it can easily include a patient reference, a dispensing note or a session identifier interpolated into a script. A report is a request leaving the browser to a collector, so anything the specification puts in the body is something it has decided may cross that boundary. Making the sample opt-in, inline-only and truncated is the compromise between debuggability and not making the collector a second copy of the page's data. ## What the record still tells you An empty sample is not an empty record. Without it you still have: - **`effective-directive`**: the directive the browser actually checked against, which is what tells you whether this was a script, a style or something else. `violated-directive` carries the same value and is a documented historical alias, not a second piece of information. - **`source-file`, `line-number` and `column-number`**: where in the document the refused construct sits, which is frequently enough to identify it directly. - **`document-uri`**, so you know which page produced it. - **`disposition`**, so you know whether this was refused for real or merely recorded. - **`original-policy`**, the exact policy text that produced the record, which matters when more than one policy text is in circulation across a rollout. ## Turning the sample on, deliberately Adding `'report-sample'` to a directive is a considered change, not a default: - Add it to the specific directive whose violations you cannot identify, not to every directive in the policy. - Expect it only on inline violations; a refused external fetch will still report an empty sample with the keyword present. - Treat the resulting samples as page content in your collector's retention policy, because that is what they are. ## The reading that gets it wrong The common failure is to read an empty sample as evidence of a boring violation, and a `blocked-uri` of `inline` as a resource fetched from some odd scheme. Both misreadings send people looking for a network request that never happened. The correct reading of `blocked-uri: inline` with an empty sample is precise and useful in one sentence: *something written into this document, rather than fetched by it, matched no source expression in the directive named by `effective-directive`, at the position given by `source-file` and `line-number`, and this policy did not ask for a sample of it.*