7 ms·

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that

by fivea 5y ago

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. 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.

iqanq 5y ago
If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.
- fivea 5y ago
  > If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened. 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.
  - JanSt 5y ago
    We are not arguing about the usefulness of CORS, of course it is useful. It does not protect you though.
- eurasiantiger 5y ago
  A lock with no keys can still be opened with a lockpick or just brute force.
- pshc 5y ago
  If you have a lock with no keys, it's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks. 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.
  - casion 5y ago
    "Lock with no keys" isn't particularly uncommon. They exist in the real world as one-way devices.
  - iakh 5y ago
    There's a while saying dedicated to it, "lock them up and throw away the key".
    - pshc 5y ago
      Hahah, alright. I'll grant you that. The lock:CORS metaphor was tenuous at inception, and now it is truly vaporized.
    - Dylan16807 5y ago
      Notice how nobody ever does that with an actual lock. It's a metaphor for never letting them go free.
hn_throwaway_99 5y ago
> 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. 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.
- blurker 5y ago
  Actually, I agree with OP. Grandparent's phrasing: > 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.
  - JimDabell 5y ago
    > The 3rd point they include as "completely wrong" is not wrong 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.
- vinnymac 5y ago
  You and OP make a good point. In that most people I’ve come across don’t understand how the Same-Origin Policy and Cross-Origin Resource Sharing differ and relate. I believe it’s important developers learn the nuances, otherwise we will likely see more faulty implementations.
- pshc 5y ago
  Regardless of their tone, fivea is correct to point this out as myopic. 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.
JimDabell 5y ago
The set of all requests possible with CORS is a superset of all requests possible without CORS. The entire purpose of CORS is to allow more requests. By definition, it removes security barriers and opens things up. > 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.
- Dylan16807 5y ago
  > Yes, and a policy that permits nothing is You're reading that backwards. "nothing" is "no security".
patrickthebold 5y ago
I think the confusing is in "adding CORS". I think you mean "Adding CORS to the browser standards", and gp means "Adding some kind of CORS interceptor thing in my backend". 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.

by fivea 5y ago

iqanq 5y ago

If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

fivea 5y ago
> If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened. 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.
- JanSt 5y ago
  We are not arguing about the usefulness of CORS, of course it is useful. It does not protect you though.
eurasiantiger 5y ago
A lock with no keys can still be opened with a lockpick or just brute force.
pshc 5y ago
If you have a lock with no keys, it's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks. 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.
- casion 5y ago
  "Lock with no keys" isn't particularly uncommon. They exist in the real world as one-way devices.
- iakh 5y ago
  There's a while saying dedicated to it, "lock them up and throw away the key".
  - pshc 5y ago
    Hahah, alright. I'll grant you that. The lock:CORS metaphor was tenuous at inception, and now it is truly vaporized.
  - Dylan16807 5y ago
    Notice how nobody ever does that with an actual lock. It's a metaphor for never letting them go free.

hn_throwaway_99 5y ago

> 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. 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.

blurker 5y ago
Actually, I agree with OP. Grandparent's phrasing: > 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.
- JimDabell 5y ago
  > The 3rd point they include as "completely wrong" is not wrong 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.
vinnymac 5y ago
You and OP make a good point. In that most people I’ve come across don’t understand how the Same-Origin Policy and Cross-Origin Resource Sharing differ and relate. I believe it’s important developers learn the nuances, otherwise we will likely see more faulty implementations.
pshc 5y ago
Regardless of their tone, fivea is correct to point this out as myopic. 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.

JimDabell 5y ago

The set of all requests possible with CORS is a superset of all requests possible without CORS. The entire purpose of CORS is to allow more requests. By definition, it removes security barriers and opens things up. > 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.

Dylan16807 5y ago
> Yes, and a policy that permits nothing is You're reading that backwards. "nothing" is "no security".

patrickthebold 5y ago

I think the confusing is in "adding CORS". I think you mean "Adding CORS to the browser standards", and gp means "Adding some kind of CORS interceptor thing in my backend". 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.