Closed Bug 1192684 Opened 8 years ago Closed 11 months ago

Content Security Policy reports should include "effective-directive" and "status-code"


(Core :: DOM: Security, defect, P3)

39 Branch



108 Branch
Tracking Status
firefox108 --- fixed


(Reporter: tollmanz, Assigned: tschuster)


(Blocks 1 open bug)


(Keywords: dev-doc-needed, Whiteboard: [domsecurity-backlog1])


(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

1. Set a Content Security policy of `default; report-uri` for an HTML document.
2. Have the HTML document attempt to load an image with src of "".

Actual results:

A report is issued with a JSON payload that does not include the "effective-directive" and "status-code" properties.

Expected results:

A report should be issued with:

"effective-directive": "img-src",
"status-code": 200

From the CSP2 spec regarding "effective-directive":

"The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation (e.g. "script-src") even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive."

And "status-code":

"The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0."
Thanks tollmanz - moving to DOM::Security.
Component: Untriaged → DOM: Security
Product: Firefox → Core
I have confirmed this behaviour in 40.0.3 and the values are missing from the reports.

Appropriate parts of the spec:

Examples of a report from Chrome (Version 47.0.2508.0 dev-m 64-bit) and Firefox 40.0.3 attached.
Issue confirmed as still present in 43.0.1

This makes it incredibly difficult to normalise CSP reports on collection as there is no effective-directive value to categorise incoming reports.
Adding in my "+1" here since this definitely makes it hard to do any sensible aggregation of CSP reports. Right now, we choose to completely disregard any reports that don't include an `effective-directive` value, which means, we get nothing from Firefox at the moment.

But this is an acceptable tradeoff at the moment in my opinion, until Firefox is sending the expected data.
Ever confirmed: true
Blocks: CSP
I know we are not setting the 'effective-directive' and also don't report the status-code. So that needs to be fixed and incorporated in the JSON report, somewhere around here:
Whiteboard: [domsecurity-backlog]
Priority: -- → P2
Note that several CSP reporting tools (Sentry being one of them) are actively rejecting all Firefox CSP reports currently due to lack of these fields.
(In reply to Reed Loden [:reed] (use needinfo?) from comment #7)
> Note that several CSP reporting tools (Sentry being one of them) are
> actively rejecting all Firefox CSP reports currently due to lack of these
> fields.

This is something I considered for but in the end I decided to add specific handling for Firefox. I parse the effective-directive out of violated-directive but this does introduce additional problems. When the block was a fallback to default-src I end up with an effective-directive of default-src, which makes filtering in the GUI a pain. I could try and be smarter and detect the actual effective-directive, but decided how I currently do it is a good balance between dropping all Firefox reports and manually trying to identify the actual effective-directive.
Priority: P2 → P1
Priority: P1 → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog1]
I doubt bug 1363326 is a duplicate:

It seems CSP3 suggests different reporting for `report-to` and `report-uri`
Yeah, there's quite a shift in reporting for CSP3 but I think this bug is still relevant for the report payload.
This first patch makes CSP to report the effective directive, following what the spec says.
Assignee: nobody → amarchesini
Attachment #9004472 - Flags: review?(dveditz)
Probably this is not the right approach. We should implement the algorithms

but this is a big refactoring of the current CSP implementation.
Attachment #9004473 - Flags: review?(dveditz)
Comment on attachment 9004472 [details] [diff] [review]
part 1 - report correct directive name

I'm not happy about these 2 patches. removing the review flag.
Attachment #9004472 - Flags: review?(dveditz)
Attachment #9004473 - Flags: review?(dveditz)
See Also: → 948151
See Also: → 1779369
Severity: normal → S3
Assignee: amarchesini → tschuster

We have bug 1779369 for always using the correct effective directive as per CSP 3.

Attachment #9300756 - Attachment description: Bug 1192684 - Content Security Policy reports should include "effective-directive" and "status-code. r?freddyb → Bug 1192684 - Content Security Policy reports should include "effective-directive" and "status-code". r?freddyb
Pushed by
Content Security Policy reports should include "effective-directive" and "status-code". r=freddyb,webidl,smaug
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch
Keywords: dev-doc-needed

Documentation changes for this can be tracked in the following issue on GitHub ->

Relnote has been added in and the CSP page includes more info on the payload details:

Can I get confirmation on whether browser compat data updates are needed as it looks like the CSPViolationReportBody API is not supported:

You need to log in before you can comment on or make changes to this bug.