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

Developers don't understand CORS (2019)

fosterelli.co

Post reply on HN
Print view View original

211–220 of 285 posts

Re: Developers don't understand CORS (2019)

#211

Post by ralusek »

9dev wrote: post #77
ralusek wrote: post #63

I understand CORS and I don't. TL;DR: It's a restriction your browser gives itself . If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call. I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simp…

> […] the browser prevents itself from making the call. That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.

My understanding was it was an OPTIONS preflight request that is made.

Re: Developers don't understand CORS (2019)

#212

Post by w29UiIm2Xz »

stymaar wrote: post #142
muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

I encountered many a web service that do not use HTTP verbs correctly.

Re: Developers don't understand CORS (2019)

#213

Post by marcosdumay »

tgv wrote: post #117
ghoshbishakh wrote: post #74

Earlier quoted context omitted.

100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).

I think many (most?) have preferred sources. I would weight Wikipedia and MDN higher than Snurk Grubble's blog in training, no matter what the topic.

Also, you can count on most developers to reach the documentation only as a last resort, and try every random blog first.

Re: Developers don't understand CORS (2019)

#214

Post by revetkn »

I did not really understand CORS until I sat down and wrote a server implementation of it and had to think hard about "what hooks should be exposed to developers for controlling it?"

Most of us I think just "expose a set of whitelisted origins and be done with it".

Here is where I landed for how to specify your server's CORS policy:

https://soklet.com/docs/cors#custom-workflow

Re: Developers don't understand CORS (2019)

#215

Post by bazoom42 »

stymaar wrote: post #142
muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

You are kind-of both right. The spec defines a subset of cross-domain requests called “simple requests” - basically such requests as has always been supported by a plain html form. These are not affected by same-origin or CORS. So you can post url/form-encoded data to a different domain - but you cant access the response.

But CORS affect all other requests, e.g POST using JSON or XML content type, and all other methods like PUT, DELETE, PATCH.

So you can do an unsafe POST using form-encoded data, but if a server supports this, they hopefully mitigate CSRF, since this has always been a risk.

Re: Developers don't understand CORS (2019)

#216

Post by 9dev »

ralusek wrote: post #211
9dev wrote: post #77

Earlier quoted context omitted.

> […] the browser prevents itself from making the call. That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.

My understanding was it was an OPTIONS preflight request that is made.

Only for complex requests, and even then - a naive implementation of a web application that executes actions on GET requests might do the same for a HEAD request too.

Re: Developers don't understand CORS (2019)

#217

Post by chuckadams »

TeMPOraL wrote: post #160
xg15 wrote: post #151

Earlier quoted context omitted.

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

Obviously JSON is a subset of text/plain, so I don't know what people were expecting? For text/plain to mean "plaintext, excluding any string that could possibly parse as any of the other named formats that have a plaintext representation"? Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?

If the JSON backend parses the payload as JSON without verifying the content type, then yes, it's a way through. There's no affirmative logic of "payload looks like json, so let it through" going on, it's just "parse this json without looking at content-type, and assume it was already subject to cross-origin restriction because it's json, right?" (same thing, just different intentions). And as we can see, that assumption fails to hold if you don't actually check the content-type.

My apps speak only JSON, so one of the first things I do is create a middleware that requires any POST/PUT/PATCH request to be application/json and reject everything else with a 415 error. That's so I can turn off the CSRF protection mechanics in the framework completely, but the two concerns are related.

Re: Developers don't understand CORS (2019)

#218

Post by stymaar »

JimDabell wrote: post #177
stymaar wrote: post #142

Earlier quoted context omitted.

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

> GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests. This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the requ…

I wasn't aware of the distinction between “safe” and “idempotent”, TIL, thank you.

> DELETE is not defined to be safe but it is defined to be idempotent

This one puzzles me though. How can DELETE be idempotent? If the first request works then the second one should return a 404, as the key to delete doesn't exist anymore.

Re: Developers don't understand CORS (2019)

#219

Post by Lerc »

mr_toad wrote: post #193
Beltiras wrote: post #143

Earlier quoted context omitted.

I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.

CORS isn’t designed to increase security, since the same-origin policy is a secure default. It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.

But the combination of the two reduces security in the same manner as absurd password requirements cause people to write down their passwords.

A strong security measure without a reliable way to do the things you want to do induces people to bypass the security altogether.

Security designers generally are ok with this because they consider usability or user behaviour to be not their responsibility.

Re: Developers don't understand CORS (2019)

#220

Post by gbuk2013 »

stymaar wrote: post #218
JimDabell wrote: post #177

Earlier quoted context omitted.

> GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests. This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the requ…

I wasn't aware of the distinction between “safe” and “idempotent”, TIL, thank you. > DELETE is not defined to be safe but it is defined to be idempotent This one puzzles me though. How can DELETE be idempotent? If the first request works then the second one should return a 404, as the key to delete doesn't exist anymore.

Response is implementation detail: a 404 on second request is one way to do it, a 202 would be another, or 200 with some sort of response to distinguish (e.g. { changed: boolean }).

Idempotency just means no state mutation on subsequent request.

Post reply on HN