101–110 of 162 posts
Earlier quoted context omitted.
Again, CORS does not protect, the SOP does :-)
> 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.
No they are not making that assumption.
Earlier quoted context omitted.
This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send…
Yup. CORS has so many loopholes that you should pretend like it doesn't exist. My favorite is... imagine I routinely port-forward an app's debug port to my workstation for debugging. It has a useful /email-debug-info?address=example@example.com endpoint. You can then call that over the Internet by serving me a web page that contains http://localhost:1234/email-debug-info?address=example@examp... ">. CORS doesn't care…
This is just a CSRF issue, which is well understood and easily fixed with a CSRF/authenticity token.
Also, GET requests should not have side effects like sending an email. A reasonable default seen in some frameworks is GET requests have no side effects and don't require CSRF tokens, while all other verbs do.
If my API doesn't use cookies, is there any reason for me to not fully enable CORS on the server? I.e. using JWT in a typical SPA API scenario.
If you have any unauthenticated routes that you don't want arbitrary websites calling. > using JWT in a typical SPA API scenario. Is this typical? It's a pretty horrible setup. Cookies have a lot of great features that 'store a JWT in LocalStorage' just doesn't have.
I'm still interested in the original question: if you use localstorage for auth tokens and you have proper CSRF protection, what does allowing all CORS actually make you vulnerable to?
Earlier quoted context omitted.
> 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…
> 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. Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize…
The grandparent comment argues about semantics and provides information that is technically correct, but not in a useful sense. To say that "CORS decreases security" because it opens up cross origin communication is perhaps not disingenuous (who can say?) but certainly misleading. All browser users would be worse off without CORS.
I think we are arriving at the word 'security' with different starting points and lenses, and a different chunking of what constitutes CORS. So I too am guilty of making a semantic argument.
CORS is well defined here: it ALLOWS a browser to make certain types of requests to endpoints outside the domain the browsed website comes from:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Because the browser follows the same origin policy for a number of API (like FETCH):
https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
Also if you are a developer, please check:
https://developer.mozilla.org/en-US/docs/Glossary/CSP
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
To add an extra layer of protection against cross site scripting. I think one of the recent data leak could have been avoided if the website implemented that very basic header all modern browsers support.
> 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…
It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.
Request headers and body content-type are also a factor for POST, anything which couldn't be set through a FORM is forbidden.
The most common issue is that the request is only simple if its content-type is `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain`. JSON POST requests usually run afoul that. The second big issue is setting bespoke headers as only Accept, Accept-Language, Content-Language, and Content-Type (restricted to the above list) are simple. There common sticking points are headers like Authorization.
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…
I know the official line is that CORS “protects” the relying party (the website that initiates requests) but in practice I have found it to be quite the opposite. From having to deal with CORS over the years, to me is just a tool to protect one thing… the intellectual property of whatever site we are loading resources from. For example, images arrive “tainted” and you can’t get their pixels on a canvas no matter how…
(Besides, I'm not sure where it falls inside the new Firefox extension rules, but this is the kind of thing to implement on an extension, or in the worst case, on a plugin.)
Earlier quoted context omitted.
It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.
This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send…
yep, that's what Cross-Origin Resource Policy (CORP) for. It is designed to seal the last loop hole in same-origin policy. (img and scripts don't require cors at all) But there is a big gotcha, the old browser that don't know about it simply don't care. So it isn't strictly useful for now.
> 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…