1572810 - Figure out if we want a more generic solution to avoid CORS if the transport doesn't support it.

Status: NEW

(Core :: DOM: Security, task, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

We have scheme checks for file:// in the fonts code, and bug 1499000 will add a similar thing for mask images and the "resource" scheme.

Do we want to add a more generic "do CORS checks if the transport supports it", and migrate these callers to that?

Comment 1

[Anne (:annevk)]

I'd like to understand the motivation for this better. From my perspective, either something is safe enough to always be considered same-origin or it requires CORS and then bypassing CORS would not be safe. We make exceptions for file and resource URLs for largely legacy reasons. If we did not have those constrains we would not allow loading them I think.

So other than clearly documenting that only for legacy reasons exceptions are permitted, I'm not sure there's much we should be doing here.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The file and resource exceptions are ad-hoc and scattered at the callsites, some of which except one, some the other, some both (?), and some neither. This is not a reasonable approach to security; revising that is what this bug is about.

For some things, like CSS masks, it's not clear that the CORS bits are there for any sort of safety, as opposed to a general "all new loads should be subject to CORS" approach. In particular, I have not seen any actual justification for CORS being required there. So pending that getting sorted out on the spec side (which might involve removing the CORS bits altogether), it might be a good idea to not enforce CORS in non-Web situations in general. This is also what this bug is about.

I should also note that for non-Web situations there are additional security checks that Firefox does in many cases that prevent origin A from doing a load from a different-scheme URL B at all. So in general the security model of non-Web protocols is quite different from the one of http/https that CORS was designed for, and the concept of "origin" in this space is a lot more complicated than "scheme + host + port", esp because there is no host or port involved....

Comment 3

[Anne (:annevk)]

To be clear, I'm much less experienced with the non-web scenarios so I'll totally defer to you all on that, though I'd be curious to read up on the security model if there's something documented.

I still have something to quibble though. At a high-level, I think documented exceptions at certain callsites is okay if the overall goal is to discourage a certain practice. If we're okay with add-ons/extensions taking a dependency on resource URLs that's a different matter of course.

As for mask URLs, without CORS it seems you could obtain information about the mask, violating the same-origin policy. That seems on par with the risk for other formats, such as fonts, so I think restricting there is the right thing to do for web content at least.