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.