Générateur CSP
Cybersécurité d'entreprise•Conforme RFC 3986 & W3C CSP3

Générateur Content Security Policy (CSP)

Générez des en-têtes Content Security Policy (CSP) sécurisés en un clic. Configurez script-src, style-src, nonces et empreintes SHA-256 pour bloquer les attaques XSS et éliminer les erreurs CSP.

100
Score OWASPNiveau renforcé (Grade A+)
Profils de sécurité prédéfinis :
1
Ingestion des directives AST
16 directives & analyseur lexical de balises
2
Nonces cryptographiques & Web Crypto
CSPRNG 128 bits & SHA-256
3
Audit statique des contournements OWASP
7 détecteurs de contournements critiques
4
Export multi-plateforme
Nginx, Caddy, Next.js, Apache
Paramètres & Directives
Profil d'architecture
Mode d'application de l'en-tête
Options de sécurité avancéesNiveau de spécification W3C Level 3
Compatibilité des niveaux W3C CSP
Générateur de Nonce CSPRNG Web Crypto & Hachage SHA-256
window.crypto.subtle
Préfixe du noncedG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg==
Générateur d'empreinte SHA-256 pour scripts inline :'sha256-RFWzHiTAeaP0v89upId2U1QGEGNhBlCe/JC9Zdqvqo='
Injecteurs de services vérifiés (Allowlist) :
default-srcDirectives de chargement (Fetch)Aucun repli (Non hérité)
Universal fallback boundary for all fetch directives when omitted.
'self'
script-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources for JavaScript execution and inline scripts.
'self''strict-dynamic''nonce-dG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg=='https:'unsafe-inline'
style-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources for stylesheets, inline styles, and CSS fonts.
'self''unsafe-inline'
img-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources of images, SVG vectors, and favicons.
'self'data:https:
connect-srcDirectives de chargement (Fetch)Hérite de default-src
Restricts script interfaces: fetch(), XMLHttpRequest, WebSocket, and sendBeacon.
'self'
font-srcDirectives de chargement (Fetch)Hérite de default-src
Governs sources for web fonts loaded via @font-face rules.
'self'data:
object-srcDirectives de chargement (Fetch)Hérite de default-src
Restricts plugins (<object>, <embed>, <applet>). OWASP mandates 'none'.
'none'
media-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources for <audio> and <video> HTML5 media streams.
(Se replie sur default-src si non renseigné)
frame-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources for nested browsing contexts (child <iframe> elements).
(Se replie sur default-src si non renseigné)
worker-srcDirectives de chargement (Fetch)Hérite de default-src
Restricts Worker, SharedWorker, and ServiceWorker execution origins.
(Se replie sur default-src si non renseigné)
manifest-srcDirectives de chargement (Fetch)Hérite de default-src
Governs valid sources of progressive web application (PWA) manifests.
(Se replie sur default-src si non renseigné)
base-uriDirectives de documentAucun repli (Non hérité)
Restricts URLs in <base> tags. CRITICAL: does NOT inherit from default-src!
'none'
form-actionDirectives de navigationAucun repli (Non hérité)
Restricts target submission endpoints for HTML <form> elements.
'self'
frame-ancestorsDirectives de documentAucun repli (Non hérité)
Clickjacking Armor: restricts parents embedding this site. HTTP header only!
'none'
report-uriReportingAucun repli (Non hérité)
Legacy URI collector endpoint for W3C CSP Level 2 violation reports.
(Explicitement sans restriction — déconseillé)
report-toReportingAucun repli (Non hérité)
Modern W3C Reporting API endpoint group identifier.
(Explicitement sans restriction — déconseillé)
Directives actives : 11Sources configurées : 18
Moderne strict (Nonce + Hashes)
Content-Security-Policy: upgrade-insecure-requests; default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-dG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg==' https: 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; font-src 'self' data:; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; require-trusted-types-for 'script'; trusted-types default dompurify

