Can data: URLs be part of a secure context?

[annevk]

I think the resolution of #26 is no, but this resolution creates a vary weird state. In effect, we're back to mixed content that isn't blocked.

If data: URLs would simply network error it'd be fine, but now they can get all the capabilities they want if they have the cooperation of the embedder.

This in turn makes other stateful features such as COOP and COEP hard to define.

cc @bzbarsky @mikewest

[annevk]

See https://github.com/whatwg/html/issues/5198 and https://github.com/whatwg/html/issues/4916 for additional context (and links to various tests).

[annevk]

The risks here are that the data: URL is something that is injected and navigated to (which is not possible with srcdoc) or the result of an "open redirector" with a similar injection hole.

From those perspectives it makes sense to me to treat them as insecure contexts, but I'm not sure what this means for COEP.

Is this the one case where your document has COOP and COEP but it does not have cross-origin isolation? Or are data: URLs disallowed in this new world?

(I think by-and-large this issue is now about how data: URLs create a weird mixed-content-like state and the specification should call that out and ideally offer advice for how to deal with that.)

[bzbarsky]

or the result of an "open redirector" with a similar injection hole.

This is the "HTTP 3xx to data:" case? That case should not inherit secure context state, just like it didn't use to inherit origin in Gecko when data: in general inherited origins.

As far as injection and navigation, how is that different in practice from someone injecting a navigation to an https:// URL they control, which would also be secure context?

[annevk]

It's not. I think it's only different in that someone might imbue their own data: URL with privileges and does not consider that an attacker might be able to get it replaced through XSS. I'm not sure that's a strong enough reason and I would kinda prefer either forbidding data: URLs entirely or making them always inherit state (other than origin) as the current state of affairs is really special and will require lots of thinking each time we add a new policy.

(And yeah, HTTPS redirect to a data: URL. I did not test what implementations do today.)

[annevk]

To state it somewhat more strongly, I now think we should change the specification so that data: URLs creating documents or workers can no longer create this unique problem and instead inherit this state as they do for other state.

[annevk]

https://github.com/web-platform-tests/wpt/pull/21146 has a test for this (workers only atm).

[annevk]

More tests: https://github.com/web-platform-tests/wpt/pull/21781. I couldn't find any existing data: URL tests for secure contexts.

[mikewest]

I talked with @camillelamy about this earlier today, and I can get behind the notion of inheriting transport secureness from a parent context. I'm a little reluctant to give data: more capability, but I agree that it' a strange state of affairs for a document to be able to delegate capability to a data: frame via postMessage(), but not grant it directly. I also accept that it simplifies the model by removing some edge cases (we push CSP down to the data: URL, we should probably push everything that would eventually end up in the "policy container" we'll eventually define in https://github.com/whatwg/html/issues/4926).

How would this affect top-level data: documents? Presumably we've made those hard enough to get to that it would be reasonable to continue denying them capability?

[mikewest]

(Would you be willing to send a spec PR?)

[annevk]

A top-level data: URL can only come from a user-initiated navigation (well, that's the plan for standards and implemented in at least Chrome and Firefox, see https://github.com/whatwg/html/pull/5279) and I agree that those should not create a secure context.

I can see about writing a PR.