Cette page a été traduite par l'API Cloud Translation.

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

Obtenez une isolation inter-origine et une protection contre les fuites intersites lorsque vous interagissez avec des pop-ups.

Arthur Hemery

Maud Nalpas

Une nouvelle valeur pour la règle d'ouverture multi-origine (COOP) est disponible: restrict-properties. Elle 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 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 a deux principaux cas d'utilisation:

Empêcher les fuites intersites sans endommager le site
Rendre votre site isolé multi-origine.

Empêcher les fuites intersites sans interruption

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

Un site Web malveillant peut en tirer parti pour effectuer des attaques telles que des fuites entre sites. 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 inter-origines avec les pop-ups.
Définissez same-origin-allow-popups, qui bloque toutes les interactions inter-origines qui ouvrent votre site dans un pop-up.
Définissez unsafe-none, qui autorise toutes les interactions inter-origines avec les pop-ups.

Il était donc impossible pour les sites Web qui doivent être ouverts dans un pop-up et interagir avec leur déclencheur d'appliquer le COOP. Cela laissait des cas d'utilisation clés tels que la connexion 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 pouvant être utilisées pour le comptage des cadres et d'autres attaques de fuites intersites ne sont pas disponibles. Toutefois, 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 préservant les principaux cas d'utilisation. Exemple :

Si vous fournissez un service dans une fenêtre pop-up, le paramètre Cross-Origin-Opener-Policy: restrict-properties vous protège contre un large éventail d'attaques par fuites intersites. Vous pouvez toujours ouvrir toutes les pages que vous pouviez ouvrir auparavant.
Si vous devez accéder à une fenêtre pop-up inter-origine, le paramètre 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 vous pouvez ouvrir aujourd'hui.
Si l'ouverture et l'ouverture définissent l'en-tête et que les pages sont multi-origines, le comportement est semblable à celui d'un seul d'entre eux ayant défini l'en-tête. S'ils sont de même origine, un accès complet est accordé.

Rendre votre site isolé multi-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 isolé multi-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.

Jusqu'à présent, pour utiliser ces API, vous deviez définir Cross-Origin-Opener-Policy: same-origin. Toutefois, cela interromprait tout flux de pop-up inter-origine 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 inter-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 inter-origine avec les deux en-têtes suivants:

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

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

Pour en savoir plus sur credentialless, consultez la page Charger des ressources entre origines multiples 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 inter-origines.

Tester l'essai Origin Trial

Pour tester Cross-Origin-Opener-Policy: restrict-properties, activez l'essai de l'origine.

Prise en charge des navigateurs

Cross-Origin-Opener-Policy: restrict-properties n'est actuellement compatible qu'avec Chrome. D'autres navigateurs sont activement impliqués dans 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 ?

Définir COOP: restrict-properties à la fois sur le pop-up et sur votre page principale n'entraîne aucune restriction. Le définir uniquement sur le pop-up ou uniquement sur la page principale empêche tout accès aux propriétés autres que postMessage et closed dans l'ouvreur, même s'ils 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 les ouvrir à d'autres propriétés. Si vous avez un cas d'utilisation qui ne peut pas être résolu uniquement à l'aide de postMessage et closed, laissez vos commentaires sur le fil de discussion "Intent to Experiment".