141–150 of 285 posts
Once you understand that it's onlying to solve problems that happen in a user's compliant browser, and not some wider issue of resource authorisation, it does get a bit easier to understand.
Though in a way CORS seems too simple for what it achieves.
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…
> 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.
Earlier quoted context omitted.
I don't think you can even say CORS does that. The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party, If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the…
It seems like nobody understands CORS. Including me TBH.
Earlier quoted context omitted.
I think you're confused. The only thing blocked would be client side fetch. You need to find another way to protect everything else.
> The only thing blocked would be client side fetch. Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?
I wish more people read the CORS article on MDN[1] which helped me a lot at the time when I was trying to understand it. I knew some people had trouble with CORS but had no idea it was this bad, going by the comments here. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
Earlier quoted context omitted.
I don't care about my server. It has everything to do with what it is preventing my browser client from doing. The whole point is using content from the whole web not my server.
You can do whatever you want with your browser client. You just cannot create a website that will make the browser clients of other people send authenticated requests from JavaScript to my site if I don’t want that.
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.…
This is really a self inflicted problem. If you host your backend on the same origin as your frontend (using a reverse proxy) you don’t need CORS at all and you can use the vanilla SOP, and strengthen it further with a strict CSP.
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…
> (ignoring preflight requests for now and assuming we're talking just about "safe" Methods) You can't ignore those because they constitute the bulk of CORS' security model. Yes, you're technically right that CORS cannot prevent other websites from making any request to your server - this would be impossible, since the browser somehow has to get the CORS headers in the first place. However what CORS absolutely lets y…
Earlier quoted context omitted.
> (And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.) Is that so? Neither urlencoded forms nor multipart/form-data are valid JSON on the wire, so while other websites could send requests, wouldn't they just hit a parse error?
You can massage a text/plain form into valid JSON. text/plain is also one of the allowed default types. It works if the server doesn't check the content-type. Source: I've done that successfully in multiple pentests. Edit: lazy LLM generated example: That gives you {"key":"value", "ignore":"="} The trick is to stuff the = character you cannot control into an irrelevant value.