And JS can also indirectly initiate requests for resource or page fetches, e.g. by creating image tags or popup windows. It can't see the results directly, but it can make some inferences.

there are so, so, so many ways to read this data back it's not even fun.

There are ways, but they generally need a cooperation of both sides of the inter-domain boundary. What you generally can't do is make arbitrary reads from the context of other domain (e.g. call GET on their api and read a result) into your domain without them explicitly allowing it.

Right. What you can sometimes do is observe the effects of the content being loaded, e.g. see the dimensions of an image element change when its content is loaded.

Is there some document somewhere that lists all the potential ways of doing stuff like this?

Yeah, https://xsleaks.dev tracks most of the known ways to leak cross-origin data.

oh hell yes. And oh yes iframes and postmessages, of course people would setup them incorrectly and even if they do some (probably not that important but still) data will leak if you're creative enough. Thanks for the link!

you're right, you can initiate cross-site requests that _could be_ form submissions. It was even in the post but I thought I'd omit that bit for clarity. I should have decided otherwise.

Is that actually true? This SO seems to contradict that: https://stackoverflow.com/questions/44121593/sending-a-simpl...

I just want to fetch publicly available information from my client-side app, but CORS gets in the way and forces me to use a sketchy CORS proxy. Makes me really hate CORS

it is true. But again, writes are allowed, reads are not, you won't be able to see the reply. Which author of the question eventually realised https://stackoverflow.com/a/44122076/1685746

I agree with this, but in my past online discussions about fetching publicly available information, two main arguments often arise:

1. The resource owner doesn’t want you fetching their resource.

2. They don’t want to suddenly be flooded with requests.

Each of these points has counterarguments. For example, the Same Origin Policy (SOP) only restricts fetches from the client side, and nothing stops people from fetching via a backend.

The second argument makes sense, the resource owner doesn’t want their resource to be freely fetched and to suddenly receive thousands of requests that their server likely can’t handle. SOP helps prevent this, but if you’re fetching from the backend, you should implement caching to avoid repeatedly hitting the target resource.

I created a CORS proxy [0] to handle this scenario, including caching responses.

There are also several free CORS proxies [1] available, they might be considered sketchy, but they’re probably fine for testing.

[0] https://corsfix.com

[1] https://gist.github.com/reynaldichernando/eab9c4e31e30677f17...

To make things even more complicated, service workers can intercept requests and change the request mode.

oh god you're right https://stackoverflow.com/a/57206146/1685746 yeah sure what can go wrong, let's listen to fetch and modify requests in a service worker.

I actually use this to add authentication headers to images directly via src="". No blob management in javascript :)

Even more funny CORS allow * has very funky interactions as it simplified "doesn't allow the client to provide credentials" (e.g. Authorization header, cookies, etc.).

If you have public call-by-JS focused HTTP API which should be accessible from pretty much anywhere and therefore set it to * but also want an `Authorization` header you are in for bad luck.

Solution 1. use a custom header for your credentials like e.g. AWS does, works for JS focused APIs but cookies and as such e.g. cookie based XSS protection won't work.

Solution 2. dynamically return the callers domain as allowed origin. Works but requires dynamic responses to pre-flight requests and kinda undermines the whole CORS system.

honestly neither is really satisfying