3 ms·

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

by stymaar 4mo ago

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. For non-idempotent requests however (the only ones that are supposed to be able to have side effects), a preflight OPTION request will be sent in cross-origin context instead of sending the request itself. And unless the right headers are set in the OPTION response, the request won't be sent at all.

Sophira 4mo ago
That's not quite correct. POST requests with certain Content-Type headers, such as text/plain or multipart/form-data, will still be allowed without any kind of preflight. If the web application doesn't check the Content-Type header strictly, then you've got a problem.
- stymaar 4mo ago
  You're right, I forgot that form requests bypass the preflight.
muvlon 4mo ago
We are saying the same things, just expressing them in different terms. Yes, only idempotent methods and "safe" POST requests don't need preflight. And I'm saying you need to make sure in your server implementation that those are actually safe. The article states that the CORS header will prevent random other websites from talking to localhost at all, which is just wrong.
ksbd-pls-finish 4mo ago
>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. Just my first thought as a security engineer, but sounds like a perfect opportunity to execute a timing attack to me. For example, vheck which users exist (by measuring response time for /api/users?name=john) etc
- bazoom42 4mo ago
  Probably, but note that cross-domain GET-requests have been supported since the beginning of the web, since this is literally how links works. So while a badly implemented GET handler can indeed cause security issues, this is old news and unrelated to CORS. (Besides, why measure response times? Can’t you just check if api/users?name=john returns a resource or a 404 not found?)
JimDabell 4mo ago
> 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 request once or several times. GET is defined to be both safe and idempotent. Clients can make GET requests without explicit human intent driving them because they are safe, not because they are idempotent. DELETE is not defined to be safe but it is defined to be idempotent. This means you need human intent to drive it, but clients can retry as much as they like because whether you ask to delete a resource one time or a hundred times, the result is still the same – the resource is deleted. Obviously making DELETE requests can result in adverse effects even though it is idempotent. POST is neither safe nor idempotent, however it’s subject to some unintuitive rules when it comes to things like cross-origin requests for historical reasons.
- stymaar 4mo ago
  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.
  - gbuk2013 4mo ago
    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.
    - stymaar 4mo ago
      > 202 would be another Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right. > 200 with some sort of response to distinguish (e.g. { changed: boolean }). Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}
w29UiIm2Xz 4mo ago
I encountered many a web service that do not use HTTP verbs correctly.
bazoom42 4mo ago
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.
827a 4mo ago
> if your server is implemented in a sensible way, lol
J-Kuhn 4mo ago
You can do GET & POST requests without preflight. The logic behind this is: It was possible to do this before the introduction of those APIs anyway - but you could not read the response. You could send a GET request by, for example, embedding an image. And you could send a POST request by submitting a form - even if the form did only consist of hidden elements. Those are called "simple requests": https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR... It is expected from web application that they can correctly handle those requests, even when they were sent from a different origin (for example, blocking them by using a CSRF token). It was however not expected that existing web applications could handle non-simple requests - as the ability to do so was restricted either to command line tools or required other user interaction/configuration. This is where the preflight request comes in - send an OPTIONS to check if the other side is okay with that kind of request. But what CORS do is: It can make the response available to the requesting script - the request did already happen if it didn't require a preflight.
dataflow 4mo ago
You're confusing "idempotent" with "pure", I think.

by stymaar 4mo ago

Sophira 4mo ago

That's not quite correct. POST requests with certain Content-Type headers, such as text/plain or multipart/form-data, will still be allowed without any kind of preflight. If the web application doesn't check the Content-Type header strictly, then you've got a problem.

stymaar 4mo ago
You're right, I forgot that form requests bypass the preflight.

muvlon 4mo ago

We are saying the same things, just expressing them in different terms. Yes, only idempotent methods and "safe" POST requests don't need preflight. And I'm saying you need to make sure in your server implementation that those are actually safe. The article states that the CORS header will prevent random other websites from talking to localhost at all, which is just wrong.

ksbd-pls-finish 4mo ago

>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. Just my first thought as a security engineer, but sounds like a perfect opportunity to execute a timing attack to me. For example, vheck which users exist (by measuring response time for /api/users?name=john) etc

bazoom42 4mo ago
Probably, but note that cross-domain GET-requests have been supported since the beginning of the web, since this is literally how links works. So while a badly implemented GET handler can indeed cause security issues, this is old news and unrelated to CORS. (Besides, why measure response times? Can’t you just check if api/users?name=john returns a resource or a 404 not found?)

JimDabell 4mo ago

> 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 request once or several times. GET is defined to be both safe and idempotent. Clients can make GET requests without explicit human intent driving them because they are safe, not because they are idempotent. DELETE is not defined to be safe but it is defined to be idempotent. This means you need human intent to drive it, but clients can retry as much as they like because whether you ask to delete a resource one time or a hundred times, the result is still the same – the resource is deleted. Obviously making DELETE requests can result in adverse effects even though it is idempotent. POST is neither safe nor idempotent, however it’s subject to some unintuitive rules when it comes to things like cross-origin requests for historical reasons.

stymaar 4mo ago
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.
- gbuk2013 4mo ago
  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.
  - stymaar 4mo ago
    > 202 would be another Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right. > 200 with some sort of response to distinguish (e.g. { changed: boolean }). Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}

w29UiIm2Xz 4mo ago

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

bazoom42 4mo ago

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.

827a 4mo ago

> if your server is implemented in a sensible way, lol

J-Kuhn 4mo ago

You can do GET & POST requests without preflight. The logic behind this is: It was possible to do this before the introduction of those APIs anyway - but you could not read the response. You could send a GET request by, for example, embedding an image. And you could send a POST request by submitting a form - even if the form did only consist of hidden elements. Those are called "simple requests": https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR... It is expected from web application that they can correctly handle those requests, even when they were sent from a different origin (for example, blocking them by using a CSRF token). It was however not expected that existing web applications could handle non-simple requests - as the ability to do so was restricted either to command line tools or required other user interaction/configuration. This is where the preflight request comes in - send an OPTIONS to check if the other side is okay with that kind of request. But what CORS do is: It can make the response available to the requesting script - the request did already happen if it didn't require a preflight.

dataflow 4mo ago

You're confusing "idempotent" with "pure", I think.