Bases des technologies web
Le JavaScript d'une page de https://app.example.com veut envoyer avec fetch une requête POST vers https://api.example.net/orders, avec un corps de type Content-Type: application/json. Quel comportement de CORS est correct dans ce cas ?
- ACORS agit aussi en dehors des navigateurs : sans autorisation du serveur, même un POST envoyé par un outil en ligne de commande est bloqué en chemin sur le réseau
- BLe navigateur envoie d'abord une vérification préalable (preflight) avec la méthode OPTIONS, et n'envoie le véritable POST que si le serveur renvoie l'autorisation dans ses en-têtes
- CLes requêtes vers une autre origine sont toujours envoyées sans vérification, et le JavaScript de la page peut lire la réponse même si le serveur n'y ajoute rien
Afficher la réponse et l'explication
Réponse : B. Le navigateur envoie d'abord une vérification préalable (preflight) avec la méthode OPTIONS, et n'envoie le véritable POST que si le serveur renvoie l'autorisation dans ses en-têtes
CORS est un mécanisme qui permet, dans les limites autorisées par le serveur, les requêtes vers d'autres origines et la lecture de leurs réponses, restreintes par la politique de même origine. Un POST avec Content-Type: application/json est un type de requête qu'un simple envoi de formulaire ne peut pas produire ; le navigateur commence donc par une requête OPTIONS qui indique la méthode et les en-têtes utilisés, afin de vérifier l'autorisation. Si la réponse du serveur ne contient pas d'autorisation comme Access-Control-Allow-Origin, le navigateur n'envoie pas la véritable requête. CORS est une règle appliquée par les navigateurs : le serveur doit donc se protéger par ailleurs, par l'authentification et la vérification des droits.
Continuer : 9 autres questions sur Bases des technologies web