# Ajouter un en-tête Permissions-Policy granulaire pour un site qui multiplie les scripts tiers

> Bloquer toutes les API sensibles du navigateur revient souvent à casser une intégration légitime. Composer une politique fine évite ce compromis frustrant.

- Auteur : WordPress Développement
- Publié le : 2024-06-11
- Mis à jour le : 2024-06-11
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/permissions-policy-granulaire-scripts-tiers/

## L’essentiel

- Permissions-Policy contrôle l'accès aux API sensibles du navigateur, pas seulement les scripts
- Une politique trop restrictive casse des intégrations légitimes
- Autoriser au cas par cas, par origine, plutôt qu'en tout ou rien

Un site qui accumule les intégrations tierces — widget de chat, carte interactive, lecteur vidéo, module de paiement embarqué — expose potentiellement chacune de ces API du navigateur (géolocalisation, caméra, microphone, capteurs de mouvement) à des scripts qui n'en ont pourtant besoin que ponctuellement. L'en-tête HTTP `Permissions-Policy`, successeur de l'ancien `Feature-Policy`, permet de restreindre précisément quelles origines peuvent utiliser quelles fonctionnalités, plutôt que de laisser un accès ouvert par défaut à tout script chargé sur la page.

Contrairement à une politique tout-ou-rien qui désactiverait une fonctionnalité pour l'ensemble du site, `Permissions-Policy` autorise une granularité fine par directive et par origine, ce qui évite le compromis frustrant entre sécurité et fonctionnalités réellement nécessaires.

## Étape 1 : lister les fonctionnalités réellement utilisées

Avant de composer une politique restrictive, il faut inventorier quelles API du navigateur sont effectivement sollicitées par les intégrations en place. Sur un projet type combinant un widget de chat, une carte interactive et un lecteur vidéo, l'inventaire ressemble typiquement à ceci :

- Le widget de chat demande l'accès au microphone pour les messages vocaux
- La carte interactive demande la géolocalisation pour centrer la vue
- Le lecteur vidéo demande le mode plein écran (`fullscreen`)
- Aucune intégration n'a besoin de la caméra ni des capteurs de mouvement

## Étape 2 : composer la politique par directive

> L'essentiel à retenir : Permissions-Policy contrôle l'accès aux API sensibles du navigateur, pas seulement les scripts ; Une politique trop restrictive casse des intégrations légitimes ; Autoriser au cas par cas, par origine, plutôt qu'en tout ou rien

Chaque directive de `Permissions-Policy` accepte une liste d'origines autorisées, ou les valeurs spéciales `*` (toutes origines), `self` (origine du site) ou une liste vide (fonctionnalité totalement désactivée). Pour l'inventaire ci-dessus :

```
add_action( 'send_headers', function () {
    $politique = array(
        'camera=()',
        'microphone=(self "https://widget-chat-exemple.com")',
        'geolocation=(self "https://cartes-exemple.com")',
        'fullscreen=(self "https://lecteur-video-exemple.com")',
        'accelerometer=()',
        'gyroscope=()',
        'magnetometer=()',
    );
    header( 'Permissions-Policy: ' . implode( ', ', $politique ) );
} );
```

Cette configuration ferme entièrement l'accès à la caméra et aux capteurs de mouvement, dont aucune intégration en place n'a besoin, tout en autorisant précisément les trois origines qui utilisent légitimement le microphone, la géolocalisation et le plein écran.

## Étape 3 : tester chaque intégration après déploiement

Une politique trop restrictive se manifeste rarement par une erreur explicite : le plus souvent, la fonctionnalité concernée cesse simplement de fonctionner, sans message clair pour l'utilisateur. Après tout déploiement d'un en-tête `Permissions-Policy`, il faut tester manuellement chaque intégration concernée — activer le micro du widget de chat, demander la géolocalisation sur la carte, passer le lecteur vidéo en plein écran — pour confirmer qu'aucune n'a été bloquée par erreur.

### Un piège fréquent : les iframes

Une fonctionnalité autorisée par `Permissions-Policy` au niveau du document principal ne se propage pas automatiquement à une iframe intégrée, sauf si l'attribut `allow` de la balise `iframe` la répercute explicitement :

```
<iframe src="https://lecteur-video-exemple.com/player"
        allow="fullscreen"></iframe>
```

Oublier cet attribut sur une iframe reste la cause la plus fréquente d'une intégration qui « ne fonctionne plus » après l'ajout de l'en-tête, alors que la politique côté serveur est correctement configurée.

## Étape 4 : revoir la politique à chaque nouvelle intégration

La politique n'est jamais figée : chaque nouveau script tiers ajouté au site doit être évalué pour déterminer s'il nécessite une fonctionnalité non encore autorisée, et l'en-tête doit être mis à jour en conséquence. Une politique composée une fois puis jamais révisée finit par bloquer silencieusement une intégration future, ou pire, par être élargie par réflexe à `*` pour « éviter les problèmes », ce qui annule l'intérêt de la démarche.

> Une politique de permissions qui n'autorise que ce qui est réellement utilisé referme une surface d'attaque sans qu'aucun visiteur ne s'en aperçoive.

## En résumé

Composer un en-tête `Permissions-Policy` granulaire, directive par directive et origine par origine, évite le dilemme entre tout bloquer et ne rien restreindre. L'effort principal ne réside pas dans la syntaxe de l'en-tête, mais dans l'inventaire précis des fonctionnalités réellement nécessaires à chaque intégration tierce, et dans la discipline de revoir cette politique à chaque évolution du site.