Prevent CSP reports being sent if I handle the SecurityPolicyViolation event.

[ScottHelme]

I'd like to be able to intercept CSP reports and process/handle them on the client side prior to sending.

CSP reporting is very noisy and right now looking at real numbers from https://report-uri.io a significant quantity of reports are discarded by filters at our edge. Depending on the exact filters configured by the user it can quite reasonably be 40%-80% of reports discarded.

The ability to handle these client side by applying filtering to prevent them being sent would be a significant advantage. Reducing noise improves the usefulness of CSP reports and not sending them saves network activity on the client. This would make it easier for hosts to deploy reporting.

[mikewest]

@andypaicu, I am sure, will be thrilled beyond words to look into what we'd have to do to make this work. I suspect it shouldn't be terribly difficult?

[mikewest]

/cc @ckerschb, who's poking at this in Firefox.

[SkateScout]

Even if you can not block it, it would be really great if you can inform the client that there was something blocked. There should be an event called "securitypolicyviolation" but i did not get this to work with thunderbird nigthly.

[ckerschb]

That sounds reasonable to me. It shouldn't be hard to put something in place to block the report before going out if the event is handled in the browser. Let us first get SecurityPolicyViolation events into Firefox :-)

FWIW, SecurityPolicyViolation Events should be available for FF59, see https://bugzilla.mozilla.org/show_bug.cgi?id=1037335

[Zirro]

With SecurityPolicyViolation events in place, the preventDefault()-method might be the most natural way to expose this.

[dveditz]

Or instead don't use CSP's built-in reporting, and then use the violation events to send your own filtered reports.

[ScottHelme]

I'd prefer the preventDefault() route otherwise the host is going to have to do UA sniffing to determine whether or not the client implements the interface and thus whether or not to inject the report-uri directive into the policy.

[mikewest]

Making the SecurityPolicyViolation event cancellable and relying on preventDefault() sounds fine to me, and is consistent with developer understanding of other events. We'll need to restructure the way we send reports to wait for the developer decision about how to handle it, but that doesn't look terribly complicated.

@andypaicu, you up for doing that work?

[koto]

Having a cancellable SecurityPolicyViolation event could also help in implementing a fallback mechanism for Trusted Types. Is there something blocking the change?

[andypaicu]

@koto Nothing in particular, just lack of bandwith.

[Elisheva-Jacobson]

To prevent the security reports from being sent, you can leave out the report-uri and report-to directives. The securitypolicyviolation event will still fire, even if it's a report-only policy. Then you can listen to securitypolicyviolation events on the client side and post your own reports conditionally with the information from the securitypolicyviolation event.

[michaelficarra]

@Elisheva-Jacobson True, though that script would be subject to the CSP restrictions, right? So it may not be able to communicate with the reporting service.

[Elisheva-Jacobson]

That script would still be subject to the csp restrictions, but there's no reason that it should not be able to communicate with the reporting service, unless you make it inline or load it from a third-party domain.