Blocking webRequest usecase - add, modify and remove CSP directives

[carlosjeurissen]

With the blocking webRequest API, it is possible to actively read and change the CSP directive.

However, with DNR, you can only set a complete header without knowing what the original value was. This leads to situations in which in a DNR environment, the complete CSP has to be removed as it can't be predirected what the CSP could be.

An example is a CSP which contains a nonce. Say the extension tries to modify the frame-ancestors directive. It would have to know the nonce value of the request. Without knowing it, the CSP has to be too unsafe to be acceptable under the DNR situationl.

[tophf]

Someone should probably make a meta issue that lists evidence that currently MV3 extensions actually reduce safety of the users or web sites because there's no other way to implement features. Another such case where total removing of the site's CSP would be required is to implement GM_addElement functionality for Tampermonkey/Violentmonkey.

[xeenon]

Would regexSubstitution for modifyHeaders be an option to address this? Similar to the redirect action that supports regexSubstitution.

[tophf]

Since RE2 syntax for regex doesn't support lookahead and complex matching, regexSubstitution would work only for the cases that are relatively simple like the one reported in https://crbug.com/1254637.

[rdworth]

One use case we have had to modify CSPs using blocking web requests is to allow styles/stylesheets that support extension UI being added to the page

[nir-walkme]

Following the last meeting of the WECG, I am adding our use case to support this request.

We are a large SaaS company with a product that is implemented using a browser extension that adds functionality on top of existing web applications.
As we have very large customers, they usually require customization of the look and feel and behavior of our software. This customization can be blocked by CSP while our customers usually don't have direct control on the CSP of the web application as some are third-party apps.

Examples for types of customizations that can be blocked by CSP:

• Adding images (can be blocked by img-src CSP)
• Adding stylesheets (can be blocked by style-src CSP)
• Sending analytics to a third-party server (can be blocked by connect-src CSP)
• Adding small javascript snippets (can be blocked by script-src CSP)

When faced with a CSP restriction we have the following alternative solutions:

• In Manifest V2, the CSP can be modified easily using blocking webRequest.
• In Manifest V3, blocking webRequest works only in force-installed extensions, which some of our customers do use, but a portion of our customers install the extension manually.
• Using DNR allows removing the CSP header completely but that would weaken the overall security. It is not possible to modify the CSP header by reading the existing text and changing it.
• User Script API - This requires adding an additional permission which is not an option for us since it would disable the extension to our users until they approve it. In addition, we don't want to have the "optics" of being a "user script extension" which we are not.
• When CSP is implemented as a meta tag CSP (in the HTML and not in the header), there is no way to override it.

We believe the best solution is to have a dedicated CSP API for web extensions. This API should overcome CSP headers and CSP meta tags.
Another alternative would be to enhance the DNR to allow editing the CSP headers. This would not solve the CSP meta tag issue but still could solve many of the cases.

Not having a solution to this problem might push some extension authors to remove the CSP headers completely using DNR (we will not do it, of course). So at the end of the day we believe that a solution to this problem would increase the overall security posture of the web extensions ecosystem.

[Rob--W]

One use case we have had to modify CSPs using blocking web requests is to allow styles/stylesheets that support extension UI being added to the page

Could you be a bit more specific? Web-accessible extension URLs are supposedly exempt from the CSP restrictions. This is even one of the rare cases where a specification mentions extension interaction explicitly, at https://www.w3.org/TR/CSP3/#extensions:

Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.

The request here was originally about replacements for webRequest + CSP. Even if DNR were to get the capability to manipulate CSP, it wouldn't address the <meta> way of restricting CSP. Therefore I am interested in use cases to see whether extensions would really need a big hammer (i.e. CSP modifications in DNR) or whether there are better fitting specialized extension APIs.

Note: webRequest+CSP modification is and has always been a big hack; One of the unresolved open issues is that extensions cannot cooperate with each other to define the desired behavior.

Following the last meeting of the WECG, I am adding our use case to support this request.

Thanks!

When faced with a CSP restriction we have the following alternative solutions:

• User Script API - This requires adding an additional permission which is not an option for us since it would disable the extension to our users until they approve it. In addition, we don't want to have the "optics" of being a "user script extension" which we are not.

"Adding small javascript snippets" fits the description of a user script manager. Since the feature is optional, would an optional permission work? Alternatively, if the snippets are static, they can be embedded in the extension and be inserted with the regular scripting API.

[tophf]

would an optional permission work?

Probably not, because Chrome web store policies aggressively insist that an extension must have a single purpose, and being a userscript manager is not just an optional permission that any extension can use but a separate purpose in itself.

[nir-walkme]

"Adding small javascript snippets" fits the description of a user script manager.

Technically you are correct. But this is not the primary purpose of our extension so we would be reluctant to represent ourselves as such.

Since the feature is optional, would an optional permission work?

No. Optional permissions in general do not work well for us because of the way our product is being used. Our product integrates with the end user's flow of work, and usually they are not aware that a browser extension is involved. Therefore we cannot show a permission request popup.
Also @tophf's previous comment on that makes sense.

Alternatively, if the snippets are static, they can be embedded in the extension and be inserted with the regular scripting API.

I'm afraid that it is not static.

Thanks for following up on this, @Rob--W. While "User Script API" may solve the script-src CSP problem for some extensions (not for us), as I mentioned in my previous comment, the problem is more broad (images, stylesheets, etc...) and requires a general CSP solution (either deidcated CSP API or using DNR)

[rdworth]

One use case we have had to modify CSPs using blocking web requests is to allow styles/stylesheets that support extension UI being added to the page

Could you be a bit more specific? Web-accessible extension URLs are supposedly exempt from the CSP restrictions.

I went back and looked and we were whitelisting our own domain name where we had a stylesheet or a font file