Charger des ressources multi-origines sans en-têtes CORP à l'aide de COEP: sans identifiants

Les ressources multi-origines diffusées par des tiers n'incluent souvent pas d'en-têtes CORP appropriés. Si elles peuvent être demandées sans identifiants, vous pouvez désormais activer l'isolation inter-origine en les marquant comme telles.

Eiji Kitamura

Nous avons publié la nouvelle valeur credentialless de la règle d'intégration inter-origine (COEP) qui permet au navigateur de charger des ressources inter-origines qui n'utilisent pas la règle de ressources inter-origines (CORP), en envoyant une requête sans identifiants, tels que des cookies. Cela permet aux développeurs d'adopter plus facilement l'isolation inter-origine.

Pourquoi l'isolation multi-origine est-elle nécessaire ?

Certaines API Web augmentent le risque d'attaques par canal auxiliaire telles que Spectre. Pour atténuer ce risque, les navigateurs proposent un environnement isolé activable appelé isolation multi-origine. Avec un état isolé multi-origine, la page Web peut utiliser des fonctionnalités privilégiées telles que SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et des minuteurs de haute précision avec une meilleure résolution, tout en isolant l'origine des autres, sauf s'ils sont activés.

La page Web doit envoyer deux en-têtes HTTP pour activer l'isolation multi-origine:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Avec un état isolé multi-origine, toutes les ressources multi-origines doivent être diffusées avec CORS ou définir un en-tête Cross-Origin-Resource-Policy à charger.

Défis liés à l'activation de l'isolation multi-origine

Bien que l'isolation inter-origine offre aux pages Web une meilleure sécurité et la possibilité d'activer des fonctionnalités puissantes, son déploiement peut s'avérer difficile. L'un des plus grands défis consiste à activer CORS ou CORP pour toutes les ressources multi-origines. Les ressources sans ces en-têtes ne seront pas chargées par le navigateur sur une page isolée multi-origine.

Ces ressources multi-origines sont généralement diffusées par des tiers pour lesquels il peut être difficile d'ajouter les en-têtes nécessaires.

Mais que se passe-t-il si nous savons que la ressource est suffisamment sûre pour être chargée ? En fait, les seules ressources à risque sont celles demandées avec des identifiants, car elles peuvent inclure des informations sensibles que le pirate informatique ne peut pas charger lui-même. Cela signifie que les ressources pouvant être demandées sans identifiants sont disponibles publiquement et peuvent être chargées en toute sécurité.

credentialless à la rescousse

C'est là que COEP: credentialless entre en jeu. credentialless est une nouvelle valeur pour l'en-tête Cross-Origin-Embedder-Policy. Comme require-corp, il peut activer l'isolation multi-origine, mais au lieu d'exiger un en-tête CORP:cross-origin pour les requêtes multi-origines sans CORS, elles sont envoyées sans identifiants (par exemple, des cookies).

Vous pouvez également activer l'isolation multi-origine avec les deux en-têtes suivants:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Cela signifie que le serveur inter-origine demandé ne pourra pas répondre avec une ressource sensible, et le demandeur peut toujours supposer que la réponse ne contient que des informations accessibles au public.

Cette décision s'inscrit également dans le plan des navigateurs visant à abandonner progressivement les cookies tiers.

Démo

Vous pouvez essayer différentes options d'en-tête dans cette démonstration : https://cross-origin-isolation.glitch.me.

Questions fréquentes

Puis-je envoyer une requête authentifiée dans un environnement credentialless ?

Absolument, au prix de modifier le mode de la requête pour exiger une vérification CORS sur la réponse. Pour les balises HTML telles que <audio>, <img>, <link>, <script> et <video>, ajoutez simplement crossorigin="use-credentials" explicitement pour indiquer au navigateur d'envoyer des requêtes authentifiées.

Par exemple, même si un document sur https://www.example.com comporte un en-tête Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> envoie une requête avec identifiants.

Pour l'API fetch(), vous pouvez utiliser request.mode = 'cors'.

COEP: require-corp est-il toujours utile pour mon site Web ?COEP: credentialless

COEP: require-corp ne vous oblige pas à basculer manuellement le mode de requête vers CORS si des cookies sont nécessaires pour certaines sous-ressources d'origines multiples.

Puis-je également charger des iFrames multi-origines sans en-têtes spéciaux dans un environnement credentialless ?

Non. Le chargement d'éléments iframe inter-origines dans un environnement credentialless nécessite toujours les mêmes conditions que pour require-corp. Les documents iFrame doivent être diffusés avec deux en-têtes:

  • Cross-Origin-Embedder-Policy: credentialless (ou require-corp)
  • Cross-Origin-Resource-Policy: cross-origin

La bonne nouvelle, c'est qu'il existe une discussion en cours sur la possibilité de charger des iFrames multi-origines sans ces en-têtes en attribuant des iFrames crossorigin="anonymous". Cela permet de charger des iFrames multi-origines sans en-têtes, mais sans identifiants.

Cette fonctionnalité sera-t-elle adoptée par d'autres navigateurs ?

Étapes suivantes

Deux autres mises à jour sont prévues pour atténuer d'autres problèmes liés à l'isolation multi-origine:

Les personnes qui se sont inscrites à l'essai Chrome pour étendre la modification de SharedArrayBuffer en raison des obstacles ci-dessus peuvent se demander quand il prendra fin. Nous avions initialement annoncé qu'elle serait arrêtée dans Chrome 96, mais nous avons décidé de la repousser à Chrome 106.

Ressources

Photo de Martin Adams sur Unsplash