Règles de décision du générateur

Le générateur de politique de sécurité du contenu (CSP) suggère chaque valeur à partir de 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.

Du report à la source

Chaque report de violation CSP cite une directive et ce que le navigateur a bloqué. Le générateur en tire la valeur qui l'autoriserait :

Le générateur suggère des origines, pas des chemins complets. Une entrée par origine garde la politique courte, et elle reste valable quand un fournisseur renomme un fichier.

Les reports causés par une extension de navigateur, comme une URL chrome-extension://, ne deviennent jamais une source. Votre site ne les charge pas, et une politique ne peut pas les autoriser. Pour les écarter avant leur stockage, consultez Ignorer les reports des extensions de navigateur.

Les reports qui ne citent rien qu'une politique puisse autoriser, comme une violation Trusted Types, sont eux aussi écartés. Le tableau de revue les compte dans une remarque.

Bruit

Le bruit est une source reportée dont vos pages n'ont pas besoin. La cause habituelle est un logiciel installé sur la machine du visiteur, comme un antivirus ou un injecteur de publicités, qui ajoute des scripts à chaque page. L'autoriser élargit la politique pour rien.

Le générateur classe une source comme bruit dans chacun de ces cas :

• L'hôte appartient à un outil connu pour injecter du contenu dans les pages, comme un antivirus, une extension de navigateur telle que Grammarly ou Honey, ou un réseau d'adware.
• La source a très peu de reports, et ils représentent une part infime des reports de sa directive.
• La source n'apparaît que sur quelques jours de la période, et un seul navigateur l'a reportée alors que votre site en voit plusieurs.

L'encadré Détectée comme du bruit, rejetée d’office du panneau de détails indique lequel de ces cas s'applique, avec les chiffres correspondants.

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 n'apparaître que par à-coups et pourtant être réelle. Vérifiez le filtre Bruit avant de déployer.

Politiques détectées

Chaque report CSP transporte la politique qui l'a produit. Le générateur regroupe les reports par politique et classe les politiques selon la probabilité que votre site serve chacune aujourd'hui. Une politique reportée souvent et récemment arrive en tête, si bien qu'une politique déployée hier passe devant une politique restée en place un an avant d'être remplacée.

Chaque politique détectée reçoit l'un de ces trois libellés :

Après un déploiement, votre politique précédente peut garder le libellé en service pendant quelques heures. Les visiteurs conservent des pages en cache qui envoient encore l'ancien header.

Le générateur affiche jusqu'à six politiques détectées. Quand l'une d'elles est en service, c'est la politique de départ par défaut. Sinon, la valeur par défaut est la base CentralCSP.

La base CentralCSP

La base est la politique que CentralCSP recommande comme point de départ sûr pour tout site. Elle n'autorise que votre propre origine, et elle reporte chaque script qui se charge :

Les deux mots-clés de reporting n'autorisent rien. 'report-sample' ajoute le début du code inline bloqué à son report. 'report-sha256' reporte le hash de chaque script qui se charge, ce qui alimente l'inventaire de scripts. Les deux sont sans risque dans une politique appliquée.

Si vous encadrez vos propres pages, réglez frame-ancestors sur 'self' au lieu de 'none'.

Quand vous partez de votre propre politique

Le générateur conserve chaque valeur de la politique détectée et la complète avec la base :

• Une directive de la base absente de votre politique est ajoutée. Une directive de ressource manquante reprend les valeurs de sa directive de repli, comme default-src, pour ne jamais restreindre ce qui se charge déjà.
• Un mot-clé de la base absent de votre politique, comme 'report-sample', est ajouté à la directive.
• Un script-src qui utilise un nonce reçoit 'strict-dynamic'. Les scripts chargés par vos scripts porteurs du nonce sont alors approuvés eux aussi.

Ces ajouts apparaissent comme Recommandé dans le tableau de revue. Chacun peut être rejeté comme n'importe quelle autre valeur.

Un nonce de votre politique revient sous la forme du placeholder 'nonce-{RANDOM}'. Votre serveur doit le remplacer par une nouvelle valeur aléatoire à chaque réponse. Un nonce fixe ne protège rien. Consultez Nonces et unsafe-inline.

Signalements de risque

Le générateur note la politique avec la même analyse que l'évaluateur CSP. Chaque ligne porte sa pastille de risque avant que vous ne décidiez, y compris les valeurs que vous n'avez pas ajoutées.

Les signalements de risque ne changent jamais une décision à eux seuls. Une valeur risquée que vos pages chargent reste ajoutée. La retirer demande d'abord une modification de votre code, et le panneau de détails décrit cette modification.

Si l'analyse n'est pas disponible, le générateur fonctionne quand même. Les pastilles de risque manquent et l'étape de déploiement affiche Analyse indisponible jusqu'à ce que vous réessayiez.

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.

L'API applique les mêmes limites. L'endpoint Build a recommended CSP utilise par défaut les 7 derniers jours, et chaque utilisateur peut l'appeler 10 fois par minute. Consultez la référence de l'API.

Étapes suivantes

• Tableau de revue
• Retirer une valeur risquée
• Violations CSP
• Référence Content Security Policy