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 les en-têtes CORP adéquats. S'ils peuvent être demandés sans identifiants, vous pouvez désormais activer l'isolation multi-origine en les marquant comme tels.

Eiji Kitamura

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

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

Certaines API Web augmentent le risque d'attaques par canal auxiliaire, comme Spectre : À pour limiter ce risque, les navigateurs offrent un environnement isolé basé sur l'activation, appelé cross-origin isolation (isolation multi-origine). Avec une origine croisée dans un état isolé, 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 s'ils sont activés.

La page Web doit envoyer deux en-têtes HTTP pour permettre 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éfinissez un en-tête Cross-Origin-Resource-Policy à charger.

Difficultés liées à l'activation de l'isolation multi-origine

L'isolation multi-origine renforce la sécurité des pages Web et leur permet activer des fonctionnalités puissantes, difficile. L'une des plus grandes est l'obligation d'activer CORS ou CORP pour tous les types ressources. 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 elles peuvent il n'est pas facile 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, le seul les ressources menacées sont celles demandées avec des identifiants, potentiellement des informations sensibles que l'attaquant ne peut pas charger sur leur vous-même. Cela signifie que les ressources pouvant être demandées sans identifiants disponibles 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. Semblable à require-corp, il peut activer l'isolation multi-origine, mais au lieu de nécessiter un CORP:cross-origin pour les requêtes multi-origines "no-cors", elles sont envoyées sans problème identifiants (par exemple, les cookies).

Vous pourrez activer l'isolation multi-origine en passant par 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 pourra pas répondre avec une une ressource sensible. Le demandeur peut toujours supposer que la réponse n'est traitée contient des informations accessibles au public.

Ceci est également aligné sur les exigences des navigateurs plan d'abandon progressif des cookies tiers.

Démo

Vous pouvez tester 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, au prix d'un changement du 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 pour envoyer des requêtes authentifiées.

Par exemple, même si un document sur https://www.example.com contient en-tête Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> va envoyer 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 peut-il encore être utile pour mon site Web ?

COEP: require-corp ne vous oblige pas à passer manuellement du mode de demande à CORS si des cookies sont nécessaires pour certaines sous-ressources d'origines multiples

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'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 permettra de charger des iFrames multi-origines sans en-tête, mais sans identifiants de connexion.

D'autres navigateurs utiliseront-ils cette fonctionnalité ?

À venir

Deux autres mises à jour sont prévues pour atténuer d'autres difficultés liées à multi-origines:

Personnes qui se sont inscrites à la phase d'évaluation de Chrome pour étendre la modification SharedArrayBuffer en raison de obstacles ci-dessus peuvent se demander quand il prendra fin. À l'origine, nous a annoncé qu'elle prendra fin dans Chrome 96, mais nous avons décidé de reportez-vous à Chrome 106.

Ressources

Photo de Martin Adams sur Désactiver