Live data from Hacker News

Do You Really Know CORS?

performantcode.com

21–30 of 127 posts

Re: Do You Really Know CORS?

#21

Earlier quoted context omitted.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

[deleted]

Re: Do You Really Know CORS?

#22
post #5

This is really an informative article. We've recently stumbled across this issues and all other pages I could google did not explain it as clearly as this page.

My experience was the same as yours, resources explaining things assumed technical knowledge far beyond my level or were not very clear. This was a very well put-together article.

My only contribution to the discussion is that if you get a CORS error where you wouldn't expect it, the problem might not be a CORS issue. I spent the better part of a weekend trying to debug why a request to a Google API wasn't working and why I was seeing a CORS error (same thing worked fine on another system). Turns out, it wasn't the same thing, my url had a typo...

Re: Do You Really Know CORS?

#23
post #19

Earlier quoted context omitted.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

The origin could still be falsified client-side.

No, it can't be falsified by JS in the browser. CORS is only relevant for JS in the browser; it doesn't impact curl at all, for example.

Re: Do You Really Know CORS?

#24

Earlier quoted context omitted.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

The people with the security problem are the users of browsers, and the browser vendors have a solution to solve that problem built into the browser. If they didn’t enforce it at the browser level, the owners of the servers would have little incentive to enforce CORS and most just wouldn’t. See https adoption.

Re: Do You Really Know CORS?

#25
Im curious how many newer JS+API applications still use browser cookies as a means of authenticating API requests and how prevalent cookie usage still is for these types of applications?

JWT/tokens + Local/session storage + adding fetch headers seems like the best way as long as you don't run untrusted JS.

Re: Do You Really Know CORS?

#27
post #13

Had to deal with a firewall that filtered all unknown/"new" HTTP headers. This included CORS. A PITA to find the reason why Firefox wouldn't use the Google fonts.

That kind of crapware is why I'm increasingly glad that the http specs are moving towards being completely illegible to middleware boxes.

Re: Do You Really Know CORS?

#28
post #6

I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't possible to win, so barring my becoming a billionaire I've kinda just accepted that third party is here for at least a little while and I'm not going to refuse to use ads and analytics. Except on my personal website, that gets to stay cool. That said, CORS is th…

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS protects against a non-modified browser uased by Joe Random User installed via a factory/distribution path being tricked into doing something against the site policy, therefore exposing the user.

Re: Do You Really Know CORS?

#29
My only experience with CORS has been when trying to access api.foo.com from a web page on foo.com, and then getting denied. Then I messed with the settings on api.foo.com trying to get it to allow access from foo.com, and then I gave up and just configured the load balancer on foo.com to proxy requests to foo.com/api to api.foo.com.

So far it's only gotten in my way as a developer. But it's there to protect users, not me. So at the end of the day, I'm glad it's there as a way to somewhat prevent people from tricking my users into hitting my api with malicious requests.

Re: Do You Really Know CORS?

#30
post #13

Had to deal with a firewall that filtered all unknown/"new" HTTP headers. This included CORS. A PITA to find the reason why Firefox wouldn't use the Google fonts.

That kind of crapware is why I'm increasingly glad that the http specs are moving towards being completely illegible to middleware boxes.

How would http be any harder for middleware than app-layer? If both linked to libhttp.c, couldn't they each get the full parsing/reading/writing - wether proxy or server?
Post reply on HN