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 est disponible pour le paramètre Règle d'ouverture multi-origine (COOP): 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 qui démarre dans 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 y faire 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 multi-origines qui ouvrent votre site dans un pop-up.
Définissez unsafe-none, qui autorise toutes les interactions multi-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 ouvreur d'appliquer le COOP. Les principaux cas d'utilisation tels que l'authentification unique et les paiements n'étaient donc 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 de 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 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 certain nombre 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 d'origine identique, un accès complet est accordé.

Rendre votre site isolé multi-origine

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

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 couper 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

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 dans le pop-up et sur votre page principale n'entraînera 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".