Quand votre page ouvre une autre fenêtre, ou qu’elle est elle-même ouverte par un site tiers, un lien invisible se crée entre les deux : chacune garde une référence vers l’autre et, dans certaines conditions, elles partagent même un espace mémoire. Ce partage, pratique à l’origine, ouvre la porte à des attaques sophistiquées exploitant les failles matérielles des processeurs. La Cross-Origin-Opener-Policy, abrégée en COOP, est l’en-tête qui rompt ce lien et place votre page dans un groupe de navigation isolé. Voyons ce que recouvre cette politique, comment le navigateur l’applique entre les fenêtres, ce qu’elle protège réellement, et comment la déployer sans casser les intégrations qui reposent sur l’ouverture de fenêtres.

Le COOP (Cross-Origin-Opener-Policy), définition d’une barrière d’isolation

La Cross-Origin-Opener-Policy est un en-tête HTTP qui contrôle le lien entre votre page et les fenêtres ouvertes vers ou depuis d’autres origines. Elle répond à une catégorie de failles de sécurité d’un site liées au partage de contexte entre onglets, en permettant à une page d’exiger de ne plus rien partager avec l’extérieur.

Le contexte de navigation partagé

Par défaut, une fenêtre ouverte via un lien ou un script conserve un accès à celle qui l’a ouverte, à travers la référence window.opener. Ce mécanisme permet des échanges légitimes, mais il crée aussi un canal de communication entre origines que des pages malveillantes peuvent tenter d’exploiter pour observer ou influencer leur ouvreur. Plus subtilement, deux documents de même groupe peuvent finir par partager un même processus, donc une même mémoire physique. C’est précisément ce partage de mémoire entre pages qui rend possibles les attaques par canal auxiliaire, où l’on déduit des informations sensibles en mesurant des temps d’accès plutôt qu’en lisant directement les données. Ce comportement par défaut date d’une époque où le web était plus simple et les onglets moins nombreux. Aujourd’hui, une même session empile parfois des dizaines de fenêtres d’origines variées, et ce maillage implicite entre pages devient une surface d’exposition que peu d’éditeurs maîtrisent réellement, faute d’en connaître l’existence. Prendre conscience de ce maillage est déjà un progrès. Beaucoup d’équipes raisonnent page par page, sans soupçonner que leurs onglets forment, du point de vue du navigateur, un ensemble interconnecté. Visualiser ce réseau invisible entre fenêtres aide à comprendre pourquoi une politique d’isolation a du sens, et pourquoi son absence laisse, par défaut, une porte entrouverte que rien ne signale dans le fonctionnement quotidien.

Ce que le COOP verrouille

Activer une politique COOP stricte demande au navigateur de placer la page dans son propre groupe de navigation, séparé de toute origine différente. Concrètement, le lien window.opener est coupé : une fenêtre ouverte ne peut plus remonter vers la vôtre, et inversement, ce qui supprime le canal d’échange involontaire. Cette séparation s’accompagne d’une mise à l’écart au niveau des processus du navigateur. En garantissant que la page ne cohabite plus en mémoire avec des contenus d’autres origines, le COOP retire le terrain sur lequel s’appuient les attaques les plus avancées, tout en clarifiant les frontières entre votre site et le reste du web. On peut se représenter le COOP comme une cloison étanche posée entre votre page et le reste. Une fois en place, ce qui se passe de l’autre côté ne peut plus ni observer ni influencer votre contenu. Cette frontière nette entre origines remplace un voisinage flou par une séparation explicite, bien plus simple à raisonner pour qui conçoit un site sûr.

Comment fonctionne l’en-tête COOP entre les fenêtres

L’en-tête Cross-Origin-Opener-Policy accepte quelques valeurs seulement, mais le choix entre elles détermine à la fois le niveau de protection et la compatibilité avec vos fonctionnalités. C’est souvent là que se joue la réussite d’un déploiement. Ce sujet complète notre précédent article : HTTP Strict Transport Security (HSTS).

Les valeurs same-origin, same-origin-allow-popups et unsafe-none

La valeur same-origin est la plus protectrice : elle isole la page de toute origine différente, y compris des fenêtres qu’elle ouvre. La valeur same-origin-allow-popups assouplit légèrement la règle en conservant le lien vers les popups que la page ouvre elle-même, ce qui sauve de nombreuses intégrations de paiement ou de connexion. À l’opposé, unsafe-none correspond au comportement historique, sans aucune isolation. Le tableau plus bas résume ces options, mais l’idée à retenir est de viser la valeur la plus stricte que vos usages tolèrent, car c’est elle qui offre la meilleure étanchéité entre origines sans sacrifier les fonctions essentielles. Le bon réflexe consiste à partir de la valeur la plus stricte, puis à n’assouplir qu’en cas de besoin avéré. Beaucoup de sites découvrent qu’ils n’ouvrent en réalité aucune fenêtre tierce critique et peuvent viser l’isolation totale sans rien perdre. Adopter cette démarche du plus fermé vers le plus ouvert donne des configurations nettement plus sûres. Ce raisonnement vaut aussi pour la lisibilité du code sur le long terme. Une politique stricte documentée explicitement vaut mieux qu’un comportement par défaut que personne n’a choisi consciemment. Le jour où un développeur reprend le projet, il lit une intention claire plutôt que de deviner des effets implicites. Cette clarté des règles de sécurité réduit les erreurs lors des évolutions, souvent introduites par méconnaissance de l’existant. Voici les valeurs possibles de l’en-tête COOP et leur effet.

COOP, COEP et l’isolation cross-origin

Le COOP travaille rarement seul. Associé à son cousin le Cross-Origin-Embedder-Policy (COEP), il déclenche un état spécial appelé isolation cross-origin, dans lequel la page obtient des garanties de sécurité supplémentaires. C’est cette combinaison qui débloque certaines fonctionnalités puissantes du navigateur, comme les minuteries de haute précision ou la mémoire partagée. Cette articulation a une conséquence pratique : si votre site a besoin de ces capacités avancées, le COOP devient un prérequis et non une simple option. Comprendre que les deux en-têtes forment un duo indissociable évite bien des configurations à moitié actives, où l’on attend une isolation que le navigateur n’accorde jamais faute d’avoir réuni les deux conditions. Cette dépendance explique aussi pourquoi certaines fonctionnalités refusent de s’activer malgré une configuration en apparence correcte. Tant que les deux en-têtes ne sont pas réunis, le navigateur maintient la page hors de l’état d’isolation renforcée, et les capacités avancées restent verrouillées. Diagnostiquer ce duo manquant épargne de longues recherches.

Pourquoi le COOP renforce l’isolation de votre site

Adopter une Cross-Origin-Opener-Policy modifie la façon dont le navigateur web cloisonne vos pages, en passant d’un modèle où tout communique par défaut à un modèle où chaque origine reste dans son couloir. Ce changement réduit en profondeur la surface offerte aux attaques inter-fenêtres.

Se prémunir des attaques par canal auxiliaire

Les vulnérabilités matérielles de type Spectre ont montré qu’un script pouvait, dans certaines conditions, lire des données présentes dans la mémoire d’un même processus, même sans accès direct. En garantissant que la page ne partage plus son processus avec d’autres origines, le COOP retire la matière première de ces attaques, qui n’ont alors plus rien à observer. Cette protection est d’autant plus précieuse qu’elle agit à un niveau très bas, là où les défenses applicatives classiques ne peuvent rien. On ne corrige pas une faille de processeur avec un filtre côté serveur ; on l’évite en cloisonnant les contextes d’exécution, ce que le COOP fait précisément en séparant les groupes de navigation. Il serait tentant de juger ces attaques trop théoriques pour s’en soucier. C’est oublier qu’une faille de processeur touche, par nature, un parc immense de machines, et que les techniques d’exploitation se diffusent avec le temps. Se protéger en amont, c’est ne pas dépendre du calendrier des correctifs matériels, toujours plus lents que la créativité des attaquants. Cette logique de défense en profondeur mérite d’être expliquée aux décideurs, car son bénéfice n’est pas immédiatement visible : on ne constate jamais l’attaque qui n’a pas eu lieu. Présenter le COOP comme une assurance contre des menaces de bas niveau, peu probables mais aux conséquences sévères, permet de justifier l’effort de configuration auprès d’interlocuteurs habitués à raisonner en risque et en couverture.

Reprendre le contrôle des fenêtres ouvertes

En coupant la référence window.opener, le COOP neutralise aussi les abus où une page ouverte manipule la fenêtre d’origine, par exemple pour la rediriger en douce vers une copie frauduleuse pendant que l’internaute regarde ailleurs. Reprendre la main sur ces liens, c’est fermer une voie de manipulation discrète souvent négligée. Pour un site qui ouvre des fenêtres vers des services externes, cette maîtrise apporte aussi de la clarté. On sait précisément ce que chaque fenêtre peut et ne peut pas faire vis-à-vis des autres, ce qui transforme un comportement par défaut flou en frontières explicites et documentées entre votre site et les tiers qu’il sollicite. Cette reprise de contrôle simplifie le raisonnement de sécurité au quotidien. Plutôt que de se demander quelle fenêtre peut agir sur quelle autre, on part d’un principe clair : rien ne traverse, sauf ce que l’on autorise. Ce basculement vers une logique de permission plutôt que d’interdiction rend les politiques bien plus faciles à tenir dans la durée.

Déployer une politique COOP sans casser vos intégrations

Mettre en place une Cross-Origin-Opener-Policy sur un site existant suppose de vérifier au préalable ce qui repose sur l’ouverture de fenêtres, car une isolation trop brutale peut casser une connexion sociale ou un tunnel de paiement. La prudence consiste, là encore, à observer avant de verrouiller.

Choisir la bonne valeur selon vos usages

Le choix de départ se fait entre l’isolation totale et la variante tolérant les popups. Un site qui ouvre des fenêtres de paiement ou d’authentification tierce optera souvent pour same-origin-allow-popups, afin de préserver ces échanges légitimes tout en bénéficiant de l’isolation vis-à-vis du reste. Un site sans ces dépendances peut viser directement la valeur la plus stricte. Ce choix mérite d’être documenté, car il conditionne la suite. Décider en connaissance de cause quelle valeur appliquer évite de revenir en arrière après coup, et donne une base claire pour les évolutions futures du site, lorsqu’un nouveau service tiers viendra s’ajouter à l’ensemble. Il vaut la peine d’associer ici les personnes qui connaissent les parcours métier, car elles seules savent quelles ouvertures de fenêtres sont réellement indispensables. Croiser cette connaissance fonctionnelle avec l’objectif de sécurité aboutit à une valeur choisie en connaissance de cause, plutôt qu’à un réglage copié sans en comprendre les effets. Cette décision documentée facilite aussi le dialogue avec les prestataires tiers. Lorsqu’un service de paiement ou d’authentification exige une certaine gestion des fenêtres, savoir précisément quelle valeur on applique permet d’identifier vite l’origine d’un blocage. On échange alors sur une base technique commune et claire, au lieu de multiplier les essais à l’aveugle qui font perdre du temps des deux côtés. Le tableau suivant relie chaque profil d’usage à la valeur COOP la plus adaptée.

Tester l’impact sur les popups et le paiement

Avant de généraliser la politique, on vérifie méthodiquement les parcours qui ouvrent des fenêtres : connexion via un compte externe, prestataire de paiement, partage social. L’objectif est de s’assurer que l’isolation ne rompt aucun aller-retour indispensable entre la fenêtre ouverte et la page d’origine, ce qui se teste parcours par parcours. Les outils de développement du navigateur signalent clairement quand une fonctionnalité est bloquée par la politique d’ouverture. S’appuyer sur ces messages permet d’ajuster finement la valeur retenue, et de distinguer un vrai blocage fonctionnel d’un simple avertissement sans conséquence sur l’expérience réelle des visiteurs. On a tout intérêt à mener ces tests sur plusieurs navigateurs, car leur gestion des fenêtres et des en-têtes présente parfois de subtiles différences. Couvrir les principaux moteurs du marché évite de découvrir, après coup, qu’un parcours fonctionne ici mais casse ailleurs, toujours plus coûteux à corriger une fois le site en ligne. Au-delà des navigateurs, il faut vérifier les usages réels sur appareils mobiles, où les fenêtres se comportent différemment. Un paiement qui s’ouvre dans une vue intégrée plutôt que dans un onglet classique peut réagir autrement à l’isolation. Couvrir ces cas avant la généralisation garantit que la politique tient sur l’ensemble des appareils, et pas seulement dans l’environnement du développeur, souvent plus homogène que la réalité.

Surveiller via les rapports

Le COOP sait remonter ses incidents vers un point de collecte, à la manière d’autres en-têtes de sécurité modernes. Brancher cette remontée de rapports offre une visibilité continue sur les cas où l’isolation entre en jeu, et aide à repérer un service tiers nouvellement ajouté qui se heurterait à la politique. Cette surveillance s’inscrit dans la durée, car un site évolue et ses intégrations aussi. Relire la politique à chaque ajout de fonctionnalité qui ouvre des fenêtres maintient l’équilibre entre isolation solide et fonctions opérationnelles, sans laisser la configuration se dégrader silencieusement au fil des mises à jour. Cette boucle d’observation transforme la sécurité en démarche vivante plutôt qu’en réglage figé. Chaque rapport éclaire une zone du site, confirme une protection ou révèle un oubli. Entretenir cette vigilance continue sur les remontées garde l’isolation utile à mesure que les usages évoluent, sans laisser la configuration se périmer en silence.