> So, without CORS, you have a all-or-nothing security model, where the needle would always pend to the "nothing" side. With CORS, that needle can point "all that matters"
Yes, and a policy that permits nothing is more secure than a policy that permits some things. Although “nothing” is not accurate, some requests are still permitted in either case.
> You simply cannot claim that allowing only requests to the origins you explicitly allow is an erosion of a security model.
I didn't claim that. “Allowing only requests to the origins you explicitly allow” implies that you are enforcing a restriction, when in fact the opposite is happening – you are permitting more by removing restrictions. Tightly scoping what you open up with CORS is still removing restrictions, not adding them.
You're reading that backwards. "nothing" is "no security".
Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize that CORS relaxes the Same-Origin Policy.
The grandparent comment argues about semantics and provides information that is technically correct, but not in a useful sense. To say that "CORS decreases security" because it opens up cross origin communication is perhaps not disingenuous (who can say?) but certainly misleading. All browser users would be worse off without CORS.
I think we are arriving at the word 'security' with different starting points and lenses, and a different chunking of what constitutes CORS. So I too am guilty of making a semantic argument.
You and fivea are conflating functionality with security.
Yes, it may be functionally desirable for an app to allow cross-origin requests, as enabled by CORS. But, you're granting permissions, and that is opening things up, possibly making them less secure.
I think great-grandparent's point highlighting this is worth making, given that there is so much confusion around CORS.
Letting people have access to things that they are supposed to have access to is part of security. You don't get perfect security just by denying everyone access to everything.
fivea wasn't conflating functionality and security. They were saying that a world without CORS would be a world where those rights are always granted.
Or a world where those rights are never granted.
Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people believe that CORS is intended to "lock things down" vs. "open them up". They don't understand that it's opt-in or the default behavior without it.
But, it's a matter of fact that usage of CORS presents risks vs the default policy, and those risks must be considered. That's really the point vs the idea that CORS has no utility.
It's worth noting too that, strictly speaking, there are frequently workarounds to the default policy that don't require CORS, some of which are arguably more secure by way of being less prone to configuration errors.
Okay, sure, there's a semantics question and also some people are just confused.
So here is where I took issue: Yes, many confused people are conflating functionality and security. But while fivea/pshc's words might accidentally encourage that confusion, they were not confused, and were not conflating the two.
Probably more semantics. I don't claim to know what's in fivea/pshc's heads or whether they themselves are confused. I was speaking to my observation that their comments merged the two issues.
You may prefer phrasing like, "their words might accidentally encourage confusion" versus "conflation". I'd say conflation is the mechanism there, but OK.
Or you might prefer I specifically clarify "their comments conflated the two" vs "they conflated the two".
OK.
So their comments did not conflate, but might accidentally cause future conflation, so it's reasonable to reply to make the difference extra clear, but I don't think it's reasonable to accuse them of conflation.
It happens. Thanks for clarifying.
We’ve already seen a world without CORS, and that didn’t happen. Cross-origin restrictions were brought in almost immediately after the introduction of JavaScript and existed for over a decade before CORS was introduced.
> All of this is completely wrong.
Is not only needlessly argumentative but also wrong itself. The 3rd point they include as "completely wrong" is not wrong, and they end up just rephrasing it later in their correction.
It is:
> With cURL, no CORS takes effect, so the attacker has direct access with the full rights of the user.
The attacker has direct access with the full rights of the user because this is not a situation where one origin is making a request for a resource from another origin, so there’s nothing that says this shouldn’t happen. It’s got absolutely nothing to do with CORS at all.
I believe it’s important developers learn the nuances, otherwise we will likely see more faulty implementations.
It's great that CORS is a thing in browsers, and you can use it if you need. But each person who uses it is allowing more origins, and so allows more requests.
Personally I always avoid CORS and just server every thing I need from the same origin, but that's just because of the kinds of things I've worked on.
No, not really. Your simplistic example fails to acknowledge that your same-site "lock with no keys" model rendered same-origin-policy completely unusable in projects that fall beyond the scope of a personal hobby project, which left the whole world with no alternative to turn it off. CORS recognizes the absurdity of implicitly assuming that the same origin is the only possible and conceivable safe origin, or even that a site has a single origin.
Therefore, your comparison would actually be between an old lock which was no longer usable and thus forced everyone to go around with no locks, or a lock designed around one of the world's most basic requirements and thus made it possible for the old lock concept to be applicable.
If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by zero.
This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic.
Your personal assertion that CORS somehow decreases security is based on the patently false assertion that at any point in time requests only came from the same origin. Not only was this never the case, this ignores the fact that with the popularity of REST and SPAs and microservices and API-as-a-service, the norm was since switched to having browsers make requests to anything other than the same origin.
So, without CORS, you have a all-or-nothing security model, where the needle would always pend to the "nothing" side. With CORS, that needle can point "all that matters", which is pretty close to the optimal same-site solution. What CORS does is allow developers to abstract away the definition of "same origin" to mean "the origins that I explicitly allow".
You simply cannot claim that allowing only requests to the origins you explicitly allow is an erosion of a security model. That makes no sense. It made no sense when implicitly that list was only comprised of your own domain, it makes no sense now when that list includes reputable APIs that you pay to use.