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

Demystifying CORS

frontendian.co

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Demystifying CORS

#21

Post by diek00 »

zeusly wrote: post #12
sonnyblarney wrote: post #10

What I find perplexing is that for this and every other web technology, there doesn't seem to be a central comprehensive resource that explains it all in great detail. It's like we have to pick things up as we go along, from tidbits and articles here and there, not of it complete or comprehensive, and often there'll be little mistakes or misleading bits.

I think MDN is doing a great job of becoming the go-to resource for everything: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

I agree, excellent explanation of all things web. One recent example that stands out, their Django tutorial puts the official Django tutorial to shame imo

Re: Demystifying CORS

#22

Post by mabufo »

paol wrote: post #4

This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…

CORS allows you to whitelist what domains you accept certain requests from. This is a good thing.

One thing I never understood really is why a webpage is able to load scripts from a different domain. That will I suppose remain a mystery to me forever. Imagine how many fewer ads and junk we might see.

Re: Demystifying CORS

#23

Post by rrosen326 »

ThePhysicist wrote: post #5
paol wrote: post #4

This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…

CORS was designed to mitigate e.g. the following attack: * You are logged at with service X, which uses a Cookie to store your authentication code. * Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account. * You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be ac…

Aha - I think this answers something that has always confused me.

If I create a micro-service and want to protect it, CORS doesn't help me very much. I still need some sort of authentication mechanism (perhaps provided in a cookie) to say, "yes - this request is permitted."

CORS helps protect that authentication mechanism within a browser.

Is that about right?

Re: Demystifying CORS

#24

Post by dlhavema »

mabufo wrote: post #22
paol wrote: post #4

This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…

CORS allows you to whitelist what domains you accept certain requests from. This is a good thing. One thing I never understood really is why a webpage is able to load scripts from a different domain. That will I suppose remain a mystery to me forever. Imagine how many fewer ads and junk we might see.

this is a cool feature but the actual whitelist has to be held internally, in responding to an OPTIONS request, you can respond with * or concrete domain name. you can't return something like "www.example.com, www.foo.com" .

if you want to whitelist multiple domains you have to resolve this server side and check the requesting domain against your list of accepted domains.

this took me a little while to figure out.

Re: Demystifying CORS

#25

Post by jakelazaroff »

rrosen326 wrote: post #23
ThePhysicist wrote: post #5

Earlier quoted context omitted.

CORS was designed to mitigate e.g. the following attack: * You are logged at with service X, which uses a Cookie to store your authentication code. * Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account. * You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be ac…

Aha - I think this answers something that has always confused me. If I create a micro-service and want to protect it, CORS doesn't help me very much. I still need some sort of authentication mechanism (perhaps provided in a cookie) to say, "yes - this request is permitted." CORS helps protect that authentication mechanism within a browser. Is that about right?

Yup! CORS is meant to protect a service's users, not the service itself. Services should always authenticate/distrust user input/etc; no client-side technology makes that unnecessary.

Re: Demystifying CORS

#26

Post by TurningCanadian »

Ajedi32 wrote: post #17
3pt14159 wrote: post #14

Earlier quoted context omitted.

People get confused because it's two requests, first the options one, then the normal one. Their web frameworks are largely built on single connection handling, but because CORS isn't used by many people it's often a tacked on afterthought. For example, in Rails they briefly made it impossible to manually handle Options requests (something that I fixed). Then there is the core weirdness of subdomains and security hea…

There aren't two requests; at least not normally. Preflight requests are only needed if you want to send unusual headers in your request or use HTTP methods other than GET or POST. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl... But you make a good point about developers not caring about security. If I look at it from that perspective it totally makes sense. If you don't have any reason to care, C…

From the page you linked to, it depends on the MIME type of the POST

> "[...] for HTTP methods other than GET, or for POST usage with certain MIME types"

Re: Demystifying CORS

#27

Post by niftich »

paol wrote: post #4

This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…

Browsers, by consensus, adhere to a security approach called 'same-origin policy', which limits the situations that data from one context can be read by another context. CORS is a targeted way of relaxing some of those restrictions, so that you can obtain data from another context if the source endpoint consents.

Of course there are other HTTP clients. Anyone can write one, and they're probably not going to adhere to the same-origin policy. CORS, therefore, isn't really a security feature in the same vein as, say, CSRF-prevention tokens; rather, it's a language to communicate to a 'same-origin policy'-compliant user-agent to allow some cross-origin data sharing, lessening the need to pipe everything through script tags (JSONP) or one's own proxy.

Re: Demystifying CORS

#28

Post by jjnoakes »

ThePhysicist wrote: post #5
paol wrote: post #4

This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…

CORS was designed to mitigate e.g. the following attack: * You are logged at with service X, which uses a Cookie to store your authentication code. * Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account. * You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be ac…

If you need CSRF tokens for forms, etc, then what does CORS give you above CSRF tokens?

Re: Demystifying CORS

#29

Post by niftich »

jjnoakes wrote: post #28
ThePhysicist wrote: post #5

Earlier quoted context omitted.

CORS was designed to mitigate e.g. the following attack: * You are logged at with service X, which uses a Cookie to store your authentication code. * Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account. * You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be ac…

If you need CSRF tokens for forms, etc, then what does CORS give you above CSRF tokens?

CSRF tokens are a popular mitigation against CSRF, where CSRF is a "vulnerability" that arises in part when a user is tricked into asking its user-agent to make a request the user didn't actually intend.

This is particularly likely to happen in web browsers because they support hyperlinks or image tags to arbitrary destinations (which turn into GET requests), and support form auto-submission to arbitrary targets (which turn into POST requests). The request will often inherit the user's legitimate authentication posture on the target site, because all cookies and headers are also sent, riding on the user's existing session. Despite all this unpleasantness, a web browser adheres to the 'same-origin policy', which prevents the response from CSRF attack to be made known to the originating site. Given the predominance of interactive user-agents that support the same-origin policy, it's not very likely to be tricked into a CRSF with a user-agent that doesn't adhere to the same-origin policy.

CORS isn't a security feature per se, it's a mechanism to selectively relax the same-origin policy to obtain a response from a different source, if that source consents.

Re: Demystifying CORS

#30

Post by matharmin »

bzbarsky wrote: post #20
matharmin wrote: post #16

Where CORS got complicated for me was adding custom request and/or response headers to a cross-origin GET request. Different browsers handles this differently. For example, Safari would make a pre-flight request if certain request headers are sent, while Chrome would just send it. And Chrome would not make a pre-flight request, and won't populate the "Origin" request header, but will then drop "unknown" response head…

That's really odd. There are shared tests for all this stuff, and browsers should really be doing it identically. Did you happen to report bugs on this to browsers? If not, do you happen to have a link to a page that shows the behavior difference?

Nope, never got around to debug in depth. Will do that when I have some time again.
Post reply on HN