1376953 - Provide a way to limit CSP error spam in the developer console

Status: NEW

(DevTools :: Console, enhancement, P3)

Description

[April King [:April]]

I have a webextension that injects the following CSP header into webRequest.onHeadersReceived:

> request.responseHeaders.push({
>   name: 'Content-Security-Policy',
>   value: `object-src 'none'; script-src 'none'`,
> });

For a complex site, this can generate hundreds of console log errors. While most users will never notice this, developers who use tools like Laboratory or NoScript (set to block via CSP) will have tons console log spam that can be very irritating. You can disable the entire Security tab, but then you miss other Security errors unrelated to CSP.

It would be great if we could do one or both of:

a) have a dev tools preference to disable/enable CSP logging, or
b) have a CSP directive (such as `ff-no-console-log`) that can be set in a CSP header that will disable the logging of CSP errors to the console log (but not to reporting endpoints)

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

(In reply to April King [:April] from comment #0)
> a) have a dev tools preference to disable/enable CSP logging, or

Brian, is it feasible to add a devtools pref to disable CSP logging and expose that to webextensions, or would that have to be a pref in CSP?

Comment 2

[Brian Grinstead [:bgrins]]

The error has a 'category' property that's set to CSP so from the frontend we can do custom filtering. But tricky part would be how to surface this to the UI/addon. Some options:

1) Add a button in the UI to hide CSP messages - I don't think there's room in the current filter bar to add a button for each error category though and we've been trying to avoid reintroducing the nested popups on filter buttons
2) Introduce some kind of search syntax in the filter box to remove certain types of messages, such as `-category:csp`. Or `-text:NoScript` if we included the extension that caused the error in the message text - see (4) below.
3) Somehow let a web extension set a pref to hide them - although I'm not sure if webextensions can set arbitrary prefs. And also I think we'd want to make sure it didn't hide CSP errors that didn't originate from the extension - see (4) below.
4) Is there a way to detect that the header came from a web extension?  If so maybe we could hide CSP errors from web extensions by default (assuming you could still debug the requests in the netmonitor).

I'd generally lean towards 4 or 2 depending on what's possible from the platform end

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Looks like Bug 1525624 might help.