Permissions-Policy : Verrouiller les API matérielles et neutraliser les fuites de capteurs

Dans les architectures web modernes, une application héberge rarement son seul propre code : balises publicitaires, widgets de chat, outils de mesure d’audience ou scripts de cartographie s’exécutent quotidiennement dans le contexte d’exécution de vos utilisateurs. Sans restriction stricte, n’importe lequel de ces scripts tiers peut solliciter la caméra, activer le microphone, interroger la géolocalisation GPS ou sonder les capteurs de mouvement du terminal. Dans ce guide de référence, je détaille le fonctionnement de l’en-tête Permissions-Policy, son rôle capital contre les attaques sur la supply chain et la méthode pour déployer une politique zéro régression au sein de votre pipeline DevSecOps.

1. Qu’est-ce que Permissions-Policy et pourquoi Feature-Policy est obsolète

Standardisé par le W3C au sein du groupe de travail Web Application Security, l’en-tête HTTP Permissions-Policy permet aux propriétaires de sites web d’activer, de restreindre ou d’interdire sélectivement l’accès aux API matérielles et fonctionnalités sensibles du navigateur pour leur propre document ainsi que pour les cadres intégrés (<iframe>).

Pendant plusieurs années, ce contrôle était opéré par l’en-tête Feature-Policy. Pourquoi ce dernier est-il aujourd’hui obsolète ?

La différence syntaxique est immédiate et normalisée :

# Ancienne syntaxe dépréciée (Feature-Policy) :
Feature-Policy: camera 'none'; microphone 'none'; geolocation 'self'

# Nouvelle syntaxe moderne standardisée (Permissions-Policy) :
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

2. La menace des scripts tiers & supply chain attacks (écoutes et exfiltration)

En tant que directeur informatique et auditeur DevSecOps, je constate fréquemment que les équipes techniques se concentrent exclusivement sur la sécurisation de leur propre code source (tests unitaires, analyse statique, revues de code), tout en important aveuglément des dizaines de bibliothèques JavaScript externes via des gestionnaires de paquets ou des CDN tiers.

C’est précisément la porte d’entrée des attaques sur la chaîne logistique logicielle (supply chain) :

1. Un pirate compromet un dépôt npm populaire, pirate le compte d’un mainteneur open source ou corrompt le serveur de distribution d’un widget de chat client.
2. Le script tiers malveillant est injecté sur votre application web légitime et s’exécute avec les privilèges complets de la page parente.
3. Sans en-tête Permissions-Policy strict, ce script peut déclencher des requêtes d’accès au microphone, capturer les flux de webcam à l’insu de vos visiteurs ou sonder en tâche de fond l’accéléromètre et le gyroscope pour effectuer du device fingerprinting et profiler les utilisateurs.

En déclarant un en-tête Permissions-Policy à la racine de votre infrastructure serveur, vous imposez un verrou matériel infranchissable. Même si un script tiers est compromis, l’interdiction est exécutée directement par le moteur C++ du navigateur : l’appel à navigator.mediaDevices.getUserMedia() ou navigator.geolocation est rejeté instantanément sans jamais afficher de boîte de dialogue trompeuse à l’utilisateur.

3. Syntaxe officielle et directives indispensables (camera, mic, geolocation, usb)

Chaque fonctionnalité est déclarée sous la forme fonctionnalite=(liste_d_autorisation), séparée par des virgules.

Les 4 cibles d’autorisation possibles

• () : Interdiction totale. Aucun contexte (ni votre propre domaine, ni les sous-domaines, ni les iframes) ne peut utiliser cette API.
• (self) : Origine unique. Seul votre propre document hébergé sur le domaine exact peut invoquer la fonctionnalité.
• (self "https://partenaire.com") : Délégation explicite. Seuls votre domaine et les origines explicitement listées entre guillemets sont autorisés.
• * : Autorisation universelle (à proscrire formellement en production sur les API critiques).

Le socle de directives DevSecOps recommandé en 2026

Pour une application web professionnelle standard (SaaS, e-commerce, média, portail corporate), voici le gabarit de durcissement que j’applique systématiquement :

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), fullscreen=(self), screen-wake-lock=(), display-capture=()

Détaillons l’utilité des contrôles clés :

• camera=(), microphone=() : Neutralisation absolue de tout risque d’écoute furtive ou de capture d’image.
• geolocation=() : Protection de la vie privée des utilisateurs contre la géolocalisation clandestine (remplacez par geolocation=(self) si votre site propose un localisateur de points de vente légitime).
• payment=() : Bloque l’accès à la Payment Request API native, réservant les flux de paiement à vos tunnels contrôlés.
• usb=() : Interdit l’interaction avec les périphériques WebUSB connectés au terminal du visiteur.
• accelerometer=(), gyroscope=(), magnetometer=() : Bloque les capteurs inertiels fréquemment détournés pour espionner la frappe au clavier ou identifier de manière unique l’appareil.
• display-capture=() : Empêche un script tiers de déclencher la capture d’écran du bureau de l’internaute (Screen Capture API).

