Quand est-il sûr d'activer CORS?
Je développe une API Web JSON/REST, pour laquelle je souhaite spécifiquement que les sites Web tiers puissent appeler mon service via AJAX. Par conséquent, mon service envoie le fameux en-tête CORS:
Access-Control-Allow-Origin: *
Ce qui permet aux sites tiers d'appeler mon service via AJAX. Très bien jusqu'à présent.
Cependant, une sous-section de mon API Web n'est pas publique et nécessite une authentification (des trucs assez standard avec OAuth et un cookie access_token). Est-il sûr d'activer CORS sur cette partie de mon site également ?
D'une part, il serait intéressant que des sites Web tiers puissent avoir des clients ajax qui interagissent également avec cette partie de mon service. Cependant, la raison pour laquelle il existe une même politique d'origine en premier lieu, c'est que cela pourrait être risqué. Vous ne voulez pas qu'un site Web que vous visitez par la suite puisse accéder à votre contenu privé.
Le scénario qui me fait peur est qu'un utilisateur se connecte sur mon API Web, soit sur le site Web, soit via un site Web auquel il fait confiance, et qu'il oublie de se déconnecter. Cela permettra-t-il à tous les autres sites Web qu'il visite par la suite d'accéder à son contenu privé en utilisant la session existante?
Alors mes questions:
- Est-il jamais sûr d'activer CORS sur du contenu non public?
- Si un serveur compatible CORS définit un session_token via un cookie, ce cookie sera-t-il enregistré sous le domaine du serveur CORS ou du serveur de page Web principal?
En réponse à votre deuxième question (si un serveur compatible CORS définit un session_token via un cookie ...?), Le cookie est enregistré sous le domaine du serveur CORS. Le code JS de la page Web principale ne peut pas accéder au cookie, même via document.cookie. Le cookie n'est envoyé au serveur que lorsque le .withCredentials la propriété est définie, et même alors, elle n'est acceptée que lorsque le serveur définit la Access-Control-Allow-Credentials entête.
Votre première question est un peu plus ouverte. C'est assez sûr, mais il existe des moyens de contourner les choses. Par exemple, un attaquant pourrait utiliser une technique d'empoisonnement DNS pour provoquer une demande de contrôle en amont sur le serveur réel, mais envoyer la demande CORS réelle au serveur non autorisé. Voici quelques ressources supplémentaires sur la sécurité CORS:
Enfin, votre préoccupation est de donner à tout accès de site Web à vos données CORS. Afin de vous protéger contre cela, vous ne devez pas utiliser le Access-Control-Allow-Origin: * entête. Au lieu de cela, vous devez renvoyer la valeur d'origine de l'utilisateur. Par exemple:
Access-Control-Allow-Origin: http://www.example.com
Cet en-tête ne permettra que http://www.example.com pour accéder aux données de réponse.
L'intention de CORS est d'autoriser les demandes inter-origines pour les demandes XHR tout en donnant au serveur le pouvoir de spécifier quelle origine a accès à quelle ressource. En particulier, CORS a introduit le champ d'en-tête Origin qui permet au serveur de distinguer les requêtes XHR régulières et possibles. Ce champ d'en-tête ne peut pas être défini ou modifié par l'utilisateur mais est défini par le navigateur pour les demandes XHR.
Donc, si vous avez une API conçue pour être utilisée uniquement par XHR, vous pouvez (et devez) exiger que la demande soit conforme à CORS. Surtout si les requêtes peuvent également modifier l'état de votre serveur, sinon vous seriez vulnérable à CSRF.
Notez que les attaques CSRF sont possibles indépendamment de CORS utilisant d'autres méthodes pour forger des requêtes GET et POST. CORS ne permet d'accéder à la réponse du serveur des requêtes XHR avec JavaScript que si le serveur le permet.