Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've never understood why so many people seem to find this confusing. CORS is really simple: if you want third-party sites to be able to access the contents of a given page, you need to send `Access-Control-Allow-Origin: sitename.com` in your response. If you don't send that header, the browser will default to the more secure behavior and just deny access. (Yes, it can get more complicated when you need to allow credentials or access to other HTTP methods but the concept itself is dead-simple.)

Maybe people are just confused about the same-origin policy in general? (Which is not the same thing as CORS, but related.) That's more understandable, but still really easy to explain; if you're signed into a site or have access to a non-public (corporate LAN) site, you _don't_ want every third-party site you visit to have unrestricted access to all your personal data on that site. Therefore browsers, by default, don't allow third-party access to a given origin; simple as that.



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 headers in general. Most developers don't really care about security. They'll do what they're told and like to do a good job overall, but deep down they don't enjoy spending time thinking about how to pwn the app they're building. They just want someone to use what they've built and love it.


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, CORS headers may just seem like an unnecessary annoyance that you don't want to bother learning. "Not allowed access? Why? I don't care about your darned security headers, I just want to make an API request."


You're right.

I forgot about the simple requests angle because 100% of the requests I make are non-simple. I need custom headers and JSON Content-Types. Yet again why this area is so annoying.


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"


CORS as a concept is dead simple. CORS as an implementation in decades old Java services is anything but. I can spend hours trying to get Charles to allow a proxy from localhost development to a backend service.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: