Permissions Policy pour les fonctions du navigateur intégrées

Permissions Policy limite les fonctions du navigateur qu'un document peut utiliser. La réponse du document supérieur fixe la limite maximale et l'attribut allow de l'iframe délègue une fonction à l'origine enfant. Ce mécanisme n'accorde pas la permission de l'utilisateur, ne crée pas de périphérique et ne prouve pas la réussite de l'application.

Pour une caméra, un microphone, la géolocalisation ou le plein écran, consignez séparément la politique reçue, l'origine finale, l'état de permission et le résultat visible. Cette séparation indique le propriétaire du problème sans élargir l'accès après l'échec d'un fournisseur. L'exemple compare https://app.example et https://widget.example.

L'exemple compare https://app.example et https://widget.example.

Ce que contrôle la politique

La spécification W3C associe une fonction à une liste d'origines. Permissions-Policy: geolocation=(self "https://widget.example") autorise le document principal et le widget nommé. L'iframe doit ensuite correspondre à cette origine: allow="geolocation" ne rend pas une autre origine admissible. Schéma, port, redirections et chaîne de frames sont importants. Les valeurs par défaut dépendent de la fonction; vérifiez le guide MDN.

«Autorisé par la politique» signifie seulement que le document peut tenter l'API. Le contexte sécurisé, l'activation utilisateur, l'autorisation, un réglage administrateur, un périphérique et des options propres à la fonction peuvent encore échouer. Un état prompt ou granted de navigator.permissions ne supprime pas un blocage de l'iframe.

Étape	Preuve	Ce que cela ne prouve pas
Origine et contexte	URL finale, schéma, port, contexte sécurisé	La présence de l'API
Implémentation	Test ciblé de l'interface	Une requête autorisée
Permissions Policy	Header, allow, ancêtres, origine enfant	Une permission ou un périphérique
Décision plateforme	prompt, refus, réglage, état du périphérique	Le résultat métier
Application	État visible et accusé avec délai borné	Un enregistrement serveur

camera, microphone, geolocation et fullscreen sont des entrées distinctes. Déclarez uniquement ce que le parcours utilise. Évitez * dans un système multi-tenant; validez l'origine réelle après redirection et gardez une allowlist révisable.

Frontière avec CSP, COOP et COEP

CSP détermine quels scripts, connexions, images et frames peuvent être chargés via script-src, connect-src et frame-src. CSP peut bloquer le chargement avant Permissions Policy; une frame chargée peut ensuite être bloquée par la politique. Ne diminuez pas CSP pour masquer une délégation manquante.

COOP modifie les relations entre contextes de premier niveau et fenêtres opener. COEP impose des conditions CORS ou CORP aux ressources cross-origin intégrées. Aucun des deux n'autorise caméra, microphone ou géolocalisation; Permissions Policy ne crée pas non plus l'isolation cross-origin et ne rend pas une ressource compatible CORS. Vérifiez réseau et CSP, puis origine et isolation si nécessaire, header et allow, puis seulement la demande soumise à l'utilisateur.

Ces mécanismes ne remplacent ni l'autorisation serveur, ni la validation, ni le consentement, ni l'accessibilité. Une API permise requiert encore une décision produit sur le compte et la durée du flux.

Une requête comporte plusieurs étapes

Vérifiez d'abord l'origine finale et le contexte sécurisé.

Vérifiez ensuite que le navigateur expose l'interface attendue.

Consignez le header, allow, la chaîne des ancêtres et l'origine enfant.

Après la politique, l'activation, l'autorisation, l'administrateur et le périphérique peuvent encore bloquer.

Enfin, vérifiez l'état affiché par l'application.

Contrat d'intégration et solution de repli

Avant de modifier les headers, nommez origine supérieure et origine enfant finale, fonction, but, geste, propriétaires du header et du markup, et alternative visible. Une caméra peut proposer un téléversement manuel; le plein écran doit garder la navigation normale; la géolocalisation doit offrir une saisie manuelle. Un refus ou un délai ne doit pas perdre le focus ni les données. Arrêtez les pistes caméra/microphone à la fin et ne répétez pas silencieusement les invites.

