Politique de ressource entre origines (CORP)
La politique de ressource inter-origines est une politique définie par l'en-tête HTTP Cross-Origin-Resource-Policy qui permet aux sites web et aux applications de s'inscrire à une protection contre certaines requêtes provenant d'autres origines (comme celles émises avec des éléments HTML tels que <script> et <img>), afin de réduire les attaques par canal secondaire spéculatif, comme Spectre (angl.), ainsi que les attaques d'inclusion de script inter-sites.
Une CORP est une couche de protection supplémentaire au-delà de la politique de même origine par défaut.
Note :
La politique n'est efficace que pour les requêtes no-cors (angl.), qui sont émises par défaut pour les méthodes/en-têtes autorisés par CORS.
Comme cette politique est exprimée par un en-tête de réponse, la requête réelle n'est pas empêchée — c'est plutôt le navigateur qui empêche le résultat d'être divulgué en supprimant le corps de la réponse.
Utilisation
Note : En raison d'un bogue dans Chrome (angl.), la définition de la politique de ressource inter-origine peut perturber le rendu des PDF, empêchant les visiteur·euse·s de pouvoir lire au-delà de la première page de certains PDF. Faites preuve de prudence lors de l'utilisation de cet en-tête dans un environnement de production.
Les applications web définissent une politique de ressource inter-origine par l'en-tête de réponse HTTP Cross-Origin-Resource-Policy, qui accepte l'une des trois valeurs suivantes :
same-site-
Seules les requêtes provenant du même Site peuvent lire la ressource.
Attention : C'est moins sécurisé qu'une origine. L'algorithme permettant de vérifier si deux origines appartiennent au même site (angl.) est défini dans la norme HTML et implique la vérification du domaine enregistrable.
same-origin-
Seules les requêtes de la même origine (c'est-à-dire, schéma + hôte + port) peuvent lire la ressource.
cross-origin-
Les requêtes provenant de n'importe quelle origine (à la fois même site et inter-site) peuvent lire la ressource. C'est utile lorsque COEP est utilisé (voir ci-dessous).
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
Lors d'une vérification de la politique de ressource inter-origine, si l'en-tête est défini, le navigateur refuse les requêtes no-cors émises depuis une origine/site différent(e).
Relation avec la politique d'intégration inter-origine (COEP)
L'en-tête de réponse HTTP Cross-Origin-Embedder-Policy, lorsqu'il est utilisé sur un document, peut être utilisé pour exiger que les sous-ressources soient soit de la même origine que le document, soit accompagnées d'un en-tête de réponse HTTP Cross-Origin-Resource-Policy pour indiquer qu'elles peuvent être intégrées. C'est pourquoi la valeur cross-origin existe.
Historique
Le concept a été initialement proposé en 2012 (sous la forme d'un en-tête From-Origin), mais ressuscité (angl.) au deuxième trimestre de 2018 et implémenté dans Safari et Chromium.
Au début de 2018, deux vulnérabilités matérielles de type canal auxiliaire connues sous le nom de Meltdown et Spectre ont été divulguées. Ces vulnérabilités permettent la divulgation de données sensibles en raison d'une condition de concurrence survenant dans le cadre de la fonctionnalité d'exécution spéculative, conçue pour améliorer les performances.
La politique de ressource inter-origine a été développée comme un moyen direct pour les sites de bloquer les requêtes inter-origine no-cors indésirables. C'est une défense efficace contre les attaques de type Spectre, car le navigateur supprime le corps des réponses données avant qu'un·e attaquant·e ne puisse y accéder.
Spécifications
| Spécification |
|---|
| Fetch> # cross-origin-resource-policy-header> |
Compatibilité des navigateurs
Voir aussi
- L'en-tête HTTP
Cross-Origin-Resource-Policy