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

111–120 of 127 posts

Re: Do You Really Know CORS?

#111

Post by [deleted] »

laumars wrote: post #77
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…

The entire webstack is such a broken mess of inconsistencies and thousands of hidden traps that can render the entire thing insecure. People moan about C yet I find the web stack greatly more painful to write because you didn't even have control over the compiler following standards strictly (where stuff has even been standardised). I really do wish we worked together to create a new standard for building and deployi…

[deleted]

Re: Do You Really Know CORS?

#112

Post by afs35mm »

Here's one question that's always bugged me - What's stopping a malicious user from sending an HTTP request from any API client like Postman, or even Curl from the CL? Something like a post with: {transferTo: myAccountId, amount: 1000000000}?

Obviously in any nontrivial web app it would fail because of authentication issues, but if a server doesn't do ANY sort of security checking, that should work, no? Does that mean that the onus is on the server developer of mybank.com? And if so, what would stop the malicious request from working on any server developed before the existence of CORS?

Re: Do You Really Know CORS?

#113

Post by joevandyk »

afs35mm wrote: post #112

Here's one question that's always bugged me - What's stopping a malicious user from sending an HTTP request from any API client like Postman, or even Curl from the CL? Something like a post with: {transferTo: myAccountId, amount: 1000000000}? Obviously in any nontrivial web app it would fail because of authentication issues, but if a server doesn't do ANY sort of security checking, that should work, no? Does that mea…

Server is supposed to check authentication/authorization through some method.

If HTTP, that’s done via setting some information in the request headers, be it a cookie, or basic auth, or token auth, or similar.

CORS is done by the browser - to not allow certain requests to be made (In case you are accidentally executing malicious javascript code). The server tells the browser via the CORS headers which requests are ok to make.

Re: Do You Really Know CORS?

#114

Post by biot »

Ajedi32 wrote: post #51
paulddraper wrote: post #8

Earlier quoted context omitted.

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. I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access wo…

It’s secure in a “trust the client” manner. Any server code not still doing its own authentication is in for a rude awakening.

Re: Do You Really Know CORS?

#116

Post by paulddraper »

sbergot wrote: post #108
paulddraper wrote: post #102

Earlier quoted context omitted.

I don't misunderstand. My beef with CORS is that I have to encoded the validation logic into its HTTP headers. But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.

> CORS are a cheaper way to enable cross origin requests

Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?

Re: Do You Really Know CORS?

#117

Post by acoard »

lwansbrough wrote: post #9

I love CORS. I wouldn't be able to provide the level of security with my API that I do because of it. Without CORS, I don't believe my API design would be practically possible due to the security risks. If I have access to the Fetch API, I can tell the browser to send the user's cookie cross-origin and I can validate the request based on the origin. This allows for interesting authentication scenarios without the nee…

>and I can validate the request based on the origin

Are you talking about the HTTP referer? That's easily spoofable and can't be relied on server-side. The same-origin policy and all the CORS security is implemented in the browser itself, not in HTTP.

If you need to be certain that a request originated from your own page and not another domain you need to use a CSRF token.

Re: Do You Really Know CORS?

#118

Post by lwansbrough »

acoard wrote: post #117
lwansbrough wrote: post #9

I love CORS. I wouldn't be able to provide the level of security with my API that I do because of it. Without CORS, I don't believe my API design would be practically possible due to the security risks. If I have access to the Fetch API, I can tell the browser to send the user's cookie cross-origin and I can validate the request based on the origin. This allows for interesting authentication scenarios without the nee…

>and I can validate the request based on the origin Are you talking about the HTTP referer? That's easily spoofable and can't be relied on server-side. The same-origin policy and all the CORS security is implemented in the browser itself, not in HTTP. If you need to be certain that a request originated from your own page and not another domain you need to use a CSRF token.

I'm talking about the Origin header, which is present on XHR requests and cannot be assigned by code. A CSRF token is not necessary if you require Origin because the origin is not sent with standard HTML forms.

Re: Do You Really Know CORS?

#119

Post by ec109685 »

paulddraper wrote: post #116
sbergot wrote: post #108

Earlier quoted context omitted.

Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.

> CORS are a cheaper way to enable cross origin requests Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?

If your server can handle Origin checks that way, then leave your CORS headers wide open and problem solved.

The problem is that existing servers don’t generally check origin headers, so browsers needed some other mechansim to understand which requests were safe.

Re: Do You Really Know CORS?

#120

Post by ec109685 »

biot wrote: post #114
Ajedi32 wrote: post #51

Earlier quoted context omitted.

> 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. I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access wo…

It’s secure in a “trust the client” manner. Any server code not still doing its own authentication is in for a rude awakening.

If you don’t trust the client, there is nothing you can do. An insecure browser could spoof the origin header too.
Post reply on HN