2

Reading about CORS(https://spring.io/understanding/CORS) I have got the next doubts:

  1. I thought in CORS the requests were blocked in the client but not in the server but its not true. CORS is a double checked security, both in client and in server, right? How is this checked in server?
  2. Not allowing cross domain requests is used because I dont want to get requests from outside my web application for security reasons.... right?
  3. What about if I am not a browser and I dont implement any security checkings? Lets imagine the domain of my web app is http://mywebapp.com:80 and to get customers the request has to be http://mywebapp.com/customers. I want this last request to be done from the domain http://mywebapp.com:80. If I make a java app to make requests to http://mywebapp.com/customers I could get the answer despite the fact I am not asking this from origin http://mywebapp.com:80, right?

Thanks

fernando1979
  • 1,727
  • 2
  • 20
  • 26

2 Answers2

4

CORS is a double checked security, both in client and in server, right?

No. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS. There is no server-side checking in the CORS protocol, as defined in https://fetch.spec.whatwg.org/.

How is this checked in server?

CORS is not enforced on the server side. Browsers are the sole enforcement point. Servers participate in the protocol simply by setting particular response headers.

Specifically, when a server receives a request, the CORS protocol doesn’t require servers to check whether or not it’s a cross-origin request. Servers may check for the presence of the Origin request header and do something different based on whether it’s found or what its value is, but the CORS protocol doesn’t depend on whether servers do that or not.

Moreover, the CORS protocol definitely doesn’t require servers to block requests or to do anything else specific with requests. Instead, servers simply include the Access-Control-Allow-Origin response header in responses.

Browsers always receive the responses just as they normally would—but if they’re responses for cross-origin requests, then the browsers enforce the CORS protocol by refusing to expose the response the frontend/client-side JavaScript code running in a web app unless the response includes an Access-Control-Allow-Origin response header that indicates the server is opting in to allowing the request cross-origin.

Not allowing cross domain requests is used because I don’t want to get requests from outside my web application for security reasons.... right?

The CORS protocol doesn’t block all requests to any resource. Unless your web resource is running inside an intranet or otherwise behind a firewall of some kind, than any arbitrary non-browser tools/applications can still get to your web resource. CORS doesn’t block them.

CORS isn’t particularly useful for the case of web resources that are already publicly accessible over HTTP without restrictions. Instead CORS is mainly intended for the case of web resources running inside an intranet or otherwise behind a firewall and that are only otherwise protected by IP-based authentication that assumes anybody inside the intranet/firewall is trusted.

The problem CORS is meant to address is, when a user accesses an arbitrary outside web app inside such an intranet/firewall, that web app runs with the same authority as the user. So if web resources inside the intranet/firewall trust the user just based on IP address, then without cross-origin restrictions, any arbitrary outside web app also runs with the same authority/trust as the user.

What about if I am not a browser and I don’t implement any security checkings? … If I make a java app to make requests to http://mywebapp.com/customers I could get the answer despite the fact I am not asking this from origin http://mywebapp.com:80, right?

Yes. The CORS protocol does nothing to restrict that.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • Thanks a lot. Its curious how this "security" is meant to be implemented in clients(browsers) and not in the server and I dont understand why – fernando1979 Apr 08 '17 at 18:32
  • 1
    For more explanation see the last paragraph of the answer at https://stackoverflow.com/questions/34650915/it-seems-the-pre-flight-for-cors-doesnt-make-sense-is-it-a-joke/34668785#34668785 and also the answer at https://stackoverflow.com/questions/20164173/is-cors-considered-bad-practice/20167528#20167528. CORS is implemented in clients (browsers) and not in the server for pretty much the same reason that the [same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) is implemented in browsers and not in servers. – sideshowbarker Apr 08 '17 at 22:13
  • 1
    The answer at https://stackoverflow.com/questions/27583161/confusion-over-how-cross-origin-resource-sharing-cors-works/42072894#42072894 is also a good explanation – sideshowbarker Apr 08 '17 at 22:26
2
  1. The server can check the Origin request header. https://fetch.spec.whatwg.org/#http-responses explains the headers the server can include (and exclude) in more detail.
  2. Yeah, though you need to be wary of XSRF and such. There's many possible attacks on a site.
  3. Yes, that's correct. More importantly, if you do not use HTTPS your data will leak all over.
Anne
  • 7,070
  • 1
  • 26
  • 27
  • About the first question, this is not implemented by default right? About the third question, how to avoid then request from outsiders? – fernando1979 Apr 08 '17 at 15:43
  • 2
    3. That's when you use authentication. Except IP address, based on what would you "trust" your users? – Sergiu Paraschiv Apr 08 '17 at 15:45
  • 1
    "Implemented by default" assumes a particular server implementation and I'm not familiar with all of them. I assume most don't block by default though. – Anne Apr 08 '17 at 15:52