Cross-Origin-Opener-Policy: same-origin : cette ligne d’en-tête HTTP isole une fenêtre de navigation des autres fenêtres ou onglets ouverts par des origines différentes, en empêchant tout accès direct entre leurs objets window respectifs. Pour une page qui embarque un widget de paiement tiers en iframe, cette isolation limite ce que le contenu de l’iframe pourrait autrement observer ou manipuler dans la fenêtre principale, et inversement.
Étape 1 : comprendre ce que COOP isole précisément
Sans cet en-tête, une page ouverte depuis un lien ou un formulaire peut, dans certains cas, conserver une référence à la fenêtre d’origine via la propriété JavaScript window.opener. Un widget de paiement qui ouvrirait une fenêtre de confirmation dans un nouvel onglet pourrait alors, en théorie, interagir avec la fenêtre d’origine si celle-ci n’a pas explicitement coupé ce lien. L’en-tête Cross-Origin-Opener-Policy ferme cette possibilité en isolant le contexte de navigation par origine.
Étape 2 : choisir la bonne valeur pour un tunnel de paiement
Trois valeurs principales existent : unsafe-none, qui conserve le comportement historique sans isolation, same-origin-allow-popups, qui isole la page tout en conservant une relation limitée avec les fenêtres qu’elle ouvre elle-même, et same-origin, l’isolation la plus stricte. Pour une page qui ouvre une fenêtre de paiement tierce en popup et doit ensuite recevoir une confirmation de cette fenêtre, same-origin-allow-popups constitue généralement le bon compromis, car same-origin strict couperait la communication nécessaire au retour de confirmation.
Étape 3 : déclarer l’en-tête côté serveur
<IfModule mod_headers.c>
Header always set Cross-Origin-Opener-Policy "same-origin-allow-popups"
</IfModule>
Sur WordPress, cette déclaration peut aussi passer par le filtre wp_headers, ce qui évite de dépendre uniquement de la configuration serveur et permet de la limiter à certains gabarits de page seulement, comme la page de paiement :
add_filter('wp_headers', function (array $headers) {
if (is_page('paiement')) {
$headers['Cross-Origin-Opener-Policy'] = 'same-origin-allow-popups';
}
return $headers;
});
Étape 4 : tester l’intégralité du parcours de paiement
L’erreur la plus fréquente consiste à tester uniquement l’affichage initial du widget, sans dérouler le parcours complet jusqu’à la page de confirmation. Un tunnel qui ouvre plusieurs fenêtres successives, ou qui redirige via une page intermédiaire hébergée sur un autre domaine, peut révéler un blocage inattendu uniquement à cette étape avancée si la valeur choisie est trop stricte pour ce schéma précis.
- Dérouler un paiement de test jusqu’à sa confirmation complète, dans un navigateur avec la console de développement ouverte.
- Vérifier l’absence d’erreur liée à une fenêtre bloquée ou à une communication refusée entre fenêtres.
- Répéter le test sur un navigateur mobile, où le comportement des popups diffère parfois de celui d’un ordinateur de bureau.
Étape 5 : documenter la valeur choisie et sa raison
Un commentaire proche de la déclaration de l’en-tête, précisant pourquoi same-origin-allow-popups a été retenu plutôt que la valeur la plus stricte, évite qu’une future revue de sécurité durcisse cette valeur sans tester l’impact sur le tunnel de paiement, et casse ainsi un parcours qui fonctionnait jusque-là.
Ce que COOP n’isole pas à lui seul
Cross-Origin-Opener-Policy agit sur le contexte de navigation entre fenêtres, pas sur le contenu d’une iframe intégrée directement dans la page, qui reste régie par d’autres mécanismes comme l’attribut sandbox ou l’en-tête Content-Security-Policy. Un widget de paiement affiché directement en iframe plutôt que via une fenêtre popup ne bénéficie donc pas de cette isolation particulière, et nécessite une revue distincte de ses propres restrictions d’intégration.
En résumé
Cross-Origin-Opener-Policy isole efficacement le contexte de navigation d’une page vis-à-vis des origines tierces qu’elle embarque ou qu’elle ouvre, à condition de choisir la valeur adaptée au schéma réel du tunnel de paiement concerné. Une valeur trop stricte casse la communication nécessaire au retour de confirmation ; une valeur absente laisse la porte ouverte à une interaction non désirée entre fenêtres d’origines différentes.
