CORS security with mobile apps

Question

We need to keep our API server security with CORS restriction :

Access-Control-Allow-Origin : http://myonlinesite.com 

But we also needs this API to be accessible for our mobile apps (Android+iOs).

All the solutions I found tell me to allow all origin : * , but this would be a big security failure for our API.

We are building our apps with Cordova, which WebView serves local files and therefore sends : origin: null , for all its http(s) requests. So we are thinking about adding null to the allowed origin. It's better, since it will block every other website attempting to fetch our API, but it will allow any mobile apps to fetch it...

Is there any more interesting solution for this ?

Thank you!

Answer 1

So we are thinking about adding null to the allowed origin. It's better, since it will block every other website attempting to fetch our API, but it will allow any mobile apps to fetch it...

Well if you do that then you’re allowing requests from JavaScript code that runs from any non-http/https origin—that includes anybody running anything from a file:// or even data: URL.

So if you are using a restrictive CORS policy for “security” reasons then sending responses with an Access-Control-Allow-Origin: null header sounds like a pretty bad idea.

---

We need to keep our API server security with CORS restriction : All the solutions I found tell me to allow all origin : *, but this would be a big security failure for our API.

You don’t explain why you’ve determined it would be a security failure or why you need to have a restrictive CORS policy at all. But unless (1) the API server is running in an intranet or behind some other kind of firewall, and (2) access to the resources is otherwise restricted only by IP auth, then you don’t gain anything from using a restrictive CORS policy. To quote the spec:

Basic safe CORS protocol setup

For resources where data is protected through IP authentication or a firewall (unfortunately relatively common still), using the CORS protocol is unsafe. (This is the reason why the CORS protocol had to be invented.)

However, otherwise using the following header is safe:

Access-Control-Allow-Origin: * 

Even if a resource exposes additional information based on cookie or HTTP authentication, using the above header will not reveal it. It will share the resource with APIs such as XMLHttpRequest, much like it is already shared with curl and wget.

Thus in other words, if a resource cannot be accessed from a random device connected to the web using curl and wget the aforementioned header is not to be included. If it can be accessed however, it is perfectly fine to do so.

Answer 2

As pointed out in sideshowbarker's answer, using Access-Control-Allow-Origin: null cannot be considered secure if the app can be opened in a browser context. It doesn't present a security risk for an app running in its own dedicated web view, however.

The Same Origin Policy (which CORS extends) is designed for a specific kind of threat: a script from a foreign domain, running in the browser, sending a request to your server that includes your authorization cookies. But if you're running your app in a dedicated WKWebView then there won't be any foreign scripts that are able to make a request to your server using your cookies.