Sécurité CORS avec les applications mobiles

Question

Nous devons maintenir la sécurité de notre serveur API avec la restriction CORS :

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

Mais nous avons également besoin que cette API soit accessible pour nos applications mobiles (Android+iOs).

Toutes les solutions que j'ai trouvées me disent d'autoriser toutes les origines : * mais cela constituerait un gros défaut de sécurité pour notre API.

Nous construisons nos applications avec Cordova, dont le WebView sert des fichiers locaux et envoie donc des fichiers : origin: null pour toutes ses requêtes http(s). Nous envisageons donc d'ajouter null à l'origine autorisée. C'est mieux, car cela bloquera tout autre site web tentant de récupérer notre API, mais cela permettra à toute application mobile de la récupérer...

Existe-t-il une solution plus intéressante pour cela ?

Merci !

Answer 1

Nous envisageons donc d'ajouter null à l'origine autorisée. C'est mieux, car cela bloquera tout autre site web tentant de récupérer notre API, mais cela permettra à toute application mobile de la récupérer...

Si vous faites ça, vous autorisez les requêtes du code JavaScript qui s'exécute à partir de tout une origine non-http/https, ce qui inclut toute personne exécutant quelque chose à partir d'une file:// ou même data: URL.

Ainsi, si vous utilisez une politique CORS restrictive pour des raisons de "sécurité", l'envoi de réponses avec un nom de fichier Access-Control-Allow-Origin: null L'en-tête semble être une assez mauvaise idée.

---

Nous avons besoin de maintenir la sécurité de notre serveur API avec une restriction CORS : Toutes les solutions que j'ai trouvées me disent d'autoriser toutes les origines : * mais cela constituerait un gros défaut de sécurité pour notre API.

Vous n'expliquez pas pourquoi vous avez déterminé qu'il s'agirait d'un échec de sécurité ou pourquoi vous devez avoir une politique CORS restrictive. Mais à moins que (1) votre serveur Web fonctionne dans un intranet ou derrière un autre type de pare-feu, et (2) que l'accès aux ressources soit autrement limité uniquement par l'authentification IP, alors vous ne gagnez rien à utiliser une politique CORS restrictive. Pour citer la spécification :

Configuration de base du protocole CORS sécurisé

Pour les ressources dont les données sont protégées par une authentification IP ou un pare-feu (ce qui est malheureusement encore relativement courant), l'utilisation du protocole CORS n'est pas sûre. (C'est la raison pour laquelle le protocole CORS a dû être inventé).

En revanche, l'utilisation de l'en-tête suivant est sans danger :

Access-Control-Allow-Origin: *

Même si une ressource expose des informations supplémentaires basées sur un cookie ou une authentification HTTP, l'utilisation de l'en-tête ci-dessus ne les révélera pas. Il partagera la ressource avec des API telles que XMLHttpRequest comme il est déjà partagé avec curl et wget .

Ainsi, en d'autres termes, si une ressource n'est pas accessible à partir d'un appareil aléatoire connecté au web à l'aide de curl et wget l'en-tête susmentionné ne doit pas être inclus. Toutefois, s'il est possible d'y accéder, il est parfaitement possible de le faire.

Answer 2

Comme indiqué dans la réponse de sideshowbarker, l'utilisation de Access-Control-Allow-Origin: null ne peut être considérée comme sûre si l'application peut être ouverte dans le contexte d'un navigateur. En revanche, il n'y a pas de risque de sécurité pour une application qui s'exécute dans sa propre vue web dédiée.

La politique de la même origine (que CORS étend) est conçue pour un type spécifique de menace : un script d'un domaine étranger, s'exécutant dans le navigateur, envoyant une requête à votre serveur qui inclut vos cookies d'autorisation. Mais si vous exécutez votre application dans un serveur dédié à l'application WKWebView alors il n'y aura pas de scripts étrangers capables de faire une demande à votre serveur en utilisant vos cookies.