# Ajouter Cross-Origin-Opener-Policy pour isoler un iframe de paiement tiers

> Un widget de paiement embarqué en iframe partage par défaut son contexte de navigation avec la page qui l'accueille. Les étapes pour l'isoler sans casser le tunnel de paiement.

- Auteur : WordPress Développement
- Publié le : 2021-04-25
- Mis à jour le : 2021-04-25
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/cross-origin-opener-policy-iframe-paiement/

## L’essentiel

- COOP isole le contexte de navigation d'une origine à l'autre
- Une mauvaise valeur casse une redirection de paiement légitime
- Le test doit couvrir tout le tunnel, pas seulement l'affichage initial

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

> L'essentiel à retenir : COOP isole le contexte de navigation d'une origine à l'autre ; Une mauvaise valeur casse une redirection de paiement légitime ; Le test doit couvrir tout le tunnel, pas seulement l'affichage initial

## É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.