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