Hacker News Reader

> CORS only exists because XMLHTTPRequest broke the assumptions of web 1.0 servers. Suddenly any web browser loading any page anywhere could make a request to your server without the user's explicit permission

This had always been true; making cross-origin requests with e.g. <img> tags is still very much a thing.

This is why we can make GET and POST requests without an OPTIONS preflight...

Apparently, since developers should already have been protecting against cross-origin requests on GET and POST via other means (CSRF tokens), there was no need for the additional preflight protection.

They only added preflights to requests that browsers couldn't make previously.

Source: https://stackoverflow.com/a/39736697/114855

This is also the reason you can still POST text/plain to random TCP servers on the user's local network, without pre-flight check.

That’ll be gone soon: https://web.dev/cors-rfc1918-feedback/

I'd rather deal with stateless CORS than having to muck around with CSRF again, though.

True. CORS exists because the web browser would send the user's cookies (ie auth) for your site to you, when the user doesn't think they are on your site, but it's really malicious code from another site the user was visiting, acting as the user on your site without the user's knowledge.

Thats the threat model CORS is meant to address. Not just in general that a web host might not want a request from "anywhere" happening, but that site B might not want an authenticated request on behalf of User X to site B being made by code from site A.

That still doesn't distinguish the XmlHttpRequest from the <img> tag. They both send cookies.

You're right that sending cookies is the problem CORS addresses, but XmlHttpRequest didn't break any assumptions that were valid before.

It is much more difficult (perhaps impossible on a properly-implemented site?) to interact with a site on behalf of a user in harmful ways through an img tag -- Like, say, getting their checking account number, or transfering money from their checking account to yours, or resetting their password or email address. It's difficult/impossible to do that kind of attack only through an <img> tag, because Javascript can't see the body response of the URL in an <img> tag even if you point it at a non-image, and additionally an img tag can only be used for GET requests.

I didn't say that XmlHttpRequests "broke any assumptions that were valid before", I don't know exactly what that means.

If an XmlHttpRequest were allowed to do arbitrary cross-site requests, Javascrpt could use them do some of the kind of attacks mentioned above. Which is why XmlHttpRequests can't do cross-site requests. CORS exists to let XmlHttpRequests do cross-site requests only in an opt-in way, so a site can opt-in to it in ways that it knows/believes are secure from attacks like above.

I'm not saying the overall web security story is perfect (nobody would ever say that!), but that's where CORS comes from, and why it's different than img tag.

The common misconception is that CORS exists as some kind of general access control to your website. It only exists to keep the user of a well-behaved browser safe (in certain ways) from malicious Javascript on a site they are visiting. CORS has nothing at all to do with any scenarios involving malicious browsers, which are of course free to ignore CORS.

> (perhaps impossible on a properly-implemented site?)

Well, "proper implementation" would prevent a lot of attacks. But there's nothing stopping you, as a web server, from making state changes in response to GET requests, and it's far from unheard of.

I don't understand what you're trying to argue about.

The thing XHR added was:

1) POST.

2) Of arbitrary content.

3) With an arbitrary Content-Type header.

You don't get an OPTIONS for the sort of XHR request that you could do with an <img> tag (always GET). You don't get an OPTIONS for the sort of XHR request that you could do with a <form> tag (GET or POST). You only get OPTIONS if one of the following is true:

* Your request method is not GET/HEAD/POST

* You set a header value for a header other than Accept, Accept-Language, Content-Language, or Content-Type.

* You set Content-Type to a value other than "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain".

* You have upload listeners on the XHR upload.

* You use ReadableStream in the request.

True, though POST requests claiming to send form data are among the most threatening requests (and still would be if they weren't immune to CORS). It's a weird hole from a security perspective, though as you note it makes perfect sense from a historical-development perspective.

Also 4) ability to see the text results of your request.

No way for JS to do that with an IMG tag, I don't think.

If the XHR is same-origin then you control that text anyway, so know what it is (and there is no OPTIONS anything going on), and if it's cross-origin then the text results are not exposed by default (unless the server jumps through the other CORS hoops to expose them). The OPTIONS bits are not relevant to this part.

Instead of sending a request before every defined case in the CORS policy, it could be implemented requesting only one GET to a plain file (fully cacheable) with the domain policy definition.

Like robots.txt for the search engines.

This is how Macromedia Flash handled it a lifetime ago

Flash was 20 years ahead of its time (even though it already had its share of fame).

Apple killed it to pave way for the App Store. It was a shame because around that time Flash was at its peak of innovation, with stuff like Alchemy (whose modern day equivalent could be WebAssembly) and Flex (no-code thingy that was TRULY catching up, only 10 years ago). It was also starting to implement features like atomics, shared data buffers, app bundles, hardware-accelerated 3D, etc... They also went to great lenghts to open their VM, and the ecosystem that was being generated around that was awesome (anyone here used haXe back then?). It was also present on like 99% of devices already and it was the only thing at the time that truly felt like "write once, run anywhere" (HTML wasn't as feature-rich and still quite fragmented between browsers).

Flash was the single biggest threat to Apple's planned business model, and with it gone, Apple's road to becoming a trillion-dollar company has been a walk in the park.

Except CORS policies can be dynamic, depending on the request context.

It doesn't seem impossible that the static file could have an indicator for "send an OPTIONS in this case". 95% of CORS setups don't need to look at the request beyond the origin requesting it (and I'd wager that almost all CORS-enabled APIs just blindly allow everything).

Besides loading resources which was mentioned by sibling comment, some websites still rely on submiting forms cross origin, even with cookies! XMLHTTPRequest is not required. iframes exist, so the user doesn't even have to see their browser make those requests.

What is braid? I just get a blank page.

Try loading again, seems to be working now. Braid is an IETF draft proposal (and larger ecosystem) around bringing state synchronization to HTTP.

Cross-Origin Resource Sharing (CORS)

No, it's not ugly. It's necessary. And we don't need any additional tooling around it or yet another thing that "fixes" what doesn't need to be fixed.

If you control domain.com and api.domain.com, then you can create a proxy that glues the two to the same domain, getting rid of any CORS annoyances forever. And you use the tech that exists. The whole problem takes less than 1 minute to type, test, deploy and there's no need for yet another big thing invented to solve a small problem that occurs due to ignorance of self-proclaimed "developers".

I think it has some ugliness to it, but the idea behind it is necessary. The restrictions it places on front-end scripts are currently very challenging to work around, particularly if you're trying to implement a strict CORS policy on an existing website.

It's difficult enough to implement that it probably won't be implemented on the majority of the web - and maybe that's okay.

Yes it is ugly. How many learners have been stumpped by CORS errors over the years?

But it's also necessary.

> And we don't need any additional tooling around it or yet another thing that "fixes" what doesn't need to be fixed

This is what CORS is though.