23

I've been looking on the web regarding CORS, and I wanted to confirm if whatever I made of it is, what it actually is.

Mentioned below is a totally fictional scenario.

I'll take an example of a normal website. Say my html page has a form that takes a text field name. On submitting it, it sends the form data to myPage.php. Now, what happens internally is that, the server sends the request to www.mydomain.com/mydirectory/myPage.php along with the text fields. Now, the server sees that the request was fired off from the same domain/port/protocol

(Question 1. How does server know about all these details. Where does it extract all these details froms?)

Nonetheless, since the request is originated from same domain, it server the php script and returns whatever is required off it.

Now, for the sake of argument, let's say I don't want to manually fill the data in text field, but instead I want to do it programmatically. What I do is, I create a html page with javascript and fire off a POST request along with the parameters (i.e. values of textField). Now since my request is not from any domain as such, the server disregards the service to my request. and I get cross domain error?

Similarly, I could have written a Java program also, that makes use of HTTPClient/Post request and do the same thing.

Question 2 : Is this what the problem is?

Now, what CORS provide us is, that the server will say that 'anyone can access myPage.php'. From enable cors.org it says that

For simple CORS requests, the server only needs to add the following header to its response: Access-Control-Allow-Origin: *

Now, what exactly is the client going to do with this header. As in, the client anyway wanted to make call to the resources on server right? It should be upto server to just configure itself with whether it wants to accept or not, and act accordingly.

Question 3 : What's the use of sending a header back to client (who has already made a request to the server)?

And finally, what I don't get is that, say I am building some RESTful services for my android app. Now, say I have one POST service www.mydomain.com/rest/services/myPost. I've got my Tomcat server hosting these services on my local machine.

In my android app, I just call this service, and get the result back (if any). Where exactly did I use CORS in this case. Does this fall under a different category of server calls? If yes, then how exactly.

Furthermore, I checked Enable Cors for Tomcat and it says that I can add a filter in my web.xml of my dynamic web project, and then it will start accepting it.

Question 4 : Is that what is enabling the calls from my android device to my webservices?

Thanks

ngrashia
  • 9,869
  • 5
  • 43
  • 58
Kraken
  • 23,393
  • 37
  • 102
  • 162

3 Answers3

26

  1. First of all, the cross domain check is performed by the browser, not the server. When the JavaScript makes an XmlHttpRequest to a server other than its origin, if the browser supports CORS it will initialize a CORS process. Or else, the request will result in an error (unless user has deliberately reduced browser security)

  2. When the server encounters Origin HTTP header, server will decide if it is in the list of allowed domains. If it is not in the list, the request will fail (i.e. server will send an error response).

For number 3 and 4, I think you should ask separate questions. Otherwise this question will become too broad. And I think it will quickly get close if you do not remove it.

For an explanation of CORS, please see this answer from programmers: https://softwareengineering.stackexchange.com/a/253043/139479

NOTE: CORS is more of a convention. It does not guarantee security. You can write a malicious browser that disregards the same domain policy. And it will execute JavaScript fetched from any site. You can also create HTTP headers with arbitrary Origin headers, and get information from any third party server that implements CORS. CORS only works if you trust your browser.

Community
  • 1
  • 1
sampathsris
  • 21,564
  • 12
  • 71
  • 98
  • 1
    Should an API which supports CORS execute a request even if the CORS Origin is not a recognised one? I've seen an implementation of CORS where the request is always executed, but the CORS headers on the response are only set by the server IF the Origin is recognised. Not sure if that is good design? – Josh Nov 17 '15 at 15:03
  • @Josh I'm not sure. We'll have to take a thorough look at specs. I guess this warrants a whole new question. – sampathsris Nov 18 '15 at 03:50
  • 1
    @Krumia: actually, it is not CORS that works only if you trust your browser: it is the Same Origin Policy. SOP is the safeguard mechanism, CORS is a convenient way to allow exceptions. You can trust your browser all you want, but if your home banking website has `Access-Control-Allow-Origin` set to `*`, you are gonna have a bad time! – daniel f. Jul 29 '16 at 11:16
  • @sampathsris - what do you mean by an error response? I'm trying out cors with a basic express server and the response sent is 200 (while the browser throws the error, which suggest my payload is still given to the browser of a bad domain) – Jonathan002 Feb 23 '21 at 08:23
1

For question 3, you need to understand the relationship between the two sites and the client's browser. As Krumia alluded to in their answer, it's more of a convention between the three participants in the request.

I recently posted an article which goes into a bit more detail about how CORS handshakes are designed to work.

RobS
  • 9,382
  • 3
  • 35
  • 63
0

Well I am not a security expert but I hope, I can answer this question in one line.

If CORS is enabled then server will just ask browser if you are calling the request from [xyz.com]? If browser say yes it will show the result and if browser says no it is from [abc.com] it will throw error.

So CORS is dependent on browser. And that's why browsers send a preflight request before actual request.

Rajeev
  • 11
  • 1
  • 2