API keys are for projects, authentication is for users. Read more here - https://cloud.google.com/endpoints/docs/openapi/when-why-api...
CORS is not meant to secure an API endpoint
51–60 of 162 posts
Re: CORS is not meant to secure an API endpoint
#52The real problem that someone had to urgently explain any of this in the first place.
Re: CORS is not meant to secure an API endpoint
#53Earlier quoted context omitted.
Again, CORS does not protect, the SOP does :-)
You can consider CORS a relaxation on top of SOP (same-origin policy), since CORS allows you to opt-in to certain cross-site requests which are not allowed under SOP. Then again, SOP allows certain requests like 'PUT' and 'DELETE' requests back to the origin server which was not allowed before SOP, so in that sense SOP is also a relaxation. Bit it is a good point that CORS enables more forms of cross-site requests th…
SOP is certainly not a relaxation. SOP restricts all those cross-origin request.
I don't quite understand what you mean with PUT and DELETE not being allowed before SOP? What exact operations where not possible before SOP and are now (and pose a security risk?)
Re: CORS is not meant to secure an API endpoint
#54Earlier quoted context omitted.
You can consider CORS a relaxation on top of SOP (same-origin policy), since CORS allows you to opt-in to certain cross-site requests which are not allowed under SOP. Then again, SOP allows certain requests like 'PUT' and 'DELETE' requests back to the origin server which was not allowed before SOP, so in that sense SOP is also a relaxation. Bit it is a good point that CORS enables more forms of cross-site requests th…
SOP is certainly not a relaxation. SOP restricts all those cross-origin request. I don't quite understand what you mean with PUT and DELETE not being allowed before SOP? What exact operations where not possible before SOP and are now (and pose a security risk?)
It was not possible to initiate a PUT or DELETE request from browsers until XMLHttpRequest with same-origin-policy was introduced.
Re: CORS is not meant to secure an API endpoint
#55Earlier quoted context omitted.
SOP is certainly not a relaxation. SOP restricts all those cross-origin request. I don't quite understand what you mean with PUT and DELETE not being allowed before SOP? What exact operations where not possible before SOP and are now (and pose a security risk?)
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).
Re: CORS is not meant to secure an API endpoint
#56> 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…
From experience, I can tell you that many people simply refer to this entire domain as CORS despite that S standing for Sharing. The Same Origin Policy is treated verbally more like the default state of CORS in some circles. It is very confusing and I’m not entirely sure how it ended up like that.
It's a common for protocols, mechanisms and policies to be confused in terms of intention, and often to be misunderstood. SameSite was another example recently, a lot of people don't understand that Site and Origin have specific meanings in the browser world.
From my own time observing the process of how these things get drafted up, it's because the creators of these mechanisms work in a committee and in a circle in which everyone is highly familiar with their specific terminology. There is no thought given to accessibility of general understanding for 'the masses' and that eventually manifests itself in this way. I'm not saying they should or shouldn't be giving thought to naming, just pointing out what I observe.
Re: CORS is not meant to secure an API endpoint
#57Why 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.
Re: CORS is not meant to secure an API endpoint
#58Why 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.
[deleted]
Re: CORS is not meant to secure an API endpoint
#59NoSherlock and Captain Obvious shook hands for this