61–70 of 162 posts
Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.
My guess is that it's related to subdomains not guaranteeing to be from the same origin.
The result is that people run into errors, Google them, copy paste the top SO result which advices to allow *
Doesn't seem ideal
Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.
Earlier quoted context omitted.
It was not possible to initiate a PUT or DELETE request from browsers until XMLHttpRequest with same-origin-policy was introduced.
That doesn't matter at all in a security context. POST can (and is used) for everything DELETE and PUT are used. Adding DELETE and PUT did not relax anything. The only question is whether requests are restricted (i.e. in terms of sending resources like cookies).
> CORS is an implementation in the browser and is designed to protect the user from malicious applications by ensuring that the resource in the browser is only allowed to access specific endpoints. > This browser implementation can be bypassed at any time. First, it is up to the browser itself: if CORS is not integrated, or not integrated cleanly, then it will not work. > An attacker can access the API key via the so…
This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic.
Your personal assertion that CORS somehow decreases security is based on the patently false assertion that at any point in time requests only came from the same origin. Not only was this never the case, this ignores the fact that with the popularity of REST and SPAs and microservices and API-as-a-service, the norm was since switched to having browsers make requests to anything other than the same origin.
So, without CORS, you have a all-or-nothing security model, where the needle would always pend to the "nothing" side. With CORS, that needle can point "all that matters", which is pretty close to the optimal same-site solution. What CORS does is allow developers to abstract away the definition of "same origin" to mean "the origins that I explicitly allow".
You simply cannot claim that allowing only requests to the origins you explicitly allow is an erosion of a security model. That makes no sense. It made no sense when implicitly that list was only comprised of your own domain, it makes no sense now when that list includes reputable APIs that you pay to use.
Once fully understood, it is useless mechanism of security theater.
Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.
It's inconvenient for sure but I've never dug deep into this the issue. My guess is that it's related to subdomains not guaranteeing to be from the same origin. The result is that people run into errors, Google them, copy paste the top SO result which advices to allow * Doesn't seem ideal
API keys are for projects, authentication is for users. Read more here - https://cloud.google.com/endpoints/docs/openapi/when-why-api...
(Also, I'm pretty sure an api key is a form of authentication.)
Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.
although browsers only accept a single origin domain or wildcard as cors header, the server can trivially handle the multi domain use case. on preflight request, check the location header in the request, and if it belongs to a defined whitelist, set the cors header on the response to that domain or subdomain. I don't know the why, but I can imagine that since there is a reasonable work around, browser implementers pe…
> CORS is an implementation in the browser and is designed to protect the user from malicious applications by ensuring that the resource in the browser is only allowed to access specific endpoints. > This browser implementation can be bypassed at any time. First, it is up to the browser itself: if CORS is not integrated, or not integrated cleanly, then it will not work. > An attacker can access the API key via the so…
> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Your personal assertion that CORS somehow decreases se…
CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side. CORS protect against the scenario where a malicious site tricks an…
Again, CORS does not protect, the SOP does :-)
This is simply false. You are somehow wrongly assuming that only same-origin requests exist or are needed. This scenario never existed in the real world beyond the scope of small personal projects.