# Règles de décision du générateur (/fr/docs/platform/features/builders/permissions-policy/how-it-decides) Le générateur Permissions-Policy propose chaque autorisation selon des règles que vous pouvez vérifier. Les connaître vous indique quand faire confiance à un réglage par défaut et quand passer outre. ## D'un report à une autorisation [#dun-report-à-une-autorisation] Le générateur lit deux types de report. Chaque report nomme une fonctionnalité et qui l'a demandée, et le générateur en tire l'autorisation qui la permettrait : | Ce que le navigateur a reporté | Autorisation suggérée | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Une [violation Permissions-Policy](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation) : l'une de vos pages a utilisé la fonctionnalité | `self` | | Une `potential-permissions-policy-violation` : une iframe d'une autre origine a demandé la fonctionnalité dans son attribut `allow` | L'origine de l'iframe, par exemple `"https://pay.example.com"`, signalée **Depuis un cadre** | | Une violation potentielle venant d'une iframe sans origine (un `src` relatif ou une iframe `srcdoc`), ou de votre propre origine | `self` | Le générateur accorde des origines, pas des URL complètes. Une iframe chargée depuis `https://pay.example.com/checkout?step=2` devient une autorisation pour `https://pay.example.com`. Les deux types de report peuvent être forgés par toute personne qui connaît votre endpoint. Un nom de fonctionnalité que la grammaire du header n'admet pas, ou un `src` d'iframe qui n'est pas une simple origine `http` ou `https`, ne devient jamais une ligne, il ne peut donc pas atteindre un header généré. ### Iframes et violations potentielles [#iframes-et-violations-potentielles] Une iframe demande une fonctionnalité dans son attribut `allow`. Le navigateur reporte cette demande comme une violation potentielle, que la page [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) affiche dans sa vue **Potentielles** : ```html title="product.html" ``` Cette iframe produit une ligne sous `fullscreen` et une sous `autoplay`, toutes deux pour `https://video.example.com`. Déléguer une fonctionnalité demande les deux moitiés : le header l'accorde à l'origine de l'iframe, et l'iframe continue de la nommer dans `allow`. Pour le modèle du header et de l'attribut, consultez [l'attribut allow des iframes](/fr/blog/permissions-policy-explained#comment-il-se-rapporte-à-lattribut-allow-des-iframes). Quand vous accordez une fonctionnalité à une origine d'iframe, l'étape de déploiement affiche **Les iframes ont aussi besoin de leur attribut allow** en guise de rappel. ### Scripts tiers [#scripts-tiers] Pour une fonctionnalité utilisée par vos propres pages, les reports nomment le script à l'origine de chaque appel. Le générateur classe chaque script dans l'un de trois groupes : votre propre code (servi depuis l'origine de votre site), le script d'une autre origine, ou une extension de navigateur. Quand tous les appels venaient du script d'une autre origine ou d'une extension, la ligne `self` est signalée **Script tiers** et arrive rejetée. Accorder la fonctionnalité à `self` la donnerait aussi à ce script, car un script s'exécute avec les permissions de la page qui le charge. Quand au moins un appel venait de votre propre code, la ligne arrive accordée. ## Bruit [#bruit] Le bruit est une ligne reportée dont votre site n'a pas besoin. Le générateur signale une ligne comme bruit dans l'un de ces cas : * Elle compte moins de 10 reports sur la période. * Chaque appel derrière elle venait d'une extension de navigateur, qui tourne sur la machine du visiteur, pas sur votre site. Le panneau de détails signale aussi quand un seul navigateur a reporté une ligne alors que votre site en voit plusieurs, mais ce signal ne suffit jamais à faire d'une ligne du bruit. Seuls les navigateurs Chromium envoient ces reports, la plupart des sites ne voient donc qu'un seul navigateur. Le bruit arrive rejeté, mais ce n'est qu'un réglage par défaut. Une page rarement utilisée, comme une campagne annuelle, peut reporter une fonctionnalité moins de 10 fois et en avoir quand même besoin. Vérifiez le filtre **Bruit** avant de déployer. ## Préréglages de départ [#préréglages-de-départ] Les navigateurs ne reportent jamais la Permissions-Policy avec laquelle une page a été servie, le générateur ne peut donc pas détecter la politique que vous envoyez aujourd'hui. Il part de l'une de ces options : | Politique de départ | Valeur | | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Refuser toutes les fonctionnalités listées** (par défaut) | Chaque fonctionnalité du [catalogue](#catalogue-des-fonctionnalités) définie à `()` | | **Base pour une page de paiement** | `payment=(self)` et `publickey-credentials-get=(self)`, toutes les autres fonctionnalités du catalogue définies à `()` | | **Autoriser la caméra et le microphone** | `camera=(self)`, `microphone=(self)` et `fullscreen=(self)`, toutes les autres fonctionnalités du catalogue définies à `()` | | **Votre propre politique** | La valeur que vous collez, jusqu'à 16 384 caractères | Une autorisation issue de la politique de départ reste accordée, même quand les reports la signalent. La revue ajoute ensuite ce que votre site a utilisé d'après les reports. ### Quand vous collez votre propre politique [#quand-vous-collez-votre-propre-politique] Le générateur lit la valeur comme une valeur de header Permissions-Policy, sans le nom du header : * Chaque fonctionnalité qu'elle définit est conservée, y compris les fonctionnalités hors du catalogue. * Dans chaque allowlist, il conserve `self`, `src`, `*` et les simples origines `http` ou `https`, et écarte tout le reste. * Il écarte les paramètres comme `report-to`, et ignore un membre qui n'a pas la forme `feature=allowlist`. * Une fonctionnalité du catalogue que votre politique ne définit pas garde le comportement par défaut du navigateur, sauf si les reports ou vos décisions l'ajoutent. Une politique collée n'existe que dans la page ouverte. Après un rechargement, le générateur revient à **Refuser toutes les fonctionnalités listées**. ## Catalogue des fonctionnalités [#catalogue-des-fonctionnalités] Le générateur liste 25 fonctionnalités, celles qui sont largement déployées et qu'il est utile de verrouiller. Les préréglages les définissent toutes, le header refuse donc chacune de celles que vous n'accordez pas : | Fonctionnalité | Ce qu'elle permet à une page | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | `accelerometer` | Lire le capteur de mouvement utilisé pour les gestes d'inclinaison et de secousse | | `autoplay` | Lancer une vidéo ou un son sans que le visiteur appuie sur lecture | | `browsing-topics` | Partager avec des scripts publicitaires les centres d'intérêt que le navigateur a déduits de l'historique du visiteur (l'API Topics) | | `camera` | Utiliser la caméra de l'appareil, une fois que le visiteur l'autorise | | `clipboard-read` | Lire ce que le visiteur a copié dans le presse-papiers | | `clipboard-write` | Écrire dans le presse-papiers, comme le fait un bouton Copier | | `display-capture` | Capturer l'écran ou une fenêtre, comme le fait le partage d'écran | | `encrypted-media` | Lire des vidéos ou des sons protégés par DRM via Encrypted Media Extensions | | `fullscreen` | Afficher un élément en plein écran, comme un lecteur vidéo ou une galerie | | `gamepad` | Lire les manettes de jeu | | `geolocation` | Lire la position du visiteur, une fois qu'il l'autorise | | `gyroscope` | Lire le capteur d'orientation de l'appareil | | `idle-detection` | Détecter quand le visiteur est inactif ou a verrouillé l'écran | | `local-fonts` | Lister et utiliser les polices installées sur l'appareil du visiteur | | `magnetometer` | Lire le capteur boussole de l'appareil | | `microphone` | Utiliser le microphone de l'appareil, une fois que le visiteur l'autorise | | `midi` | Communiquer avec des appareils MIDI comme des claviers musicaux | | `payment` | Ouvrir la fenêtre de paiement propre au navigateur (l'API Payment Request) | | `picture-in-picture` | Lire une vidéo dans une fenêtre flottante au-dessus des autres applications | | `publickey-credentials-get` | Connecter le visiteur avec une passkey ou une clé de sécurité | | `screen-wake-lock` | Garder l'écran allumé, par exemple pendant l'affichage d'une carte d'embarquement | | `serial` | Communiquer avec des périphériques série branchés à l'ordinateur | | `storage-access` | Permettre à un contenu tiers embarqué de demander l'accès à ses propres cookies | | `usb` | Communiquer avec des périphériques USB branchés à l'ordinateur | | `xr-spatial-tracking` | Lancer des sessions de réalité virtuelle et augmentée (WebXR) | Une fonctionnalité reportée hors du catalogue obtient elle aussi son propre groupe dans le tableau de revue, après les fonctionnalités du catalogue. Elle finit dans le header, soit accordée, soit sous la forme `()`. ## Écriture du header [#écriture-du-header] Le générateur écrit la politique sur une seule ligne, avec des virgules comme séparateurs : * Les fonctionnalités suivent l'ordre du catalogue, puis toute autre fonctionnalité par ordre alphabétique, pour que le header soit identique quel que soit le point de départ. * Une fonctionnalité accordée à personne s'écrit `()`, ce qui la refuse partout, y compris dans les iframes. * `self` vient en premier dans une allowlist, puis chaque origine entre guillemets doubles. * Une fonctionnalité accordée à `*` s'écrit `*` seul, quoi qu'elle liste d'autre. * Aucun paramètre `report-to` n'est écrit. Les reports partent vers l'endpoint `default` du header `Reporting-Endpoints`, que le générateur déclare à côté de `centralcsp`. Par exemple, une politique qui accorde `payment` à vos pages et à une iframe de paiement, et refuse le reste, se lit ainsi, raccourcie ici à cinq fonctionnalités : ```http Permissions-Policy-Report-Only: accelerometer=(), autoplay=(), browsing-topics=(), camera=(), payment=(self "https://pay.example.com") ``` Le vrai header liste toutes les fonctionnalités du catalogue. Pour l'exemple complet, consultez [Démarrer](/fr/docs/platform/features/builders/permissions-policy/get-started#4-déployer-en-mode-report-only). ## Périodes et limites [#périodes-et-limites] Le générateur lit jusqu'aux 30 derniers jours de reports. Un site qui envoie un très gros volume de reports est limité à 7 jours à la fois. Sur un tel site, l'étape **Période** affiche **Ce site envoie beaucoup de rapports : le générateur ne lit donc que ses 7 derniers jours**, et les options **14 jours** et **30 jours** sont masquées. Si une période contient plus de reports que le générateur ne peut en lire à temps, la page affiche **Cette période contient trop de rapports pour être analysée à temps. Choisissez une période plus courte.** Choisissez moins de jours et continuez. L'API applique les mêmes règles. L'endpoint **Build a recommended Permissions-Policy** porte par défaut sur les 7 derniers jours et couvre jusqu'à 30 jours. Sans politique de départ, il part de **Refuser toutes les fonctionnalités listées**. Chaque utilisateur peut l'appeler 10 fois par minute. Consultez la [référence de l'API](/fr/docs/api-mcp/api). ## Étapes suivantes [#étapes-suivantes] * [Tableau de revue](/fr/docs/platform/features/builders/permissions-policy/review-features) * [Démarrer](/fr/docs/platform/features/builders/permissions-policy/get-started) * [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) * [Report de violation Permissions-Policy](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation) * [Référence Permissions-Policy](/fr/docs/web-security/policies/permissions-policy)