Is CORS required to integrate a REST service with a web application?

Question

I have that self-hosted RESTful messaging service with authorization, SSL and more good stuff that goes with it. Now, I would like to consume that service, so I need an UI. Usually (for cross-platforms sake) I tend to develop ASP.NET MVC web application, but this time I'm not sure how to proceed.

However, I have some ideas:

1. If there are two decoupled applications - a web application and a REST service - there will have to be CORS enabled on the client.

2. If there is a web application that somehow uses some proxy (forwarder?) to get to the REST service, I don't need CORS. But I don't know how exactly that should be done in MVC.

Another thing - I would really prefer this being decoupled, so I don't want a third option to be stuffing both things into one sack.

I am a bit disappointed with what google says on the topic. There should obviously be more information, or I don't know how to look for it.

My questions are:

1. Should I go with choice #1 or #2?
2. About choice #2, is that practical and is there a best practice solution?
3. Is there a third choice I'm missing here?

• Bogdan: And what is your question?
• Robert Harvey: I've updated the title of your post with the question that I think you're trying to ask. Feel free to change it to something else if that's not the actual question.

Answer 1

You need CORS only if the client for your REST service is located inside the browser (something like a SPA, for example) and only if the client is on a different domain than that of your REST service.

If your web application is the client or if the web application is just a proxy to the REST service, then you don't need CORS.

Now, choosing a solution really depends on the problem you are trying to solve. As you have it, there are 3 possible solutions:

1. Having a SPA that connects directly to the REST service. You need CORS for that if you have the SPA on a different domain (a SPA comes with other issues too).You might get away from using CORS if you have the SPA on www.domain.com/app and the REST service exposed as www.domain.com/api for example, but you can only have one client in this way.

2. Having mostly a SPA again but deployed from a web application that uses the REST service. For using a web application as a proxy in this way you don't need CORS because you are on the same domain. Basically you recreate the HTTP operations in the Asp.NET MVC application (well... it won't be MVC since you will have just the controller).

3. Having a classic web application that connects to the REST service and serves server side pages to client browser requests. You have a full Asp.NET MVC app here, with the REST service being accessed most probably as a repository of some sort.

Like I said, choosing depends on the problem you are trying to solve. Think well before you chose because going back and doing it again, in another way, might be really painfull.

• ASA: I believe that besides the host, the port also needs to be the same: stackoverflow.com/questions/19966707/cors-error-on-same-domain
• Bogdan: @Traubenfuchs: Yes, that's right. All of protocol, host, and port must match to be considered the "same origin".

Answer 2

CORS is not required in any case. But incorporating additional building block like a proxy in place of a well established standard and approach like CORS is a violation of Occam's razor and KISS principle IMHO. That's the reason why I would follow with CORS if I were you. RESTful web services are, by design, decoupled from its clients so the 3rd option you are considering is out of the discussion here. You mentioned the service you are going to consume is protected by some authorization and authentication layer. Assuming it was designed to be publicly available in mind, and it's already protected by an additional authentication and authorization layer, then you can simply use wildcard same-origin policy approach:

A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. — Wikipedia