Sécurité CORS avec "Access-Control-Allow-Origin: *" (joker)

Question

Nous devons garder notre serveur API sécurisé avec une 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 de permettre toutes les origines : *, mais ce serait une grosse faille de sécurité pour notre API.

Nous construisons nos applications avec Cordova, dont le WebView sert des fichiers locaux et envoie donc : origin: null, pour toutes ses requêtes http(s). Nous réfléchissons donc à ajouter null à l'origine autorisée. C'est mieux, car cela bloquera tous les autres sites web tentant d'accéder à notre API, mais cela permettra à toutes les applications mobiles de l'atteindre...

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

Merci !

Answer 1

Nous devons maintenir la sécurité de notre serveur API avec une restriction CORS : Toutes les solutions que j'ai trouvées me disent de permettre toutes les origines : *, mais cela serait une grande faille de sécurité pour notre API.

Vous n'expliquez pas pourquoi vous avez déterminé que ce serait une faille de sécurité ou pourquoi vous avez besoin d'avoir une politique CORS restrictive. Mais sauf (1) si le serveur API est exécuté dans un intranet ou derrière un pare-feu, et (2) si l'accès aux ressources est par ailleurs restreint uniquement par une authentification IP, alors vous ne gagnez rien en utilisant une politique CORS restrictive. Pour citer la spécification:

Configuration de base sûre du protocole CORS

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

Cependant, autrement l'utilisation de l'en-tête suivante est sûre:

Access-Control-Allow-Origin: *

Même si une ressource expose des informations supplémentaires basées sur des cookies ou une authentification HTTP, en utilisant l'en-tête ci-dessus, celles-ci ne seront pas révélées. Elle partagera la ressource avec des APIs telles que XMLHttpRequest, tout comme elle est déjà partagée avec curl et wget.

Ainsi dit autrement, si une ressource ne peut pas être accédée à partir d'un périphérique aléatoire connecté au web en utilisant curl et wget, l'en-tête susmentionné ne doit pas être inclus. Si elle peut être accédée cependant, il est tout à fait acceptable de le faire.

Et l'auteur de la spécification Fetch/CORS va un peu plus loin dans les détails dans un article de blog connexe:

Il est tout à fait sûr d'augmenter n'importe quelle ressource avec Access-Control-Allow-Origin: * tant que la ressource ne fait pas partie d'un intranet (derrière un pare-feu). En d'autres termes, une URL à partir de laquelle vous pouvez récupérer une ressource sur internet en utilisant wget ou curl. Pour votre site web de base, cela englobe toutes les ressources du site. L'en-tête Access-Control-Allow-Origin (partie de CORS) indique au navigateur que la ressource peut être partagée.

Même si la ressource inclut des informations confidentielles basées sur des cookies ou des données d'authentification HTTP dans la requête, inclure l'en-tête et partager la ressource est toujours sûr, car le navigateur fera la requête sans aucun cookie ou donnée d'authentification HTTP. Et si le navigateur faisait la requête avec des cookies ou des données d'authentification HTTP, il ne partagerait jamais la ressource car cela nécessiterait un en-tête supplémentaire, Access-Control-Allow-Credentials, et une valeur différente pour l'en-tête susmentionné.

Alors allez-y et partagez en toute sécurité vos données publiques avec d'autres applications!

Answer 2

Comme mentionné dans la réponse de sideshowbarker, l'utilisation de Access-Control-Allow-Origin: null ne peut pas être considérée comme sécurisée si l'application peut être ouverte dans un contexte de navigateur. Cela ne présente aucun risque de sécurité pour une application s'exécutant dans sa propre vue web dédiée, cependant.

La politique de même origine (que CORS étend) est conçue pour un type spécifique de menace : un script provenant 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 une WKWebView dédiée, aucun script étranger ne pourra faire une requête à votre serveur en utilisant vos cookies.