Générateur Permissions-Policy, créer le header depuis les reports

Générez un header Permissions-Policy depuis les reports des navigateurs. Accordez la caméra, le paiement et plus encore à vos pages et iframes, puis déployez.

Le générateur Permissions-Policy écrit un header Permissions-Policy à partir de vos propres reports. Ce header indique au navigateur quelles fonctionnalités, comme la caméra, la géolocalisation ou la fenêtre de paiement, vos pages et les iframes qu'elles embarquent peuvent utiliser. Vous choisissez les reports à analyser, partez d'un préréglage ou de votre propre politique, accordez chaque fonctionnalité aux pages et iframes qui l'utilisent, puis copiez les headers.

Le générateur se trouve sous chaque site, dans la barre latérale, sous Générateurs > Permissions-Policy, à côté du générateur CSP et du générateur Connection-Allowlist. Il fonctionne sur tous les plans, et tous les rôles d'un site peuvent l'utiliser. Pour ce que les trois générateurs ont en commun, consultez Générateurs.

Revoyez chaque autorisation et déployez d'abord en report-only

Le générateur accorde chaque fonctionnalité aux pages et iframes dont les navigateurs ont reporté l'usage. Toute personne qui connaît votre endpoint de reporting peut lui envoyer des reports, une fonctionnalité accordée ne prouve donc pas que vos pages l'utilisent. Revoyez les autorisations avant de déployer, en commençant par les fonctionnalités accordées à une autre origine. Une politique issue de l'API ou de l'outil MCP applique les mêmes réglages par défaut, sans revue, alors vérifiez-la de la même façon.

Déployez toujours une nouvelle politique d'abord avec le header Permissions-Policy-Report-Only. Passez à Permissions-Policy seulement quand au moins une semaine de reports montre que rien de ce dont vos pages ont besoin ne serait bloqué.

Ce que produit le générateur Permissions-Policy

Le générateur aboutit à deux headers de réponse, prêts à coller dans la configuration de votre serveur ou de votre réseau de diffusion de contenu (CDN). Un header Reporting-Endpoints envoie les reports vers l'endpoint CentralCSP de votre site. Un header Permissions-Policy-Report-Only porte la politique, ou Permissions-Policy une fois que vous passez en mode bloquant.

Chaque fonctionnalité de la politique se lit de l'une de trois façons. () la refuse partout, self l'accorde à vos propres pages, et une origine entre guillemets l'accorde à une iframe de cette origine :

Permissions-Policy-Report-Only: camera=(), geolocation=(self), payment=(self "https://pay.example.com")

Le générateur n'écrit aucun paramètre report-to dans la politique. Ses reports partent vers l'endpoint nommé default, que le header Reporting-Endpoints déclare à côté de centralcsp. Consultez L'endpoint par défaut.

Le générateur n'enregistre ni ne déploie rien, et contrairement au générateur CSP, il ne note pas la politique. Il vous fournit les headers, et vous les ajoutez à votre site. Chaque export, les headers en TXT ou le tableau de revue en CSV, est consigné dans le journal d'audit.

Fonctionnement

Le générateur fonctionne en quatre étapes. Chaque étape reprend la réponse de la précédente.

Période : choisissez les jours de reports à analyser, jusqu'aux 30 derniers.
Politique de départ : partez d'un préréglage, par défaut celui qui refuse toutes les fonctionnalités listées, ou collez la politique que vous envoyez aujourd'hui.
Revoir les fonctionnalités : accordez ou rejetez chaque fonctionnalité, pour vos propres pages et pour chaque origine d'iframe. Chaque ligne arrive déjà tranchée : ce que vos pages et iframes ont utilisé est accordé, et le bruit ainsi que les fonctionnalités appelées uniquement par un script tiers arrivent rejetés.
Déployer : choisissez le mode report-only ou bloquant, et copiez les headers.

Les réglages par défaut conservent ce que vos pages et iframes ont utilisé sur la période, et refusent le reste du catalogue.

Le générateur Permissions-Policy à l’étape Période, avec 7 jours sélectionnés, le graphique des reports et les compteurs Rapports, Fonctionnalités utilisées et Semblent être du bruit

D'où viennent les données

Le générateur lit deux types de report que votre site collecte déjà :

Un report de violation Permissions-Policy, envoyé quand l'une de vos pages utilise une fonctionnalité que la politique bloque. Il devient une autorisation pour self.
Un report potential-permissions-policy-violation, envoyé quand l'attribut allow d'une iframe demande une fonctionnalité. Il devient une autorisation pour l'origine de cette iframe.

La page Reports Permissions Policy montre les mêmes données, dans ses vues Violations et Potentielles. Pour comprendre pourquoi la vue Potentielles compte avant de passer en mode bloquant, consultez Vérifiez Potentiel avant de faire appliquer.

Pourquoi il n'y a pas de politique détectée

Un report CSP contient la politique qui l'a produit, le générateur CSP peut donc détecter la politique que vous servez. Un report Permissions-Policy ne contient jamais la politique servie. Le générateur ne peut pas voir ce que vous envoyez aujourd'hui, il part donc d'un préréglage, ou de la politique que vous collez. La revue ajoute ensuite ce que votre site a utilisé d'après les reports.

Pour savoir comment le générateur transforme les reports en autorisations, repère le bruit et écrit le header, consultez Règles de décision du générateur.

Utilisation depuis l'API et le serveur MCP

L'API REST construit la même politique sans l'assistant. L'endpoint Build a recommended Permissions-Policy accepte une période et une politique de départ, toutes deux facultatives, et renvoie deux valeurs de header : policy pour le header Permissions-Policy et reportingEndpoints pour le header Reporting-Endpoints. Sans politique de départ, il refuse toutes les fonctionnalités listées, puis rend ce que vos pages et iframes ont utilisé, en laissant de côté le bruit et les fonctionnalités appelées uniquement par des scripts tiers. Consultez la référence de l'API.

Le serveur Model Context Protocol (MCP) expose cet endpoint sous la forme de l'outil build_recommended_permissions_policy.