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)
also is there any name for the attack(s) that setting "Access-Control-Allow-Origin: *" might expose you to? i feel like it's so much easier to talk about security stuff in terms of the specific threats we're trying to avoid, but I can't think of the name for it
(edit: I think it's CSRF)
@b0rk What that page misses is consideration of the question: is there any chance the content on my site could be used maliciously?
That is, if my site allows user-uploaded content, how sure am I that there's zero chance my site might end up hosting something malicious?
Which, of course, has nothing to do with credentials.
Or, I guess, put another way: yes, credential and identity exfiltration is one vulnerability addressed by CORS (and CSP), but it's not the only one.
One specific example here is a scenario where a site allows users to upload their own avatar image, say in PNG format. But instead of sending a PNG, the user uploads a JS file but sends its content-type: image/png. The site thinks "it's just an image" and doesn't bother to check that the content is actually valid.
If that site then has ACAO: *, it has just become a hosting service for malicious code.
Write-up for an SVG alternative to this attack: https://www.cloudflare.com/cloudforce-one/research/svgs-the-hackers-canvas/
@b0rk Which just gets us back to: it's not that * is bad, it's that it has inherent risks that you really have to think through, and thus shouldn't be offered as the default "just do this to fix it" solution.
This is one of the reasons the similar configs in CSP explicitly use the word unsafe when you're doing something unsafe. This is, IMO, significantly better DX, because the dev will hopefully be less likely to just copy and paste without understanding the risks.
It's unfortunate the Access-Control-Allow-* headers didn't use similarly evocative language.
@ricko thanks so much for that example! I would never have thought of that. i'm thinking about this * thing because (while I like to be as conservative as possible when setting permissions) I definitely had some wrong beliefs about why ACAO: * was bad and I like to know _why_ something is unsafe
I like the CSP naming and also with CSP it seems more obvious to me what the risks of allowing arbitrary code to run on my site are
I like to know why something is unsafe
Yeah, absolutely. I like the CSP stuff at https://content-security-policy.com/ because it includes lots of very practical guidance on when and when not to use each option. I think the CORS space could really use something similar, where it has very real-world scenarios.
"Do you want other sites to be able to use your images? Your JS?"
"Does your site offer embeddable content, such as via iframe?"
"Does your site allow users to upload content?"
"Is your site accessible via multiple domain names?"
etc, etc. It could then offer similar risk discussions and mitigation scenarios. "Always ensure images are actually images." "Never allow users to upload JS files." "Reject all SVG files with script tags."
Julia Evans
Rick Osborne