Interactions avec des fenêtres pop-up sécurisées avec des propriétés de restriction

Bénéficiez de l'isolation multi-origine et de la protection contre les fuites multisites lorsque vous interagissez avec des pop-ups.

Arthur Hemery
GitHub
Maud Nalpas

Une nouvelle valeur pour la règle d'ouverture multi-origine (COOP) est disponible : restrict-properties. Il offre des avantages en termes de sécurité et facilite l'adoption de l'isolation cross-origin tout en permettant à votre site d'interagir avec les pop-ups tiers pour les paiements, l'authentification ou d'autres cas d'utilisation.

Pour commencer à tester restrict-properties, participez à l'essai Origin Trial à partir de Chrome 116.

Pourquoi utiliser restrict-properties ?

Le champ restrict-properties a deux principaux cas d'utilisation :

Éviter les fuites intersites sans provoquer de dysfonctionnements

Par défaut, n'importe quel site Web peut ouvrir votre application dans un pop-up et obtenir une référence à celle-ci.

Un site Web malveillant peut en tirer parti pour effectuer des attaques telles que des fuites intersites. Pour limiter ce risque, vous pouvez utiliser l'en-tête Cross-Origin-Opener-Policy (COOP).

Jusqu'à présent, vos options pour Cross-Origin-Opener-Policy étaient limitées. Vous pouvez :

  • Définissez same-origin,, qui bloque toutes les interactions cross-origin avec les pop-ups.
  • Définissez same-origin-allow-popups, qui bloque toutes les interactions cross-origin qui ouvrent votre site dans un pop-up.
  • Définissez unsafe-none, ce qui autorise toutes les interactions cross-origin avec les pop-ups.

Cela empêchait les sites Web qui devaient être ouverts dans un pop-up et interagir avec leur ouvreur d'appliquer COOP. Cela a laissé des cas d'utilisation clés comme l'authentification unique et les paiements non protégés contre les fuites intersites.

Cross-Origin-Opener-Policy: restrict-properties résout ce problème.

Avec restrict-properties, les propriétés qui peuvent être utilisées pour le décompte des frames et d'autres attaques de fuite de données multisites ne sont pas disponibles, mais la communication de base entre les fenêtres via postMessage et closed est autorisée.

Cela améliore la sécurité d'un site tout en conservant les principaux cas d'utilisation. Exemple :

  • Si vous fournissez un service dans un pop-up, le paramètre Cross-Origin-Opener-Policy: restrict-properties vous protégera contre diverses attaques de fuites intersites. Vous pouvez toujours ouvrir toutes les pages que vous pouviez ouvrir auparavant.
  • Si vous devez accéder à un pop-up d'origine croisée, la définition de Cross-Origin-Opener-Policy: restrict-properties protégera également votre site contre le comptage des iFrames. Vous pourrez ouvrir le même ensemble de pop-ups que ceux que vous pouvez ouvrir aujourd'hui.
  • Si l'ouvreur et l'ouvert définissent l'en-tête et que les pages sont d'origines différentes, le comportement est similaire à celui où l'un d'eux a défini l'en-tête. S'ils sont de même origine, l'accès complet est accordé.

Isoler votre site multi-origine

Pourquoi avons-nous besoin de l'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é basé sur l'activation, appelé isolation multi-origine. Dans un état isolé multi-origine, la page Web peut utiliser des fonctionnalités privilégiées, y compris SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et les timers de haute précision avec une meilleure résolution, tout en isolant l'origine des autres, sauf si elles sont activées.

Jusqu'à présent, pour utiliser ces API, vous deviez définir Cross-Origin-Opener-Policy: same-origin. Toutefois, cela interromprait tout flux pop-up multi-origines dont vous pourriez avoir besoin, comme l'authentification unique et les paiements.

Cross-Origin-Opener-Policy: restrict-properties peut désormais être utilisé à la place de Cross-Origin-Opener-Policy: same-origin pour activer l'isolation multi-origines. Au lieu de rompre la relation avec l'ouvreur, elle la limite simplement au sous-ensemble de communication minimal de window.postMessage() et window.closed.

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

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

ou

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

En savoir plus sur credentialless sur Charger des ressources d'origine croisée sans en-têtes CORP à l'aide de COEP: credentialless

Démo

Essayez différentes options d'en-tête dans cette démonstration d'isolation multi-origine.

Tester l'essai Origin Trial

Pour tester Cross-Origin-Opener-Policy: restrict-properties, inscrivez-vous à l'origin trial.

Prise en charge des navigateurs

Cross-Origin-Opener-Policy: restrict-properties n'est actuellement compatible qu'avec Chrome. D'autres navigateurs participent activement à la discussion sur la standardisation.

Questions fréquentes

Mon site Web doit communiquer avec des pop-ups de même origine. Dois-je utiliser COOP: restrict-properties pour activer l'isolation multi-origine ?

Si vous définissez COOP: restrict-properties à la fois dans le pop-up et sur votre page principale, aucune restriction ne sera appliquée. Si vous le définissez uniquement sur le pop-up ou uniquement sur la page principale, vous empêcherez tout accès aux propriétés autres que postMessage et closed dans l'ouvreur, même si elles sont de même origine.

L'ensemble des propriétés autorisées est-il fixe ?

D'après les commentaires reçus jusqu'à présent, window.postMessage et window.closed devraient suffire pour la majorité des workflows, mais nous envisageons toujours de l'ouvrir à d'autres propriétés. Si vous avez un cas d'utilisation qui ne peut pas être résolu en utilisant uniquement postMessage et closed, laissez vos commentaires sur le fil de discussion sur l'intention d'expérimenter.

Ressources