Générateur de Content Security Policy

Comment construire une politique

1. Choisissez un point de départ dans Partir d’un modèle : Stricte (nonce + strict-dynamic), Site statique verrouillé, Site web classique ou Classique + Google Analytics / Ads. L’éditeur s’ouvre sur le modèle « site web classique ».
2. Ajustez les Directives. Chaque champ accepte des sources séparées par des espaces ; un champ vide omet la directive.
3. Utilisez l’Ajout rapide pour ajouter un mot-clé à la Directive choisie : 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data:… Ajouter un nonce insère un nonce aléatoire de 128 bits.
4. Pour autoriser un script en ligne précis sans 'unsafe-inline', collez-le (ou le HTML qui l’entoure) dans Hacher un script ou un style en ligne et cliquez sur Calculer le SHA-256 et l’ajouter.
5. Cochez upgrade-insecure-requests si d’anciennes URL utilisent encore http://, et indiquez si besoin une URL de réception des rapports.
6. Copiez l’En-tête HTTP, l’En-tête Report-Only ou la Balise HTML . L’Analyse de cette politique se met à jour pendant la saisie.

Pour auditer une politique existante, collez-la dans Évaluer une politique existante et cliquez sur Évaluer la politique ; Charger dans l’éditeur la recopie dans les champs.

À quoi sert une Content Security Policy

Une CSP indique au navigateur depuis quelles origines la page peut charger scripts, styles, images, polices, cadres et connexions. Son rôle principal est de limiter le cross-site scripting (XSS) : même si un attaquant parvient à injecter du balisage dans votre page, une bonne politique empêche le script injecté de s’exécuter. Elle contrôle aussi qui peut intégrer votre page dans un cadre (frame-ancestors), où les formulaires peuvent envoyer leurs données (form-action) et vers quoi <base> peut pointer (base-uri).

Les directives de récupération comme img-src ou font-src se replient sur default-src quand elles sont absentes. base-uri, form-action et frame-ancestors n’ont pas de repli : c’est pourquoi l’analyse les réclame explicitement.

Nonces, hashs et strict-dynamic

Autoriser des hôtes (script-src https://cdn.exemple.com) semble sûr mais se contourne souvent : les grands domaines hébergent des points d’accès JSONP et de vieilles bibliothèques qu’un attaquant peut réutiliser. L’approche recommandée par les équipes de sécurité des navigateurs est une CSP stricte : chaque <script> légitime porte un nonce généré par le serveur à chaque réponse, ou est autorisé par son hash, et 'strict-dynamic' permet à ces scripts de confiance de charger ceux dont ils ont besoin. Dans ce cas, https: et 'unsafe-inline' ne servent que de repli pour les très vieux navigateurs ; les navigateurs récents les ignorent.

Un nonce n’est efficace que s’il change à chaque réponse et reste imprévisible. Celui qu’insère Ajouter un nonce n’est qu’un exemple : votre serveur ou votre framework doit générer le sien. Un hash porte sur les octets exacts du code en ligne : reformater le script impose de recalculer le hash.

En-tête, Report-Only et balise meta

Envoyez la politique dans un en-tête de réponse HTTP chaque fois que c’est possible. Déployez-la d’abord en Content-Security-Policy-Report-Only : les navigateurs signalent les violations (dans la console, et à votre point de réception si vous en avez un) sans rien bloquer, ce qui laisse le temps de corriger les pages avant d’appliquer la politique. Les réglages de rapport ajoutent report-uri pour les anciens navigateurs et report-to avec un en-tête Reporting-Endpoints.

La version <meta http-equiv> dépanne sur un hébergement statique, mais les navigateurs y ignorent frame-ancestors, report-uri, report-to et sandbox, et il n’existe pas de balise meta Report-Only. L’outil retire ces directives de la balise et le signale.