# Ajouter un en-tête Permissions-Policy pour limiter ce qu’une intégration tierce peut solliciter

> Un widget de carte ou de visioconférence embarqué en iframe peut, par défaut, demander la géolocalisation ou la caméra. Cinq étapes pour restreindre ces permissions.

- Auteur : WordPress Développement
- Publié le : 2020-09-03
- Mis à jour le : 2020-09-03
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/en-tete-permissions-policy-integration-tierce/

## L’essentiel

- Permissions-Policy restreint les API sensibles par origine
- Une iframe hérite des permissions sauf restriction explicite
- Le test doit couvrir chaque fonctionnalité réellement utilisée

La spécification Permissions Policy décrit ce mécanisme comme un moyen de sélectivement activer et désactiver l'usage de fonctionnalités et d'API du navigateur. Concrètement, un en-tête HTTP permet à un site d'interdire à une iframe embarquée l'accès à la caméra, au microphone ou à la géolocalisation, même si le contenu de cette iframe tente de les solliciter.

Un widget de visioconférence, une carte interactive ou un lecteur vidéo tiers intégré en `<iframe>` hérite, par défaut, d'un accès potentiel à plusieurs API sensibles du navigateur. Restreindre explicitement ce qui est autorisé réduit la surface d'action de ce code que l'éditeur du site ne maîtrise pas directement.

## Étape 1 : identifier les fonctionnalités réellement nécessaires

Avant toute restriction, il faut lister ce que chaque intégration tierce utilise réellement. Un widget de carte n'a généralement besoin que de `geolocation`. Un lecteur vidéo peut nécessiter `fullscreen` et `autoplay`. Tester l'intégration avec les outils de développement du navigateur ouverts, onglet réseau et console, révèle rapidement les permissions sollicitées.

## Étape 2 : construire l'en-tête au niveau du serveur

L'en-tête se construit comme une liste de directives, chacune associée à une liste d'origines autorisées. Sur un serveur Apache, il s'ajoute via `.htaccess` ou la configuration du site :

> L'essentiel à retenir : Permissions-Policy restreint les API sensibles par origine ; Une iframe hérite des permissions sauf restriction explicite ; Le test doit couvrir chaque fonctionnalité réellement utilisée

```
<IfModule mod_headers.c>
    Header always set Permissions-Policy "geolocation=(self \"https://cartes.exemple-fournisseur.fr\"), camera=(), microphone=(), fullscreen=(self)"
</IfModule>
```

Sur Nginx, la déclaration prend la forme suivante dans le bloc `server` :

```
add_header Permissions-Policy "geolocation=(self \"https://cartes.exemple-fournisseur.fr\"), camera=(), microphone=(), fullscreen=(self)" always;
```

## Étape 3 : refuser par défaut, autoriser explicitement

La parenthèse vide, comme `camera=()`, interdit l'usage de la fonctionnalité à toutes les origines, y compris le site lui-même. La valeur `self` l'autorise uniquement pour le domaine principal. Ajouter une origine tierce entre guillemets, comme dans l'exemple ci-dessus, l'autorise spécifiquement pour cette iframe et aucune autre.

## Étape 4 : vérifier depuis WordPress si une extension définit déjà des en-têtes

Certaines extensions de cache ou de sécurité ajoutent déjà des en-têtes HTTP via le filtre `wp_headers`. Deux définitions concurrentes de `Permissions-Policy` ne s'additionnent pas : la seconde écrase généralement la première selon l'ordre d'exécution. Un test avec l'onglet réseau du navigateur, en observant la réponse du document HTML, confirme quel en-tête est réellement envoyé.

```
add_filter('wp_headers', function (array $headers) {
    $headers['Permissions-Policy'] = "geolocation=(self), camera=(), microphone=()";
    return $headers;
});
```

## Étape 5 : tester chaque intégration après la mise en place

- Charger chaque page contenant une iframe tierce et vérifier dans la console qu'aucune erreur de type violation de la politique de permissions n'apparaît pour une fonctionnalité réellement utilisée.
- Si une fonctionnalité légitime se retrouve bloquée, ajouter son origine à la directive concernée plutôt que de supprimer la restriction entière.
- Documenter, dans un commentaire proche de la définition de l'en-tête, la raison de chaque origine autorisée, pour faciliter une révision future.

## Ce qui distingue Permissions-Policy d'une simple bonne pratique

Contrairement à une recommandation de configuration générale, cet en-tête produit un effet vérifiable et observable immédiatement : une tentative d'accès à une API restreinte, depuis une origine non autorisée par la directive, échoue systématiquement côté navigateur, sans dépendre du comportement du code tiers lui-même. Le site n'a donc pas besoin de faire confiance au bon comportement du widget embarqué : la restriction s'applique indépendamment de ce que ce code tente de faire, ce qui en fait une protection active plutôt qu'une simple recommandation de bonne conduite.

## En résumé

Un en-tête Permissions-Policy correctement configuré ne remplace pas une revue de sécurité du code tiers embarqué, mais il limite ce que ce code peut solliciter au niveau du navigateur, même en cas de comportement inattendu ou malveillant de son côté. La démarche complète tient en cinq étapes : lister les besoins réels, construire l'en-tête, refuser par défaut, vérifier les conflits, puis tester chaque intégration.