4. Délégation granulaire dans les <iframe> : l’attribut allow vs héritage

L’un des atouts majeurs de Permissions-Policy réside dans sa gestion de la hiérarchie d’intégration. Par défaut, une page enfant chargée dans une balise <iframe> hérite strictement des restrictions de la page parente.

Si votre application principale bloque la caméra via Permissions-Policy: camera=(), aucun iframe ne pourra activer la caméra, même si l’iframe tente de déclarer son propre en-tête permissif.

À l’inverse, si vous autorisez une fonctionnalité sur votre domaine principal et souhaitez la déléguer de manière chirurgicale à un prestataire tiers (ex. un widget de visioconférence ou un lecteur vidéo), vous devez combiner l’en-tête HTTP et l’attribut HTML allow :

<!-- Délégation explicite et sécurisée du plein écran et de la caméra au widget tiers -->
<iframe src="https://meet.prestataire.com/room/123" 
        allow="camera 'src'; fullscreen 'src'"
        title="Salle de réunion sécurisée">
</iframe>

5. Stratégie de déploiement DevSecOps sans régression applicative

Dans une démarche DevSecOps d’entreprise, la sécurité ne doit jamais bloquer le déploiement continu ni introduire de régression fonctionnelle silencieuse. Pour intégrer Permissions-Policy sereinement, j’applique un protocole en 3 phases :

Phase 1 : Inventaire des fonctionnalités légitimes

Consultez vos équipes produit et inspectez vos maquettes : votre application a-t-elle un besoin réel de vidéo, d’audio, de géolocalisation ou de détection d’orientation ? Si la réponse est non pour 95 % des capteurs, ces derniers peuvent être neutralisés dès la première mise en production.

Phase 2 : Surveillance des violations via la Console & Reporting API

Avant de durcir un environnement complexe, vous pouvez associer l’en-tête à la directive de signalement report-to pour agréger les éventuelles tentatives de blocage :

# Signalement des violations vers votre collecteur d'audit
Permissions-Policy: camera=(), microphone=(); report-to=csp-endpoint

Phase 3 : Intégration dans vos tests automatisés CI/CD

Ajoutez un test de conformité automatisé dans votre pipeline (ex. PHPUnit, Playwright ou script curl) pour vérifier que l’en-tête est systématiquement retourné avec un code HTTP 200 sur toutes vos routes sensibles.

6. Configurations serveur prêtes pour la production : Nginx, Apache, Caddy & Cloudflare

Voici les snippets de configuration prêts au déploiement pour vos serveurs web et proxys inverses :

Configuration Nginx

Dans votre bloc de serveur HTTPS (server { ... }) :

# Nginx - Verrouillage Permissions-Policy DevSecOps 2026
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), fullscreen=(self), screen-wake-lock=(), display-capture=()" always;

Configuration Apache (mod_headers)

Dans votre fichier .htaccess ou configuration VirtualHost :

# Apache - Directives de durcissement matériel
<IfModule mod_headers.c>
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), fullscreen=(self), screen-wake-lock=(), display-capture=()"
</IfModule>

Configuration Caddy

Dans votre bloc de domaine dans le Caddyfile :

votresite.com {
    header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), fullscreen=(self), screen-wake-lock=(), display-capture=()"
    reverse_proxy localhost:8080
}

Configuration Cloudflare Transform Rules

Si vous utilisez Cloudflare, vous pouvez injecter l’en-tête à la périphérie du réseau (Edge) sans modifier votre serveur d’origine :

1. Allez dans Rules > Transform Rules > Modify Response Header.
2. Créez une règle active sur l’ensemble du trafic entrant (All incoming requests).
3. Définissez l’action : Set dynamic ou Set static, nom d’en-tête Permissions-Policy et collez la chaîne de directives.

7. Réduction globale de la surface d’attaque : L’écosystème WebGuardian

L’en-tête Permissions-Policy constitue un rempart redoutable pour la confidentialité des périphériques, mais il ne forme qu’un maillon d’une stratégie DevSecOps cohérente. Pour prémunir vos actifs numériques contre les intrusions et le vol de session, il doit fonctionner en synergie avec :

• La politique de transport chiffré : Découvrez comment interdire le trafic en clair et vous prémunir du SSL Stripping dans mon guide complet Strict-Transport-Security (HSTS).
• La défense applicative multicouche : Retrouvez les bonnes pratiques de configuration de CSP, X-Frame-Options et Referrer-Policy dans mon guide des Security Headers HTTP essentiels.
• La maîtrise avancée de CSP Niveau 3 : Découvrez prochainement mon analyse sur l’orchestration des nonces dynamiques dans mon dossier DevSecOps sur CSP Avancé (à paraître).