Aller au contenu

Cross-Origin Resource Sharing

CORS contrôle l’accès du navigateur aux réponses d’une autre origine. Il ne remplace ni la connexion ni la vérification des droits de l’API.

Également appeléCORS
API et contrats de données

Autoriser une autre origine à lire les réponses

Cross-Origin Resource Sharing, ou CORS, est un mécanisme fondé sur les en-têtes HTTP. Le serveur indique depuis quelles autres origines du code exécuté dans le navigateur peut accéder à ses réponses. Une origine comprend protocole, hôte et port. Le navigateur applique la règle ; CORS n’est pas une connexion à l’API.

Distinguer le portail de l’API

Un portail fictif à l’adresse https://portal.example veut lire des données de projets depuis https://api.example/projects. L’API peut autoriser l’origine du portail avec Access-Control-Allow-Origin. Selon la méthode et les en-têtes, le navigateur demande d’abord avec OPTIONS si l’appel réel est autorisé. Cette vérification préalable, appelée preflight, n’a pas lieu pour chaque appel.

Pour d’autres appels, la requête peut déjà atteindre le serveur alors que le navigateur refuse ensuite au script l’accès à la réponse. Une erreur CORS ne prouve donc pas qu’aucune opération n’a eu lieu côté serveur.

Si des cookies de session doivent être envoyés, les paramètres de transmission des informations d’authentification doivent aussi concorder. Ces réponses exigent une origine explicite plutôt que le joker * ; Access-Control-Allow-Credentials intervient également. Les règles du navigateur sur les cookies continuent de s’appliquer. Indépendamment, l’API contrôle identité et droits sur les données demandées.

Sources