[Lerc]

I don't think you can even say CORS does that.

The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party,

If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the other will. If people adapt their code until it works with another implementation, were they mistaken, or the other end?

[xg15]

I think it still works, because the number of "client implementations" of CORS is very limited (*) - only the browsers have to implement that, and the browser devs seem to understand it well enough.

So there is only one end of the system that is confused - the servers - but at least the other end - the browsers - can mostly be trusted to implement it correctly.

(*) unless you're implementing an open proxy, but then you have bigger problems.

[everforward]

There’s few implementations of the engine, but many implementations of rules for that engine.

I think OPs point is that many of those rule sets probably don’t do what the author intended.

I would second that, because CORS questions are common and “turn on the allow all pattern” is almost always in the top 3 suggestions.

Semi-related tangent, it annoys the hell out of me that create-react-app (and the newer incarnation) don’t come with an “allow all” CORS rule. Don’t force me to figure out which arcane setting configures CORS headers, I’m the one writing the code, I’m okay with wherever the HTTP requests are going, I’ll set up real CORS headers on nginx for prod.

[RobotToaster]

It seems like nobody understands CORS.

Including me TBH.

[Beltiras]

I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.

[embedding-shape]

Back in the day when I started web development, websites making their own requests after they loaded wasn't a thing. Eventually, XMLHttpRequest appeared, which let JS do HTTP requests at (page) runtime, and the whole "AJAX movement" kicked off.

Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. But sometimes we want to be able to make requests from pages to other Origins, so CORS (Cross-Origin Resource Sharing) lets you configure your server to tell browsers that "You're allowed to make requests to me, even if you're on a different origin".

This is basically the simplified version of the why and how behind CORS.

[JimDabell]

> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin.

I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty much straight away – Netscape 2.0.2 I believe. Almost 20 years passed and then CORS was created. So while it’s technically true, the timeframe in which JavaScript could make any cross-origin requests was basically the blink of an eye, and for all intents and purposes, the SOP has been around since the beginning and definitely many, many years before Ajax came around.

[embedding-shape]

Yeah, definitely I was simplifying a lot, borderline misleading perhaps even.

Before XMLHTTPRequest there was also a time we were doing requests via ActiveX as well, but I did it so briefly I barely remember how it worked by now, and I'm 99% sure this was exclusively in IE as well, maybe IE4 or IE5. I'm not sure if the issue mentioned earlier with cross-origin requests may have been exclusive to IE as well, but I think there was a larger window than "blink of an eye" that it was a issue.

But again, this is all long time ago, and it was in the beginning of my career, I might misremember and you may very well be right.

[JimDabell]

XMLHTTPRequest was originally an ActiveX object (something like ActiveXObject("Microsoft.XMLHTTP")), that’s probably what you are thinking of. You couldn’t make cross-domain requests with it though. Other browsers then implemented XMLHTTPRequest based on the ActiveX object, and then Internet Explorer supported XMLHTTPRequest and dropped ActiveX.

Before that, people who wanted to make cross origin requests sometimes used Flash but I think that always needed a crossdomain.xml file to work. JSONP was also used, which is where you source a <script> from the remote that calls a function in your own context to pass information in. You needed to be a little more careful with that, but only because you were deliberately passing information in; the browser couldn’t read it by itself.

I’m pretty sure the SOP has been effective in all non-Netscape browsers from as soon as they started supporting JavaScript.

[Izkata]

Looks like that largely affected things loaded by <script> tags, and either it was opt-in or didn't affect XMLHTTPRequest/fetch. The big change where we had to start dealing with cross-origin security didn't happen until the 2010s with CORS.

[mr_toad]

CORS isn’t designed to increase security, since the same-origin policy is a secure default.

It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.

[embedding-shape]

Yeah, basically Same-Origin Policy (https://en.wikipedia.org/wiki/Same-origin_policy) was the part that increased security, as it prevented websites (in browsers) from making arbitrary requests to arbitrary 3rd party websites.

Cross-Origin Resource Sharing (https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is one way to relax the Same-Origin Policy, so you essentially whitelist what actually can be shared across Origins. To be used when the default Same-Origin Policy is too strict.

Overall I think it's a really simple concept, but libraries/frameworks/docs seems to constantly over-complicate it with their explanations.

[Lerc]

But the combination of the two reduces security in the same manner as absurd password requirements cause people to write down their passwords.

A strong security measure without a reliable way to do the things you want to do induces people to bypass the security altogether.

Security designers generally are ok with this because they consider usability or user behaviour to be not their responsibility.

[TurdF3rguson]

If you're hosting some 3rd party api that's safe to call client side then you send some header that says so. The problem is when it's not safe and devs try to bypass (a reliable way to do the things they want).

The solution is to convince devs to not want to do those things.

[bazoom42]

CORS allows JavaScript to make requests to different domains than the origin of the page. By default (without CORS), JavaScript can only communicate with the origin domain.

[spl757]

A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol. More than that, it's a potential attack surface, and the idea is to reduce those. If you are the admin of something, and you are putting things into production in which you don't fully understand the implications, because you copy/pasted some crap from stackexchange assuming the person that posted it knew what they are talking about, then you are doing it wrong. Just look at this thread. It's chaos and reinforces the fact that even people that think they know, don't really know. When in doubt, grab the RFC and figure it out.

[locknitpicker]

> A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol.

The world seems to manage just well to get CORS to work, though. If developers fucking up implementations of any standard is enough justification to argue that something is worthless, you'd be hard pressed to find any software engineering topic that by your personal definition would be deemed worthless.

[yallpendantools]

> When in doubt, grab the RFC and figure it out.

Back in the day, I was using Cloudhopper, a Twitter-developed library for the SMPP protocol (not to be confused with SMTP!). Protocols being protocols, there are strict limits on field sizes, defined on the actual protocol spec. I noticed that Cloudhopper didn't impose those limits, however.

Long story short, it turns out they just left out strictly imposing field limits because other implementations didn't care either. De facto has overruled de jura and the inmates are running the asylum!