Per-type enforcement about trusted-types HOT 10 CLOSED

To update: we'll need per-type enforcement, given that the new types are likely to appear, and e.g. some authors may wish to control TrustedURLs via existing CSP mechanisms. See also mozilla/standards-positions#20.

from trusted-types.

Semantically, can't this be done via a default policy that has the identity function for conversions that the application wants to opt out of?

Is that not practical?

from trusted-types.

That would still break applications if new types are being added.

from trusted-types.

So the tradeoff then is CSP policy complexity vs flexibility in adding new types?

One way to avoid that tradeoff is with a catchall: createTrustedDefault.

from trusted-types.

So the tradeoff then is CSP policy complexity vs flexibility in adding new types?

Correct.

from trusted-types.

I'm against specifying more than the bare minimum in header content.

We ought prefer moving the complex portion of a policy in a general purpose programming language, not an ad-hoc language in a header. It seems that a catchall like policy.createTrustedDefault(x, type) would achieve that.

Lengthy policies should be shipped in cacheable body content, not header content. If most CSP policies are written in <meta> tags, then that's fine, but IIUC that's not the case.

As argued in #139 (comment) I think we should bias against adding new trusted types, but acknowledge that some will probably be necessary.

from trusted-types.

Ack, those are valid points, though I think we can generalize the issue at hand to declarative vs programmatic configuration. (e.g. the fact that the header is not cacheable is a separate issue we could fix by e.g. putting the configuration in an Origin Policy or a well-known file).

Parts of TT are already programmatic (e.g. createPolicy, default policy), with some declarative parts (the limit on policy names, the report-only-mode). I think we should have a balance here, and can't go fully programmatic. For example:

• we might end up needing inheritance rules for local schemes documents, like CSP to avoid bypasses, even accidental ones. It feels more natural for that to be controlled by a header, than by JS.
• for some deployments it's easy to control response headers in a deployment, but it's not easy to ship JS code (especially code that needs to run early and once only). For example, that can be provided trivially by a lot of middleware solutions, and makes Report-Only deployment at Google possible.

We can't go fully declarative either, as we'll quickly end up with a complex DSL - CSP demonstrates what happens then.

For now the line is drawn that only the allowed policy names, reporting URL and the enforce/report/ignore behavior are configured declaratively. I want to explore whether it makes sense to have per-type enforcement be declarative as well. This changes the syntax of the configuration a bit, but maybe not so much (especially with option 2). That's for practical reasons: I end up almost always writing a default policy that is an equivalent of no unsafe-inline for TrustedURLs. This feels redundant.

cc @mikewest @otherdaniel - is there a canonical bug for the 'csp as a compilation target' idea?

from trusted-types.

FWIW: I would very much like origin policy to be the solution here when it exists. I would love for us collectively to stop abusing response headers as policy configuration mechanisms.

is there a canonical bug for the 'csp as a compilation target' idea?

Just the only-kidding-but-no-really-we-should-do-this "spec" at https://mikewest.github.io/artur-yes/.

from trusted-types.

@mikewest, while I'm looking forward to the origin-policy existing, it will apply site-wide, so I only see it as being a baseline (or set of fallbacks) for the whole site.

Whereas individual response headers (for each page) can be customised to lock that page down as much as possible.

Or am I missing something?

In my case, most pages do not use any trusted types (so it can use null), but some pages use ~4 trusted types (one of my websites has 14, but not all are used on a single page).

So for my origin-policy, I'd have to include the full list of 14 trusted types for the baseline (not ideal if I can't lock it down any further); or, as per your current CSP experiments, I'd prefer to provide a fallback of null when an individual response header wasn't set for that page.

from trusted-types.

The current plan is to ship 4 types that focus on DOM XSS only (TrustedURL, TrustedScriptURL, TrustedScript and TrustedHTML). TrustedURLs will only be used for navigational sinks (iframe.src, window.open and such) and moslty because this is where javascript: URLs work. - I filed #192 to track this).

There are no custom (user-defined) types planned, authors might use an approach like https://gist.github.com/koto/1d044f6029ee337beffb4487b80f8b02 to add a support for them.

If additional types will surface (e.g. something for wasm), or we'd need another breaking (i.e the API introduces new enforcements) change in the future, we can introduce it via a new CSP directive keyword. But for now it seems like per-type enforcement is not needed - the types are "stable".

from trusted-types.