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.
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
(ourequire-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 ?
- Problème de suivi dans Firefox
- Demande de position du Webkit: Aucun signal
- Demande de positionnement W3C TAG : En attente
À 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
- Isoler votre site Web multi-origine avec COOP et COEP
- Pourquoi est-il nécessaire d'être isolé multi-origine pour bénéficier de fonctionnalités puissantes ?
- Guide pour activer l'isolation multi-origine
- Mises à jour de SharedArrayBuffer dans Android 88 et Chrome 92 pour ordinateur
Photo de Martin Adams sur Unsplash