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

Assigned to



4 years ago
28 days ago


(Reporter: tollmanz, Assigned: baku)


(Blocks: 1 bug)

39 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [domsecurity-backlog1])


(3 attachments)



4 years ago
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

Comment 2

4 years ago
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.

Comment 4

3 years ago
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.

Comment 5

3 years ago
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
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.

Comment 8

3 years ago
(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]
Duplicate of this bug: 1345101
Duplicate of this bug: 1363326

Comment 11

2 years ago
I doubt bug 1363326 is a duplicate:

It seems CSP3 suggests different reporting for `report-to` and `report-uri`

Comment 12

2 years ago
Yeah, there's quite a shift in reporting for CSP3 but I think this bug is still relevant for the report payload.

Comment 13

7 months ago
This first patch makes CSP to report the effective directive, following what the spec says.
Assignee: nobody → amarchesini
Attachment #9004472 - Flags: review?(dveditz)

Comment 14

7 months ago
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 15

7 months ago
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)


7 months ago
Attachment #9004473 - Flags: review?(dveditz)
See Also: → bug 948151
You need to log in before you can comment on or make changes to this bug.