Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do You Really Know CORS?

performantcode.com

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Do You Really Know CORS?

#41

Post by saganus »

Klathmon wrote: post #7

This is an awesome overview! But don't take it as all encompassing, it doesn't go into some of the more esoteric edge cases with CORS, like: * either an unreleased safari version, or the most recent version will send preflight requests even if the request meets the spec (like if the Accept-Language is set to something they don't like). * If you use the ReadableStream API with fetch in the browser, a preflight will be…

Genuine question: why do you feel you've cut your teeth more than most?

I.e. what kind of dev work do you do that makes you have to deal with this more than the average developer?

Re: Do You Really Know CORS?

#44

Post by johncolanduoni »

icebraining wrote: post #12
ravenstine wrote: post #10

Earlier quoted context omitted.

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

Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.

Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access.

Even still, a lot of people just put ‘Access-Control-Allow-Origin: *’ on everything as soon as they run into an issue, so that rule has to ban credentialed requests altogether.

Re: Do You Really Know CORS?

#45

Post by johncolanduoni »

mattnewton wrote: post #24
paulddraper wrote: post #15

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

Bingo. I still kind of wish there was an ability to make the browser invoke some kind of request that servers would reject by default (e.g. with a non-standard HTTP method) that could combine the preflight check and the request while still making servers that don’t anticipate CORS blanch and not take any dangerous actions. But the browser security model is complex and messy enough as it is, so I doubt it’s worth it.

Re: Do You Really Know CORS?

#46

Post by meddlepal »

saganus wrote: post #41
Klathmon wrote: post #7

This is an awesome overview! But don't take it as all encompassing, it doesn't go into some of the more esoteric edge cases with CORS, like: * either an unreleased safari version, or the most recent version will send preflight requests even if the request meets the spec (like if the Accept-Language is set to something they don't like). * If you use the ReadableStream API with fetch in the browser, a preflight will be…

Genuine question: why do you feel you've cut your teeth more than most? I.e. what kind of dev work do you do that makes you have to deal with this more than the average developer?

Not OP, but my guess... Most devs aren't frontend devs and I would categorize this as mostly a frontend developer problem.

Re: Do You Really Know CORS?

#48

Post by philcockfield »

parhamn wrote: post #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.

LocalStorage is so much more preferable than cookies, I agree, however as SSR ("server-side-rendering") of heavy client-side JS apps becomes more prevalent, suddenly cookies are back in business.

If the initial SSR needs some initial client-state to complete its work before sending the HTML payload, it can see the cookie, but not localStorage.

Re: Do You Really Know CORS?

#49

Post by jchook »

ottomanage wrote: post #22
lysium wrote: 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 an…

You may also enjoy https://hackernoon.com/im-harvesting-credit-card-numbers-and...

Re: Do You Really Know CORS?

#50

Post by jhabdas »

I don't know CORS that well, but like any dev worth their weight in salt I know how to get around it:

- iframe - domain js hack - reverse proxy - http header

What else? Referrer Policies await.

Post reply on HN