Live data from Hacker News

Developers don't understand CORS

fosterelli.co

81–90 of 366 posts

Re: Developers don't understand CORS

#81
Rarely does a application actually need to enable CORS. If all of your webcalls are from the same domain YOU DONT NEED CORS. (Chatbots/socket.io)

You only need CORS if you need the browser to act as a middleman to pass information back. IE: Credit Card Payment IFRAME

If you screw up CORS implementation it just means that anyone can read any information set by your website.

https://www.moesif.com/blog/technical/cors/Authoritative-Gui...

Re: Developers don't understand CORS

#82
post #32

Earlier quoted context omitted.

As a motivation to use: To prevent other sites using your resources, causing you an extra bandwith cost.

Back in the day, we used to use some Apache redirect magic to redirect to, say, an image of our choosing when the Referrer header was wrong. I had a relatively polite 'hey, you can see this image here:' message. Other people redirected to less friendly things.

You can still do this. The Referer header is sent by default on requests, and you can make your server interpret it to do anything you want.

Re: Developers don't understand CORS

#83
post #47

Earlier quoted context omitted.

> I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.

I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...

If you use fetch or XHR, yes.

If you just create an HTML form with the bank as action, fill in the inputs and submit via JS, no, because that's _navigating away_. This is also why GET requests that perform actions are dangerous, you can just embed them as an image to provoke a request. Which is exactly how zoom built their API. (they also then measured the size of the image to determine the response code, which is.... inventive)

Re: Developers don't understand CORS

#84
post #24

Seriously wondering! Why is Zoom worth $2B and companies are paying per minute plans to host meetings when you can now host your own videoconferencing software easily on your own website or app or intranet using WebRTC, branded, with your own experience, widgets, and it can all be open source? All you need to pay for are dumb TURN servers eg from twilio. Plus it would be far more secure. For example we built https://…

Can I host my own, or can I build my own? Is that platform ready to be installed and reused by other organizations?

Re: Developers don't understand CORS

#85
post #60

Earlier quoted context omitted.

I think you could implement that with CORS + CSRF tokens (blocking all types of Cross-Origin requests) but the default behaviour is to allow Cross-Origin writes (e.g. with form submissions). See https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... This is why we have CSRF tokens. So that you can effectively block Cross-Origin writes.

I think pixelperfect is talking about preflights.

That makes more sense then. Yes, it will make sure not to send authentication data in that case.

Re: Developers don't understand CORS

#86
post #60

Earlier quoted context omitted.

I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...

I think you could implement that with CORS + CSRF tokens (blocking all types of Cross-Origin requests) but the default behaviour is to allow Cross-Origin writes (e.g. with form submissions). See https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... This is why we have CSRF tokens. So that you can effectively block Cross-Origin writes.

I see what you mean, evil.com could still make a request that includes cookies, which is why we need CSRF tokens. But from my understanding, it wouldn't be able to do that in a XMLHttpRequest hidden on the page. It would have to be a request from something like submitting a form which would navigate the user off the page. Is that correct? Of course it doesn't make much difference from a security perspective.

Re: Developers don't understand CORS

#87
post #14

That is because CORS is a kludge to work around the fact that we decided to use session cookies "because developers understand it easily" instead of just re-doing everything. See https://w3c.github.io/webappsec-cors-for-developers/#cors > Enter Cross-Origin Resource Sharing. The challenge when designing CORS was how to enable web applications to request and receive more cross-origin permissions, without exposing exis…

I was hoping someone would mention the warnings that capability people had raised about the CORS proposal. Every time capability security principles have been compromised it turns out badly.

Re: Developers don't understand CORS

#88
post #40

Earlier quoted context omitted.

> In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.

But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon. (Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)

I have read $somewhere that it accumulates in testicles.

And why would I coat surgical instruments?

Edit: Just one article how healthy Teflon is:

https://fortune.com/longform/teflon-pollution-north-carolina...

Re: Developers don't understand CORS

#89
post #64

Earlier quoted context omitted.

On the contrary: CORS is what enables other sites to use your resources (in a way allowed by your policy). It was created because, by default, browsers don't let you do that.

I think what GP commented is a very common misconception. CORS is not the source of the developer trouble (that would be cross-origin restrictions), it is a way around them. But it is perhaps understandable where the confusion comes from... Browsers always mention CORS headers as part of error messages, after all.

+1 - This is a large part of the trouble. It leads to a lot of stuff being defined as the inverse of some other behavior - behavior that the developer does not have control or understanding of.

Re: Developers don't understand CORS

#90
Just tried and I get CORS errors when trying to access localhost in Firefox, also on images via xmlHttp ...

Edit: It works with image elements!

    img = document.createElement("img")
    img.src = "http://localhost:1337/service"
Btw, CORS is a PITA when doing pure web apps, apps that doesn't requre a server. I recently made a RSS reader web app, but had to use a CORS proxy.

I wonder if there is any way I can use an image element to bypass CORS and read RSS xml that way !?

Post reply on HN