Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

101–110 of 366 posts

Re: Developers don't understand CORS

#101

Post by EGreg »

nathan_long wrote: post #42
EGreg wrote: 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://…

How many people can you have in a single meeting?

It’s up to WebRTC and TURN server. Can be any number in theory. The layouts support 100 people, but each participant would have 100 peer to peer connections.

Perhaps one advantage of Zoom is that it rebalances things onto servers it owns eg via websockets? Is there documentation on this?

Re: Developers don't understand CORS

#102

Post by tgsovlerkhgsel »

csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

CORS stands for Cross-origin resource sharing.

It allows you to make arbitrary HTTP requests across origins, even those that would normally be blocked by the same-origin policy, as long as the server collaborates and allows it, easily and in a secure way.

If you control the server (or can get someone to adjust it, or it already supports it), you can use it to make requests from one website to another, directly from the client.

For example, you can have JS on a site served on www.example.com make calls directly to api.someservice.net, without any kludges.

Any time you think of some contrived proxy solution, JSONP, or other kludges to bypass the same-origin policy, you want CORS.

For non-anonymous APIs, authentication can still be a challenge.

Re: Developers don't understand CORS

#103

Post by iforgotpassword »

klodolph wrote: post #67
therein wrote: 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.)

Studies funded by companies selling Teflon products say 300 degrees. Others conclude it happens at temperatures as low as 200 which you can easily reach while cooking.

Anyways I'm almost always using plain old steel pans and pots. There are very few things that stick so badly I resort to the one Teflon pan I have.

Re: Developers don't understand CORS

#104

Post by bzbarsky »

pixelperfect wrote: post #54
anaphor wrote: 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...

CORS doesn't apply to navigations by default, so anaphor is correct: evil.com can just submit a form to banking.com and it will send the banking.com cookies. This is the whole field of CSRF (cross-site request forgery) mitigation.

CORS was introduced as a way to allow requests that browsers used to not allow at all: things like cross-site XHR in the first instance. Then it was expanded so that requests that are not normally subject to CORS checks (image loads, script loads, stylesheet loads) could opt-in to being subject to them, for various reasons. The default for those loads is still "no CORS". And there still isn't a way to do a navigation subject to a CORS check, even with opt-in.

Disclaimer: I work on Gecko and I've reviewed/implemented parts of the CORS spec.

Re: Developers don't understand CORS

#105

Post by brlewis »

alexchamberlain wrote: post #74

I don't really understand how CORS adds much security wise; it relies on the web browser behaving and respecting your policy...

It protects against attacks where the bad actor is trying to get your browser to do something you don't want. It's OK for browser security measures to rely on web browsers to implement them.

Re: Developers don't understand CORS

#106

Post by disiplus »

untog wrote: post #95
jrudolph wrote: post #80

CORS is a minefield. It doesn't help that the RFC is incredibly dense. I may be totally missing something, but I've repeatedly wondered though if CORS still has its place in times of SPAs that exclusively use xhr + javascript + some sort of auth token talking to a REST API? Consider this argument: CORS basically ensures that browser and servers cooperate to protect end users from a "smart" user agent that happily thr…

> Remove cookies and basic auth headers, what's the point of CORS? The ability to communicate with a domain other than the one your app is running on. For instance, if my site on www.example.com wants to send a POST to www.example2.com, I need CORS. example2.com needs CORS to specify that only example.com is allowed to send a POST to it, not anyoldaddress.com. example2.com could look at the Origin header and refuse c…

yup, i have a signup form on our website and that signup form calls ajax if the email is in use. without cors i would have to use jsonp or some other workaround.

Re: Developers don't understand CORS

#107

Post by anaphor »

naasking wrote: post #87
anaphor wrote: 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.

I was curious to see if there was any record of this and I found some interesting discussions from '09

https://lists.w3.org/Archives/Public/public-webapps/2009AprJ...

Very interesting to read this now.

Re: Developers don't understand CORS

#108

Post by tgsovlerkhgsel »

rezonant wrote: post #56
vbezhenar wrote: post #48

Earlier quoted context omitted.

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Installing trust store certificates for these purposes is asking for trouble. Sure, if the private key is unique per installation it theoretically should be fine, but in reality it can be hard to gather enough entropy to be satisfiably unpredictable, and it's very easy to get this wrong. It's worth noting that there isn't a solid way to limit your CA certificate in the trust-store to the domains you intend to use it…

Can't you just install a specific self-signed certificate for a single domain instead of a CA certificate?

Re: Developers don't understand CORS

#109

Post by euroclydon »

tgsovlerkhgsel wrote: post #102
csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

CORS stands for Cross-origin resource sharing. It allows you to make arbitrary HTTP requests across origins, even those that would normally be blocked by the same-origin policy, as long as the server collaborates and allows it, easily and in a secure way. If you control the server (or can get someone to adjust it, or it already supports it), you can use it to make requests from one website to another, directly from t…

Well... CORS controls whether the browser lets the other page read the response, not issue the request, preflight not withstanding.

Re: Developers don't understand CORS

#110

Post by neuroticfish »

thrusong wrote: post #46

I sort of get it and yet even when I'm sure I've configured it correctly, I'll hit road blocks in Safari, for example, when it works everywhere else as expected. It is such a frustrating experience.

I'm dealing with frustrating CORS issues right now. We have a CDN intercepting outgoing requests from a request resource and nobody here can seem to figure out how to get it to keep allowed headers for OPTIONS method requests.
Post reply on HN