Qu'est-ce que le partage des ressources entre origines multiples ?
Le partage des ressources entre origines multiples (CORS) est un mécanisme d'intégration des applications. La spécification CORS permet aux applications Web clientes chargées dans un domaine particulier d'interagir avec les ressources d'un autre domaine. Cela est utile, car les applications complexes font souvent référence à des API et à des ressources tierces dans leur code côté client. Par exemple, votre application peut utiliser votre navigateur pour extraire des vidéos d'une API de plateforme vidéo, utiliser des polices d'une bibliothèque de polices publique ou afficher des données météorologiques provenant d'une base de données météorologiques nationale. Le CORS permet au navigateur du client de vérifier auprès des serveurs tiers si la requête est autorisée avant tout transfert de données.
Pourquoi le partage des ressources entre origines multiples est-il important ?
Auparavant, lorsque les technologies Internet étaient encore nouvelles, des problèmes de falsification de requêtes intersites (CSRF, cross-site request forgery) se produisaient. Ces problèmes consistaient en l'envoi de fausses requêtes client depuis le navigateur de la victime vers une autre application.
Par exemple, la victime se connectait à l'application de sa banque. Elle était ensuite incitée à charger un site Web externe sur un nouvel onglet du navigateur. Le site Web externe utilisait ensuite les informations d'identification de cookie de la victime et transmettait des données à l'application bancaire tout en se faisant passer pour la victime. Des utilisateurs non autorisés profitaient alors d'un accès involontaire à l'application bancaire.
Pour éviter de tels problèmes CSRF, tous les navigateurs mettent désormais en œuvre la politique de même origine.
Politique de même origine
Aujourd'hui, les navigateurs imposent aux clients d'envoyer des requêtes uniquement à une ressource ayant la même origine que leur URL. Le protocole, le port et le nom d'hôte de l'URL du client doivent tous correspondre au serveur qui reçoit la requête.
Par exemple, comparez les origines des URL suivantes et de l'URL du client http://store.aws.com/dir/page.html.
| URL |
Résultat |
Raison |
| http://store.aws.com/dir2/new.html |
Même origine |
Seul le chemin diffère |
| http://store.aws.com/dir/inner/other.html |
Même origine |
Seul le chemin diffère |
| https://store.aws.com/page.html |
Origine différente |
Protocole différent |
| http://store.aws.com:81/dir/page.html |
Origine différente |
Port différent (http:// est le port 80 par défaut) |
| http://news.aws.com/dir/page.html |
Origine différente |
Hôte différent |
La politique de même origine est donc hautement sécurisée, mais rigide pour les cas d'utilisation authentiques.
Le partage des ressources entre origines multiples (CORS, cross-origin resource sharing) est une extension de la politique de même origine. Vous en avez besoin pour partager des ressources autorisées avec des tiers externes. Par exemple, vous avez besoin du CORS lorsque vous souhaitez extraire des données à partir d'API externes publiques ou autorisées. Vous en avez également besoin si vous souhaitez permettre à des tiers autorisés d'accéder aux ressources de votre propre serveur.
Comment fonctionne le partage des ressources entre origines multiples ?
Dans le cadre d'une communication Internet standard, votre navigateur envoie une requête HTTP au serveur d'applications, reçoit des données sous forme de réponse HTTP et les affiche. Dans la terminologie des navigateurs, l'URL actuelle du navigateur est appelée origine actuelle et l'URL tierce est multi-origines.
Lorsque vous envoyez une requête multi-origines, voici le processus requête-réponse :
- Le navigateur ajoute un en-tête d'origine à la requête avec des informations sur le protocole, l'hôte et le port de l'origine actuelle.
- Le serveur vérifie l'en-tête d'origine actuel et répond avec les données demandées et un en-tête Access-Control-Allow-Origin.
- Le navigateur voit les en-têtes des requêtes de contrôle d'accès et partage les données renvoyées avec l'application cliente.
Sinon, si le serveur ne souhaite pas autoriser l'accès multi-origines, il répond par un message d'erreur.
Exemple de partage de ressources entre origines multiples
Prenons l'exemple d'un site nommé https://news.example.com. Ce site souhaite accéder à des ressources à partir d'une API sur partner-api.com.
Les développeurs de https://partner-api.com configurent d'abord les en-têtes de partage des ressources entre origines multiples (CORS) sur leur serveur en ajoutant new.example.com à la liste des origines autorisées. Pour ce faire, ils ajoutent la ligne ci-dessous au fichier de configuration de leur serveur.
Access-Control-Allow-Origin : https://news.example.com
Une fois l'accès CORS configuré, news.example.com peut demander des ressources auprès de partner-api.com. À chaque requête, partner-api.com répondra avec Access-Control-Allow-Credentials : "true". Le navigateur sait alors que la communication est autorisée et autorise un accès multi-origines.
Si vous souhaitez accorder l'accès à plusieurs origines, utilisez une liste séparée par des virgules ou des caractères génériques tels que * pour accorder l'accès à tout le monde.
Qu'est-ce qu'une requête de pré-vérification CORS ?
En HTTP, les méthodes de requête sont les opérations de données que le client souhaite que le serveur effectue. Les méthodes HTTP courantes incluent GET, POST, PUT et DELETE.
Dans le cadre d'une interaction de partage des ressources entre origines multiples (CORS) normale, le navigateur envoie les en-têtes de requête et de contrôle d'accès en même temps. Il s'agit généralement de requêtes de données GET considérées comme présentant peu de risques.
Toutefois, certaines requêtes HTTP sont considérées comme complexes et nécessitent une confirmation du serveur avant leur envoi réel. Le processus d'approbation préalable est appelé requête de pré-vérification.
Requêtes multi-origines complexes
Les requêtes multi-origines sont complexes si elles utilisent l'un des éléments suivants :
- Méthodes autres que GET, POST ou HEAD
- En-têtes autres que Accept-Language, Accept ou Content-Language
- En-têtes Content-Type autres que multipart/form-data, application/x-www-form-urlencoded ou text/plain
Ainsi, par exemple, les requêtes de suppression ou de modification de données existantes sont considérées comme complexes.
Comment fonctionnent les requêtes de pré-vérification
Les navigateurs créent des requêtes de pré-vérification si elles sont nécessaires. Il s'agit d'une requête OPTIONS comme la suivante.
| OPTIONS /data HTTP/1.1 Origine : https://example.com Access-Control-Request-Method : DELETE |
Le navigateur envoie la demande de pré-vérification avant le vrai message de requête. Le serveur doit répondre à la demande de pré-vérification en fournissant des informations sur les requêtes multi-origines qu'il est prêt à accepter à partir de l'URL du client. Les en-têtes de réponse du serveur doivent inclure les éléments suivants :
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Origin
Un exemple de réponse du serveur est donné ci-dessous.
| HTTP/1.1 200 OK Access-Control-Allow-Headers : Content-Type Access-Control-Allow-Origin : https://news.example.com Access-Control-Allow-Methods : GET, DELETE, HEAD, OPTIONS |
La réponse de pré-vérification inclut parfois un en-tête Access-Control-Max-Age supplémentaire. Cette métrique indique la durée (en secondes) pendant laquelle le navigateur met en cache les résultats de pré-vérification dans le navigateur. La mise en cache permet au navigateur d'envoyer plusieurs requêtes complexes entre les requêtes de pré-vérification. Il n'est pas nécessaire d'envoyer une autre requête de pré-vérification avant l'expiration du délai spécifié par max-age.
Quelle est la différence entre CORS et JSONP ?
JSON with Padding (JSONP) est une technique historique qui permet la communication entre des applications Web s'exécutant sur différents domaines.
Avec JSONP, vous utilisez des balises de script HTML dans la page client. La balise de script charge des fichiers JavaScript externes ou intègre du code JavaScript directement dans une page HTML. Comme les scripts ne sont pas soumis à la politique de même origine, vous pouvez récupérer des données multi-origines grâce au code JavaScript.
Toutefois, les données doivent être au format JSON. De plus, JSONP est moins sécurisé que le partage des ressources entre origines multiples (CORS), car il repose sur la fiabilité du domaine externe pour fournir des données sécurisées.
Les navigateurs modernes ont ajouté certaines fonctionnalités de sécurité, de sorte que les anciens codes contenant du code JSONP ne fonctionneront plus sur eux. Le CORS est la norme Web mondiale actuelle pour le contrôle d'accès entre origines multiples.
Quelles sont les bonnes pratiques d'utilisation du CORS ?
Vous devez suivre les recommandations suivantes lorsque vous configurez le partage des ressources entre origines multiples (CORS) sur votre serveur.
Définissez des listes d'accès appropriées
Il est toujours préférable d'accorder l'accès à des domaines individuels à l'aide de listes séparées par des virgules. Évitez d'utiliser des caractères génériques, sauf si vous souhaitez rendre l'API publique. Dans le cas contraire, l'utilisation de caractères génériques et d'expressions régulières peut entraîner des vulnérabilités.
Supposons, par exemple, que vous écriviez une expression régulière qui accorde l'accès à tous les sites portant le suffixe permitted-website.com. À l'aide d'une seule expression, vous accordez l'accès à api.permitted-website.com et à news.permitted-website.com. Mais vous accordez également par inadvertance l'accès à des sites non autorisés susceptibles d'utiliser des domaines tels que maliciouspermitted-website.com.
Évitez d'utiliser une origine null dans votre liste
Certains navigateurs envoient la valeur null dans l'en-tête de requête pour certains scénarios tels que les requêtes de fichiers ou les requêtes provenant de l'hôte local.
Toutefois, vous ne devez pas inclure cette valeur dans votre liste d'accès. Cela présente également des risques de sécurité, car des requêtes non autorisées contenant des en-têtes null peuvent obtenir l'accès.
Comment AWS peut-il prendre en charge vos exigences en matière de CORS ?
Nombre de nos services intègrent une prise en charge du partage des ressources entre origines multiples (CORS). Vous pouvez ainsi contrôler l'accès multi-origines à vos API et à vos ressources hébergées sur Amazon Web Services (AWS).
Voici quelques services AWS prenant en charge le CORS :
- Amazon Simple Storage Service (Amazon S3) est un service de stockage d'objets proposant des classes de stockage rentables pour tous les cas d'utilisation du stockage de données. Amazon S3 vous permet de créer un document de configuration CORS avec des règles qui identifient les origines que vous autoriserez à accéder à vos données S3, les opérations (méthodes HTTP) que vous prendrez en charge pour chaque origine et d'autres informations spécifiques aux opérations. Vous pouvez ajouter jusqu'à 100 règles à la configuration.
- Amazon API Gateway est un service entièrement géré qui vous permet de créer, publier, gérer, surveiller et sécuriser facilement des API à n'importe quelle échelle. Vous pouvez activer le CORS pour vos API REST en un clic directement dans la console Amazon API Gateway.
Commencez à utiliser les API sur AWS en créant un compte dès aujourd'hui.
Étapes suivantes sur AWS
