w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
399 stars 155 forks source link

Wildcards in Permissions Policy Origins #516

Closed arichiv closed 1 year ago

arichiv commented 1 year ago

This change harnesses Content Security Policy matching to allow wildcards in the origins of Permissions Policy allowlists. The goal of this is to provide greater granularity in permissions to better balance the ease and risk of a wildcard permission against what might otherwise be a long list of similar, yet distinct origins.

The only wildcard allowed before was *, which matched all origins.

Wildcards will now be supported for:

Feature: https://chromestatus.com/feature/5101218029895680

closes #479


Preview | Diff

clelland commented 1 year ago

Thanks -- I think this looks good -- can you file an issue on CSP to export the three terms that we use here? (That shouldn't block merging this, but it would be good cleanup for later)

The only thing that we might want to do to tighten it up a bit would be to give Allowlist two actual properties, so that we don't have to keep referring to "the origin representing self/src in allowlist", and could actually link to a definition there. That would probably require accounting for those properties to possibly be null. We'd be able to assume at that point that the "list" part of the allowlist is just patterns, as well.

(Not necessary right now; this is functionally equivalent, but if you wanted to do that before merging, let me know and I'll hold off)

arichiv commented 1 year ago

Filed https://github.com/w3c/webappsec-csp/issues/604

I think this can merge as is, I can circle back on that cleanup when the DFNs are exported by CSP.