# Recommended Defense-in-Depth Headers:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
En-tête HTTP : Content-Security-Policy
Traitement 100 % en mémoire locale
Indicateur principal100Échelle des scores
Efficacité & Couverture11 directives18 sources
Rendu finalActif (Enforce)

Traitement côté client

Calcul haute performance exécuté intégralement dans la mémoire du navigateur.

Confidentialité & Zéro transfert serveur

Toutes les configurations restent strictement locales, sans aucune transmission vers des serveurs tiers.

Export prêt pour la production

Formats nettoyés et optimisés, prêts pour un déploiement immédiat en production.

Référence technique et guide d'architecture

Générateur CSP & Content Security Policy — Guide de référence

Générez instantanément des en-têtes Content Security Policy (CSP) robustes. Configurez script-src, style-src, nonces et empreintes de hachage pour bloquer les attaques XSS et corriger les erreurs de violation CSP.

Générateur CSP & Content Security Policy — Guide de référence — Architecture en mémoire côté client et flux de données
Générateur CSP & Content Security Policy — Guide de référence — Architecture en mémoire côté client et flux de données

Paramètres clés et contrôles

default-src (Périmètre de repli du chargement)Liste de sources (repli W3C fetch)

Fait office de directive de repli universelle pour l'ensemble des directives de chargement de ressources (script-src, style-src, img-src, connect-src, font-src, object-src, media-src, frame-src, worker-src, manifest-src). Définir 'self' restreint les catégories non attribuées à l'origine courante, tandis que définir 'none' impose une déclaration explicite absolue pour chaque type de ressource.

