Julia EvansFeb 4

something I don't think I've ever seen explained is whether there's any situation where it's safe to set "Access-Control-Allow-Origin: *" other than "if your site literally never serves any private data"

(I often hear "don't do it" which is fair I guess, but also like the Mastodon API intentionally sets Access-Control-Allow-Origin: * and that's extremely useful)

Show threadrobryk
@b0rk One situation when it's obviously safe is if any request made here could be made by the attacker directly: if there are no cookies that matter set on the domain, the server is on a publicly-available network, and nothing relies on discriminating by the client's IP, then the attacker doesn't gain anything by getting a victim to issue the request over doing that themselves.
Feb 4 at 9:06pmWeb
Show threadJulia EvansFeb 4
@robryk that makes sense, and I guess the Mastodon API is a good example of a server where that's true
Show threadrobrykFeb 4
@b0rk Yes. I think a vast majority of APIs are like that.

(It feels like CORS restrictions are sometimes used for a reason similar to the reason for protections against hotlinking: I know of public-data-returning APIs that don't allow cross-origin requests, so everyone who wants to build on top of them has to run a proxy of the API. Thus more people use the UI provided by the API provider, because there are fewer alternatives and they're harder to operate.)
Show threadJulia EvansFeb 4

@robryk interesting, I hadn't thought of it that way.

If that's true it does feel like it would contribute to a perception of same-origin restrictions as being "arbitrary"

Show threadrobrykFeb 4
@b0rk

Using these restrictions in a manner similar to hotlinking prevention is indistinguishable from a server on a private network using them to disallow other origins from accessing it via browsers of hapless users. I didn't think much about it, but I would assume that it wasn't possible to make one of these two possible without the other.

I think the anti-hotlinking-like usage contributes to a perception of CORS as being something that reinforces boundaries in the web, including ones whose existence is not in the interest of the user. I'm not sure whether this makes them feel more arbitrary to me: what does that a lot more strongly is existence of no-cors mode.

PS. Apologies: in my previous toots I implied that if you just set A-C-A-O then cross-origin requests will come with cookies. I just reread MDN article on CORS and it claims that unless you set more headers and the cross-origin requester explicitly asks for it, cross-origin requests will not include cookies. (And now here I feel like I'm seeing more arbitrariness.)
Show threadJulia EvansFeb 4

@robryk one aspect of "hotlinking prevention" that just occurred to me though is that some APIs are not really "appropriate" to use in a frontend context

like I don't think it would make sense to use the Twilio API in a frontend context, because of the way its auth works, you wouldn't want to expose your API key in your frontend in that way

so if I was the developer of that API I might not set A-C-A-O to discourage that kind of usage? Not sure.

Show threadrobrykFeb 4
@b0rk

It might be appropriate for prototypes or some weird setups where e.g. the user behind the browser is the one who provides the API keys. I agree that someone might want to cut down on inappropriate uses of that and consider these to be acceptable collateral damage.

That said, I suspect that the default (when no A-C-A-O is provided) being restrictive plays a large role here.