Fixture contrôlé et candidat

Exposez /fixtures/permissions-policy/control.html et candidate.html sur votre propre hôte. Les deux pages utilisent la même frame, le même bouton et le même marqueur. Seul le candidat reçoit le header de délégation; le contrôle l'omet. Le script enfant affiche policy=blocked ou policy=allowed après l'action explicite. Utilisez une permission synthétique, jamais la position d'une personne.

import { test, expect } from '@playwright/test';

const cases = [
  { name: 'control', url: 'https://qa.example.test/fixtures/permissions-policy/control.html', expected: 'blocked' },
  { name: 'candidate', url: 'https://qa.example.test/fixtures/permissions-policy/candidate.html', expected: 'allowed' },
];

for (const scenario of cases) {
  test(`Permissions Policy ${scenario.name}`, async ({ page }) => {
    try {
      const response = await page.goto(scenario.url, { waitUntil: 'domcontentloaded', timeout: 8000 });
      expect(response?.ok(), `réponse HTTP ${scenario.name}`).toBeTruthy();
    } catch (error) {
      throw new Error(`NETWORK_ERROR avant l'assertion: ${error.message}`);
    }
    await page.getByRole('button', { name: 'Request location' }).click();
    await expect(page.getByTestId('policy-result')).toHaveText(new RegExp(`^${scenario.expected}$`), { timeout: 5000 });
  });
}

Un délai de navigation ou de statut est une absence de preuve dans la fenêtre définie, pas un refus de politique. DNS, certificat, réponse HTTP ou route manquante restent NETWORK_ERROR. Ne transformez jamais une candidate inaccessible en blocked. Fermez le contexte et supprimez les données temporaires dans finally, en conservant la première erreur. Les routes sont attribuables car frame, origine, geste et résultat sont identiques; seule la délégation varie.

Déploiement et diagnostic

En staging, utilisez le même routage. Inspectez le header et allow après redirections, CDN, service worker et proxy. Classez le premier échec: header incorrect, chaîne de politique bloquée, refus utilisateur, erreur d'application, ou disponibilité réseau. Un résultat allowed suivi d'un refus n'est pas une panne du header; un timeout DNS n'est pas une politique.

Testez la suppression temporaire de la fonction, une origine inattendue, une redirection non listée et une frame imbriquée sans délégation. Conservez la configuration et le markup précédents pour revenir en arrière. Ne retirez pas tout le header et n'ajoutez pas *; une exception doit nommer fonction, origine, responsable et date d'expiration.

Ce que BotBrowser peut valider

BotBrowser peut exécuter ces parcours autorisés dans des contextes contrôlés, isoler l'état synthétique et comparer le résultat visible sur une version déclarée. BotBrowser ne peut pas modifier la politique livrée ni accorder une permission. Sa documentation d'isolation décrit les contextes séparés.

BotBrowser ne rédige ni ne déploie les headers, ne change pas les origines, n'accorde pas de permissions, ne fournit pas de périphérique, ne remplace pas CSP/COOP/COEP, ne corrige pas une réponse tierce et ne prouve pas une opération distante. La spécification W3C et les headers réellement livrés font foi. Les équipes application, infrastructure, fournisseur et consentement restent responsables.

Ne journalisez ni cookies, ni identifiants, ni coordonnées, ni contenu de flux.

Employez un compte synthétique propre à chaque tentative autorisée.

Revalidez l'origine finale lorsque le fournisseur change.

Toute exception urgente doit avoir un responsable et une expiration.

Le rollback doit restaurer le header et le markup ensemble.

Le support doit nommer la première étape en échec, pas une cause générique.

Consultez le guide des contextes sécurisés.

Consultez le guide CSP.

Consultez le guide d'isolation cross-origin.

Le consentement doit expliquer le but avant l'activation.

Sources

• W3C: Permissions Policy
• MDN: Permissions Policy
• MDN: attribut allow
• MDN: CSP
• MDN: COOP
• MDN: COEP
• BotBrowser: isolation

BotBrowser Team