Protocol source matches for CSP in extensions not supported

Question

Created Dec ’20

Replies 5

Boosts 2

Views 1.6k

Participants 3

When including something like http: or https: in the connect-src and img-src directives of the contentsecuritypolicy of webextensions, they are simply ignored.

Other matches like https://*.example.com/ work as expected.

Answered by Engineer in 656349022

This is expected behavior. Safari doesn't allow a full wildcard in the content security policy string.

If this is breaking your extension, could you please file feedback on https://feedbackassistant.apple.com explaining what your extension is trying to do and why you need these full wildcards?

Boost

Answer 1

Engineer OP

Apple

Jan ’21

Accepted Answer

This is expected behavior. Safari doesn't allow a full wildcard in the content security policy string.

If this is breaking your extension, could you please file feedback on https://feedbackassistant.apple.com explaining what your extension is trying to do and why you need these full wildcards?

0

Answer 2

carlosj OP

Jan ’21

To allow developers to enforce a more strict CSP. Basically without wildmark matches I have to leave out the directive completely.

For example, one use case is limiting the set of images an extension is able to load in their own context.

Normally, any image can be loaded within the extension, yet when you set this as CSP:
default-src: none; img-src: https:;

Only images from https can be loaded.

Feedback has been filed, #8968973

0

Answer 3

carlosj OP

Sep ’21

See feedback assistant ticket: https://feedbackassistant.apple.com/feedback/8968973

0

Answer 4

carlosj OP

Sep ’21

Can this post be marked as "not solved". As the issue isn't solved yet.

1

Answer 5

iamtheo OP

Jul ’24

I've also encountered this same issue, and have filed a ticket in the feedback assistant as well.

My extension (a devtool, see https://github.com/tbrockman/browser-extension-for-opentelemetry) allows users to specify arbitrary backend URLs for the extension to connect and send data to. While they could likely setup port-forwarding from http://localhost:* to their desired destination, it would be unexpected and cause unnecessary friction when every other browser allows the behavior.

For example, when connected to my VPN, I can send data to http://otel-collector:4318/v1/traces without having to worry about provisioning any certificates to use TLS (even though it would be safer to use https://, it's convenient for prototyping/PoC's to be able to skip doing so if the risks are understood).

If I have to make an explicit exception for how my extension works in Safari, it would be nice to have a link to some specific documentation outlining this deviation from expected browser behavior/incompatibility (as I wasn't able to find any reference on MDN or similar websites) so that users are able to understand why the extension is less functional/intuitive in Safari.

0