75

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!

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Vincent Wasteels
  • 1,568
  • 2
  • 14
  • 21
  • I doubt if you can set null for origin ? Even after keeping origin:*, there are various ways/APIs which can be used to protect your API – Nitishkumar Singh Feb 07 '17 at 18:50

2 Answers2

37

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.

And the author of the Fetch/CORS spec goes into a bit more detail in a related blog posting:

It is completely safe to augment any resource with Access-Control-Allow-Origin: * as long as the resource is not part of an intranet (behind a firewall). In other words, a URL you can fetch from a server on the internet using wget or curl. For your basic web site this encompasses all resources on the site. The Access-Control-Allow-Origin header (part of CORS) tells the browser the resource can be shared.

Even if the resource includes confidential information based on cookies or HTTP authentication data in the request, including the header and sharing the resource is still safe, since the browser will make the request without any cookies or HTTP authentication data. And if the browser did make the request with cookies or HTTP authentication data, it would never share the resource because that would require an additional header, Access-Control-Allow-Credentials, and a different value for the aforementioned header.

So go ahead and safely share your public data with other applications!

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • 2
    thx for your answer, indeed it will allow file:// and data:// but it still prevents other sites from sending request to our API. And the reason why we need this security is again : preventing malicious scripts in websites sending massive requests. Therefore we need the CORS restriction, but isn't it the purpose of CORS ? I mean, it's no security at all accepting ```*``` as allowed origin, right ? – Vincent Wasteels Feb 07 '17 at 23:49
  • 21
    If your API is publicly accessible than you're already essentially allowing requests from anywhereー because all non-browser tools can send as many requests to it as they want. So the only thing you are restricting is browsers. CORS doesn't prevent me from writing a malicious shell script using curl or whatever to send massive requests to your API. Or from running that script from N different machines on a botnet. Etc. So if your biggest concern is getting massive numbers of requests, CORS is not really effective at all in mitigating against that. – sideshowbarker Feb 08 '17 at 01:00
  • bad advice; we have this issue, and allowing any website to cross-reference our exclusive customer videos (solution videos from a quiz TV show) is a no-go, as they are license just for our customer; we don't care about any native/script context, as CORS doesn't protect against that anyway We care about malicious 3rd party websites (read: public accessible easily) leaching our bandwidth or even linking to these videos, and that is one of the usecases CORS was designed for, and why webview-in-app approach is at a disadvantage, without the Access-Control-Allow-Origin: null – hko Jul 11 '19 at 23:52
  • what if I already have ``` Access-Control-Allow-Origin: * ``` but still get that error on mobile (not on web) – Nicoara Jun 22 '22 at 18:24
3

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.

Kevin Christopher Henry
  • 46,175
  • 7
  • 116
  • 102