Qu'est-ce que CORS (partage des ressources entre origines) ?

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. Le serveur indique, par des en-têtes de réponse comme Access-Control-Allow-Origin, les origines dont il autorise la lecture. Pour les requêtes qu'un simple envoi de formulaire ne peut pas produire, comme un POST avec Content-Type: application/json, le navigateur envoie d'abord une vérification préalable (preflight) avec la méthode OPTIONS. C'est une règle appliquée par les navigateurs, et non un mécanisme qui protège le serveur contre les attaques.

Nom japonais: CORS(オリジン間リソース共有)

« CORS (partage des ressources entre origines) » apparaît dans 1 questions d'entraînement réparties sur 1 thèmes, dont Bases des technologies web.

Domaine: Bases des technologies web

Requêtes simples et preflight

Les requêtes GET, ou POST dans un format qu'un formulaire peut envoyer (application/x-www-form-urlencoded, multipart/form-data, text/plain), sont envoyées sans vérification, et seul Access-Control-Allow-Origin détermine si le script peut lire la réponse. Pour les requêtes qui utilisent d'autres méthodes, un autre Content-Type ou des en-têtes personnalisés, le navigateur envoie d'abord une requête OPTIONS qui indique, par Access-Control-Request-Method notamment, la méthode et les en-têtes utilisés. Si le serveur renvoie son autorisation, le navigateur envoie la véritable requête.

Envoi de cookies

Pour joindre des cookies à une requête vers une autre origine, le script doit indiquer credentials et le serveur doit renvoyer Access-Control-Allow-Credentials: true. Dans ce cas, Access-Control-Allow-Origin ne peut pas valoir *, qui désigne toutes les origines : il faut écrire précisément l'origine autorisée. Autoriser trop largement les origines expose à la lecture des informations de l'utilisateur par d'autres sites.

Malentendus fréquents

Une erreur CORS indique que le navigateur n'a pas transmis la réponse au script ; la requête elle-même a parfois bien atteint le serveur. De plus, CORS étant une règle appliquée par les navigateurs, il n'empêche pas les requêtes envoyées par des outils en ligne de commande ou par d'autres serveurs. Pour protéger les données du serveur, il faut une authentification et une vérification des droits distinctes.

S'entraîner : questions sur CORS (partage des ressources entre origines)

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.

Questions fréquentes

Peut-on corriger une erreur CORS du côté du client ?

Non. C'est le serveur qui décide des origines autorisées à lire ses réponses : il faut ajouter les en-têtes d'autorisation appropriés aux réponses du serveur de l'API. Pour une API que l'on ne gère pas soi-même, on peut aussi l'appeler en passant par son propre serveur.

Quel est le rapport entre la politique de même origine et CORS ?

La politique de même origine interdit en principe la lecture des réponses d'autres origines, et CORS est le mécanisme qui autorise des exceptions dans les limites explicitement fixées par le serveur. Si le serveur ne renvoie pas d'autorisation CORS, la restriction de la politique de même origine s'applique telle quelle.

« CORS (partage des ressources entre origines) » dans les explications

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.
Le JavaScript d'une page de https://app.example.com veut en…

Questions mentionnant « CORS (partage des ressources entre origines) » (1)

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 ?

Termes associés

Politique de même origine (same-origin policy) API REST Boucle d'événements (event loop) Code d'état HTTP Cookie (cookie HTTP) DOM (Document Object Model) HTTP (Hypertext Transfer Protocol) JSON (JavaScript Object Notation) JWT (JSON Web Token) Méthode HTTP

Retour au glossaire