[whatwg/webidl] Consider adding an `[InjectionMitigated]` extended attribute. (Issue #1440)

### What problem are you trying to solve?

It would be ideal to limit particularly interesting APIs to contexts in which the user agent can assume a hightened level of certainty that the code accessing the API is in fact the site's code, and not code that an attacker has cleverly found a way to inject into the page.

Over the last ~decade, we've landed on a combination of https://web.dev/articles/strict-csp and [Trusted Types](https://web.dev/articles/trusted-types) as sufficient mitigation. Perhaps we could choose to expose certain APIs only in contexts using those protections. This approach would be conceptually similar to the existing `[SecureContext]` and `[CrossOriginIsolated]` extended attributes.

### What solutions exist today?

Developers could choose to use Permission Policy to deny themselves access to certain capabilities if they're not sending appropriate injection-mitigation headers down to the client. This is a reasonable opt-out solution, but it's somehow unreasonable to expect every developer to make the effort/reward tradeoff.

### How would you solve it?

https://mikewest.github.io/injection-mitigated/ sketches the approach with a few monkey-patches to CSP, HTML, and WebIDL.

### Anything else?

https://github.com/WICG/digital-credentials/issues/133 is an example of the kind of API I'm thinking about. We also discussed this briefly in WebAppSec's meetings at TPAC last month: https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-09-23-TPAC-Minutes.md#injectionmitigated.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1440
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1440@github.com>