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

Bénéficiez d'une isolation multi-origine et d'une protection contre les fuites intersites tout en interagissant avec les pop-ups.

Arthur Hemery
GitHub
Maud Nalpas
Maud Nalpas
X GitHub

Une nouvelle valeur pour Cross-Origin Opener Policy (COOP) est disponible: restrict-properties. Elle offre des avantages en termes de sécurité et facilite l'adoption de l'isolation multi-origine tout en permettant à votre site d'interagir avec des pop-ups tiers pour les paiements, l'authentification ou d'autres cas d'utilisation.

Pour commencer à tester restrict-properties, participez à la phase d'évaluation à partir de Chrome 116.

Pourquoi utiliser restrict-properties ?

restrict-properties présente deux cas d'utilisation principaux:

Éviter les fuites intersites sans dégâts

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 profiter pour effectuer des attaques, telles que des fuites intersites. Pour atténuer 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, afin de bloquer toutes les interactions multi-origines avec des pop-ups.
  • Définissez same-origin-allow-popups pour bloquer toutes les interactions multi-origines qui ouvrent votre site dans un pop-up.
  • Définissez unsafe-none pour autoriser toutes les interactions multi-origines avec les pop-ups.

Il était donc impossible pour les sites Web qui devaient être ouverts dans un pop-up et d'interagir avec leur ouverture pour appliquer COOP. Par conséquent, les principaux cas d'utilisation, tels que l'authentification unique et les paiements, n'étaient pas 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 pouvant être utilisées pour le comptage des frames et d'autres attaques par fuite intersites ne sont pas disponibles, mais la communication de base entre les fenêtres via postMessage et closed est autorisée.

Cela permet d'améliorer 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ège de diverses attaques par fuite intersites. Vous pouvez toujours ouvrir toutes les pages que vous pouviez ouvrir auparavant.
  • Si vous devez accéder à un pop-up multi-origine, la définition de Cross-Origin-Opener-Policy: restrict-properties protège également votre site contre la comptabilisation des iFrames. Vous pourrez ouvrir le même jeu de pop-ups que celui d’aujourd’hui.
  • Si l'ouverture et l'ouverture définissent tous deux l'en-tête et que les pages sont multi-origines, le comportement est semblable à celui de l'une d'entre elles ayant défini l'en-tête. S'ils sont de la même origine, un accès complet est accordé.

Isolez votre site multi-origine

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

Certaines API Web augmentent le risque d'attaques 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 telles que SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et des minuteurs de haute précision avec une meilleure résolution, tout en isolant l'origine des autres, à moins qu'elles ne soient activées.

Jusqu'à présent, pour utiliser ces API, vous deviez définir Cross-Origin-Opener-Policy: same-origin. Cependant, cela interromprait le flux de pop-up multi-origine dont vous pourriez avoir besoin, tel que 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-origine. Au lieu de rompre la relation d'ouverture, il la limite simplement au sous-ensemble de communication minimal de window.postMessage() et window.closed.

Vous pouvez 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

Pour en savoir plus sur credentialless, consultez Charger des ressources multi-origines sans en-têtes CORP à l'aide de COEP: credentialless.

Démonstration

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

Tester la phase d'évaluation

Pour tester Cross-Origin-Opener-Policy: restrict-properties, activez la phase d'évaluation.

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 normalisation.

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 ?

La définition de COOP: restrict-properties à la fois dans le pop-up et sur votre page principale n'entraîne aucune restriction. Si vous ne le définissez que sur la fenêtre pop-up ou sur la page principale, l'accès aux propriétés autres que postMessage et closed dans l'application d'ouverture est impossible, même s'ils ont la même origine.

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

D'après les commentaires reçus jusqu'à présent, il semble que window.postMessage et window.closed suffisent pour la plupart 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 dans le thread "Intent to Testing".

Ressources