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.

[jeffemandel]

I'm trying to deal with this to support the (IMHO) broken behavior of Firefox documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1459872. Note this is an open bug filed 7 years ago. I have several SVG animations that trigger this violation, and this overwhelms my CSP reports (because every animation frame generates the event multiple times). I can eliminate most of this by:

window.onsecuritypolicyviolation = (event) => {
  event.preventDefault();
  event.stopPropagation();
  console.warn(`Caught ${event.violatedDirective}`);
  while (testanimate.firstChild) {
    testanimate.removeChild(testanimate.lastChild);
  }
}

Where testanimate is an SVG element to which an animation is attached.
This reduces the number of reports to my cspreport endpoint to 1. I'd like it to be zero. Other than handling the cspreport myself in a global securitypolicyviolation handler, or patching my cspreport handler to not log this warning, is there a clean way to handle this? If not, could there be a way to tell CSP to suppress repeat warnings unless logging at debug level?

[jeffemandel]

This is a kludge, but may be a useful kludge. In the splash page, I have:

<svg viewbox="0 0 1 1">
    <rect id="testanimate" x="0" y="0" width="1" height="1" fill="DodgerBlue" >
        <animate attributeName="fill" values="PapayaWhip" keyTimes="0" dur="2s" /> 
    </rect>
</svg>

In my cspreport controller, I have:

String sample = myReport.getSample();
if (sample == null || !sample.equals("PapayaWhip")) {
    log.info("CSP blocked file {} at line {} for violating {}", myReport.getSourceFile(),
            myReport.getLineNumber(), myReport.getViolatedDirective());
}

In my CSP header:

style-src-attr 'none' 'report-sample';

Firefox reports the cause of (some) violated directives if they are annotated with 'report-sample'. This results in the fill color applied by the filter to show up in the 'script-sample' field of the CSP report. I'm willing to take a chance on some bad actor jacking my site and making it all PapayaWhip, so I suppress this.
Having figured this out, I think the thing to consider are decorations such as 'debug', 'info', 'warn', 'error'. When I'm developing, I may want to track down problematic style-src-attr violations, but suppress them in production.