Par défaut : 'self' (Repli sur l'origine uniquement)
script-src & 'strict-dynamic' (Protection contre l'exécution XSS)Liste de sources & expressions de mots-clés

Régule les origines d'exécution JavaScript afin de prévenir les attaques par injection de scripts (XSS). Dans la spécification W3C CSP Level 3, l'association d'un nonce cryptographique ou d'une empreinte de hachage avec 'strict-dynamic' ordonne aux navigateurs modernes d'accorder leur confiance aux scripts créés dynamiquement par des scripts racines autorisés, tout en ignorant les listes blanches d'hôtes héritées et 'unsafe-inline'.

Par défaut : 'self' 'strict-dynamic' 'nonce-...' (Mode strict moderne)
object-src & base-uri (Défense contre les plugins & injection de base)Liste de sources (intégrité du document)

object-src restreint les extensions obsolètes telles que Flash, Java et Silverlight ; la valeur 'none' constitue une exigence fondamentale de l'OWASP et de l'ANSSI. base-uri restreint les URL autorisées dans les balises HTML <base href>. Point critique : base-uri n'hérite PAS de default-src ; son omission expose donc le site à des attaques par injection de balise <base> détournant les URL relatives des scripts.

Par défaut : object-src 'none'; base-uri 'none'
frame-ancestors (Protection anti-clickjacking & détournement d'interface)Politique d'encadrement (en-tête de réponse HTTP uniquement)

Spécifie les contextes parents autorisés à intégrer la page au sein de balises <frame>, <iframe>, <embed> ou <applet>, remplaçant avantageusement l'en-tête obsolète X-Frame-Options. Définir 'none' interdit toute intégration externe (neutralisant le détournement de clic ou clickjacking), tandis que 'self' n'autorise l'encadrement que par la même origine. Remarque : frame-ancestors est totalement ignorée au sein des balises HTML <meta>.

Par défaut : 'none' ou 'self' (Protection anti-clickjacking)
connect-src (Périmètre API & prévention d'exfiltration)Liste d'origines URL (fetch / XHR / WebSocket)

Restreint les URL cibles pouvant être sollicitées via des interfaces de script telles que fetch(), XMLHttpRequest, WebSocket (wss://), EventSource et navigator.sendBeacon(). Cette directive est essentielle pour empêcher l'exfiltration de données lorsqu'un script tiers compromis tente de transmettre des jetons de session ou des données sensibles vers des serveurs externes non autorisés.

Par défaut : 'self' (API sur l'origine courante uniquement)
upgrade-insecure-requests & report-to (Chiffrement du transport & télémétrie)Drapeau de directive & groupe de signalement

upgrade-insecure-requests intime aux navigateurs de convertir l'ensemble des URL HTTP non chiffrées en HTTPS avant tout chargement, prévenant ainsi les alertes de contenu mixte (mixed content). report-to définit le groupe de points de terminaison de la Reporting API vers lequel les navigateurs acheminent les rapports d'infraction au format JSON structuré, modernisant et supplantant la directive dépréciée report-uri.

Par défaut : upgrade-insecure-requests (Activé)

Conseils de pro et bonnes pratiques

'strict-dynamic' désactive totalement les listes blanches d'hôtes dans les navigateurs CSP3

Dès lors que 'strict-dynamic' est associé à un nonce ou à une empreinte de hachage dans script-src, les spécifications W3C CSP Level 3 imposent aux navigateurs d'ignorer systématiquement les listes blanches d'hôtes (telles que https: ou https://*.google.com) ainsi que 'unsafe-inline'. Les listes d'hôtes ne sont conservées dans l'en-tête qu'à titre de repli rétrocompatible pour les anciens navigateurs (CSP Level 2). Si vous employez 'strict-dynamic', ne comptez pas sur des listes blanches de domaines pour autoriser des scripts tiers : c'est le script chargeur racine qui doit obligatoirement porter le nonce !

L'absence de base-uri expose au détournement de scripts par injection HTML

Beaucoup d'ingénieurs pensent à tort que default-src 'self' verrouille l'intégralité du document. Or, base-uri n'hérite JAMAIS de default-src. En cas d'omission de base-uri, un attaquant exploitant une faille d'injection HTML mineure (comme un commentaire non échappé ou du markdown mal filtré) peut injecter <base href='https://attaquant-malveillant.com/'>. Le navigateur résoudra dès lors tous les scripts relatifs (par exemple <script src='/static/app.js'>) vers ce domaine hostile, contournant totalement votre politique script-src 'self'. Déclarez toujours expressément base-uri 'none' ou 'self'.

'unsafe-inline' est ignoré en toute sécurité en présence d'un nonce ou d'un hash en CSP2+

Si vous devez supporter d'anciens navigateurs limités à CSP Level 1 tout en assurant un niveau de protection optimal sur les moteurs modernes, vous pouvez déclarer sans risque : script-src 'nonce-XYZ123' 'unsafe-inline'. Conformément aux spécifications W3C CSP Level 2 et Level 3, la présence d'un nonce ou d'une empreinte cryptographique neutralise automatiquement l'instruction 'unsafe-inline' sur tout navigateur moderne. Cela garantit une rétrocompatibilité parfaite sans dégrader votre posture de sécurité.

default-src ne protège ni contre le clickjacking ni contre le détournement de formulaires

Une erreur fréquente consiste à croire que default-src 'none' verrouille l'ensemble des comportements de la page. En réalité, default-src ne régit que les directives de chargement (fetch directives). Elle n'exerce aucune influence sur frame-ancestors (qui empêche l'intégration furtive de votre site dans des iframes malveillantes à des fins de clickjacking) ni sur form-action (qui restreint les URL cibles de soumission des formulaires <form> transportant des identifiants sensibles). Vous devez impérativement déclarer frame-ancestors 'none'/'self' et form-action 'self' de manière explicite.

Pièges courants et dépannage

⚠️La console du navigateur affiche : Refused to execute inline script because it violates the following Content Security Policy directive: 'script-src 'self''

Cette infraction survient lorsqu'une balise <script> en ligne ou un gestionnaire d'événements HTML inline (comme onclick ou onload) tente de s'exécuter sans autorisation explicite. Pour remédier à cela selon les standards actuels : (1) Associez un nonce cryptographique à la balise de script (<script nonce='...'>) et déclarez ce même nonce dans script-src 'nonce-...' ; (2) Calculez l'empreinte de hachage SHA-256 du contenu textuel exact du script et intégrez 'sha256-...' dans script-src ; ou (3) Refactorisez les écouteurs inline dans des fichiers JavaScript externes liés au DOM via addEventListener.

⚠️L'appel d'API échoue avec : Refused to connect to 'https://api.example.com' because it violates connect-src

Les navigateurs modernes limitent les requêtes fetch(), XMLHttpRequest, WebSocket (wss://) et sendBeacon aux seules origines autorisées dans connect-src. Si connect-src n'est pas stipulée, le navigateur applique par défaut les règles de default-src. Si votre interface frontend communique avec une API backend distincte ou un service tiers (tel que Stripe, Sentry ou une passerelle d'API externe), déclarez expressément l'origine cible (par exemple connect-src 'self' https://api.example.com https://api.stripe.com) dans votre en-tête CSP.

⚠️L'empreinte SHA-256 déclarée dans script-src déclenche toujours une violation CSP sous Google Chrome ou Firefox

Le hachage de script pour la CSP s'effectue au bit près. Le moindre saut de ligne résiduel, une divergence de retour chariot (\r\n contre \n) ou un simple espace entre le contenu haché et le bloc exécuté dans la page produit une non-concordance cryptographique immédiate. De plus, ne prenez jamais en compte les balises ouvrantes <script> et fermantes </script> lors du calcul : hachez uniquement le code interne. Veillez enfin à ce que votre moteur de gabarits ou serveur ne reformate ni ne minifie le script après génération de l'empreinte.

⚠️La directive frame-ancestors semble être ignorée lorsqu'elle est déclarée dans une balise HTML <meta>

D'après les spécifications W3C relatives à la Content Security Policy, les directives frame-ancestors, report-uri et report-to sont formellement proscrites et ignorées au sein des balises HTML <meta http-equiv='Content-Security-Policy'>. Pour vous prémunir efficacement du clickjacking et activer frame-ancestors, la politique DOIT obligatoirement être transmise sous la forme d'un en-tête de réponse HTTP émis directement par votre serveur Web (par exemple via add_header sous Nginx, Header set sous Apache ou au sein d'un middleware Next.js).

Foire aux questions (FAQ)

Comment configurer une Content Security Policy pour bloquer les attaques XSS ?▼

Pour neutraliser les failles de type Cross-Site Scripting (XSS), déployez une politique stricte (Strict CSP) reposant sur des nonces ou des empreintes cryptographiques couplés à 'strict-dynamic' et object-src 'none'. Voici un en-tête de référence robuste : Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-RANDOM_BASE64' 'unsafe-inline'; object-src 'none'; base-uri 'none'; frame-ancestors 'none';. Cette configuration bloque l'exécution de scripts inline non signés, neutralise les vulnérabilités de plugins tiers et empêche le détournement d'URL via l'injection de balises <base>.

Quelle est la différence entre default-src et script-src dans une politique CSP ?▼

default-src constitue la directive de repli s'appliquant par défaut à tous les types de ressources ne disposant pas d'une directive dédiée (notamment script-src, style-src, img-src, connect-src et font-src). De son côté, script-src régit exclusivement les emplacements et conditions d'exécution des fichiers et scripts JavaScript. Dès que script-src est déclarée, elle supplante totalement default-src pour les scripts ; en son absence, le navigateur bascule sur les restrictions de default-src.

Pourquoi le mot-clé 'unsafe-inline' est-il considéré comme dangereux dans une CSP ?▼

Le mot-clé 'unsafe-inline' présente un risque majeur car il autorise le navigateur à exécuter n'importe quel code JavaScript présent dans le DOM, y compris les charges malveillantes injectées via des failles XSS stockées ou reflétées. L'activer sans garde-fou anéantit la protection fondamentale offerte par la CSP contre l'exécution de scripts arbitraires, à moins qu'il ne soit neutralisé par l'adjonction d'un nonce cryptographique ou de 'strict-dynamic', qui amènent les navigateurs modernes à ignorer délibérément ce mot-clé.

Comment fonctionnent les nonces CSP et de quelle manière sont-ils générés ?▼

Un nonce CSP (number used once) est un jeton aléatoire cryptographiquement sûr (généralement 128 bits encodés en Base64), généré dynamiquement côté serveur Web pour chaque requête HTTP unique. Le serveur transmet ce jeton dans l'en-tête HTTP (script-src 'nonce-abc123xyz') et applique l'attribut correspondant sur chaque balise de script légitime (<script nonce='abc123xyz'>). L'attaquant ne pouvant deviner ce jeton éphémère, tout script injecté à son insu est immédiatement bloqué par le navigateur.

Quelle est la différence entre Content-Security-Policy et son mode Report-Only ?▼

L'en-tête Content-Security-Policy applique activement la politique de sécurité en bloquant les scripts, connexions et feuilles de style en infraction tout en consignant les incidents. En revanche, Content-Security-Policy-Report-Only laisse les ressources non conformes se charger et s'exécuter normalement sans perturber l'expérience utilisateur, tout en envoyant des rapports d'infraction détaillés vers les points de terminaison configurés (report-to ou report-uri). Ce mode constitue le standard d'excellence pour auditer une application en production avant son verrouillage définitif.

Peut-on configurer une Content Security Policy à l'aide d'une balise HTML meta ?▼

Oui, une Content Security Policy peut être injectée via une balise HTML <meta http-equiv='Content-Security-Policy' content='...'> au sein de l'élément <head> de la page. Toutefois, les spécifications du W3C interdisent formellement les directives d'encadrement et de télémétrie dans les balises meta : des instructions capitales comme frame-ancestors, report-uri et report-to seront purement et simplement ignorées par le navigateur. Pour garantir une protection intégrale contre le clickjacking et bénéficier de la remontée d'incidents, la CSP doit impérativement être émise via un véritable en-tête de réponse HTTP.

Outils et utilitaires connexes

Tous les outils →
Générateur de Hachage Bcrypt et Vérificateur de Mots de PasseSécurité

Générez des hachages de mots de passe Eksblowfish avec rounds de salt réglables (4-16) et vérifiez les candidats localement dans le navigateur.

Ouvrir l'outil→
Générateur et Vérificateur de Signature HMACSécurité

Calculez et vérifiez les codes d'authentification de message RFC 2104 (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, HMAC-MD5) avec comparaison en temps constant (Timing-Safe) dans votre navigateur.

Ouvrir l'outil→
Chiffreur et Déchiffreur AES-GCM / CBC Côté ClientSécurité

Chiffrement authentifié matériel AES-256 exécuté directement dans votre navigateur via l'API Web Crypto. Zéro transmission serveur.

Ouvrir l'outil→
Générateur de Paires de Clés RSA (Publique & Privée)Sécurité

Générez des paires de clés RSA hautement sécurisées (2048 et 4096 bits) au format PEM PKCS#8 directement dans votre navigateur via l'API Web Crypto.

Ouvrir l'outil→
Encodeur et Décodeur Base58 / Base58CheckSécurité

Convertissez texte et chaînes hexadécimales vers le format Base58 utilisé par Bitcoin et IPFS avec vérification de somme de contrôle SHA-256.

Ouvrir l'outil→
Encodeur & Décodeur Base32 (RFC 4648 & Base32hex)Utilitaire

Encodez et décodez textes et données binaires en Base32 standard et Base32hex selon la RFC 4648 avec gestion du padding.

Ouvrir l'outil→