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 Cross-Origin Embedder Policy (COEP), qui permet au navigateur de charger des ressources cross-origin qui n'utilisent pas la règle Cross-Origin Resource Policy (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 avons-nous besoin d'une isolation multi-origine ?

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 d'isolation inter-origine, la page Web peut utiliser des fonctionnalités privilégiées, y compris SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et des minuteurs 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 d'isolation inter-origine, toutes les ressources inter-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 est l'obligation 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 d'origines multiples.

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 réalité, les seules ressources à risque sont celles demandées avec des identifiants, car elles incluent potentiellement des informations sensibles que l'attaquant 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 de nécessiter 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 inter-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 authentifiée.

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 nécessite pas de passer manuellement le mode de requête en CORS si des cookies sont nécessaires pour certaines sous-ressources multi-origines.

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 est qu'une discussion est en cours pour autoriser le chargement d'iFrames inter-origines sans ces en-têtes en attribuant aux 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