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

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

Eiji Kitamura

Nous avons lancé la nouvelle valeur COEP (Cross-Origin Embedder Policy) credentialless, qui permet au navigateur de charger des ressources multi-origines qui n'utilisent pas la règle CORP (Cross-Origin Resource Policy) en envoyant une requête sans identifiants, comme les cookies. Cela aide les développeurs à adopter l'isolation multi-origine plus facilement.

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

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

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 multi-origine renforce la sécurité des pages Web et permet d'activer des fonctionnalités puissantes, son déploiement peut s'avérer difficile. L'un des plus grands défis est d'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 ? De 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 par lui-même. Cela signifie que les ressources qui peuvent être demandées sans identifiants sont accessibles au public 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 pour require-corp, il peut permettre l'isolation multi-origine, mais au lieu de nécessiter un en-tête CORP:cross-origin pour les requêtes multi-origines sans contrainte, elles sont envoyées sans identifiants (par exemple, des cookies).

Vous pourrez é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 multi-origine demandé ne peut 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.

Cela correspond également à la planification des navigateurs qui prévoit de supprimer progressivement les cookies tiers.

Démonstration

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 avec identifiants dans un environnement credentialless ?

Absolument, mais cela implique 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>, il vous suffit d'ajouter crossorigin="use-credentials" explicitement pour indiquer au navigateur d'envoyer des requêtes avec identifiants.

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"> enverra une requête avec identifiants.

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

Si vous avez fourni COEP: credentialless, en quoi COEP: require-corp est-il toujours utile pour mon site Web ?

COEP: require-corp ne vous oblige pas à basculer manuellement le mode de requête sur CORS si les cookies sont nécessaires pour certaines sous-ressources multi-origines.

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

Non. Le chargement d'iFrames multi-origines dans un environnement credentialless nécessite toujours les mêmes conditions que 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'une discussion est en cours sur la possibilité de charger des iFrame multi-origines sans ces en-têtes en définissant des iFrames crossorigin="anonymous". Cela permet de charger des iFrame multi-origines sans en-têtes, mais sans identifiants.

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

À venir

Deux mises à jour supplémentaires seront bientôt disponibles pour atténuer les autres problèmes liés à l'isolation multi-origine:

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

Ressources

Photo de Martin Adams sur Unsplash