ESC

Directives CSP

Sortie Générée

Configurez les directives pour générer votre en-tête CSP...
Configurez les directives pour générer votre en-tête CSP...
Configurez les directives pour générer votre en-tête CSP...
Configurez les directives pour générer votre en-tête CSP...
Tout le traitement se fait dans votre navigateur. Aucune donnée n'est envoyée à un serveur.

Exemples d'Utilisation

Politique Restrictive de Base

Une politique simple qui n'autorise que les ressources de votre propre domaine, avec des styles en ligne et des URIs de données pour les images.

Politique Compatible CDN

Une politique permettant de charger des scripts et styles depuis des CDN populaires comme jsDelivr, cdnjs et Google Fonts.

Politique de Sécurité Stricte

Une politique hautement restrictive qui bloque tout par défaut et n'autorise que des types de ressources spécifiques depuis votre domaine.

Fonctionnalités

Constructeur Visuel

Construisez votre en-tête CSP visuellement avec des cases à cocher et des menus déroulants, sans syntaxe manuelle

Configurations Serveur

Obtenez des extraits de configuration prêts à l'emploi pour Nginx, Apache et balises meta

Validation CSP

Testez votre CSP pour les problèmes de sécurité courants et les violations des bonnes pratiques

Confidentialité d'Abord

Tout le traitement se fait localement dans votre navigateur, aucune donnée envoyée aux serveurs

Comment Utiliser ?

1

Sélectionner les Directives

Activez les directives CSP dont vous avez besoin et choisissez les sources pour chacune en utilisant les cases à cocher ou les domaines personnalisés.

2

Vérifier la Sortie

Visualisez votre CSP généré comme en-tête HTTP, balise meta ou extrait de configuration serveur. Testez-le pour détecter les problèmes.

3

Copier et Déployer

Copiez le CSP généré et ajoutez-le à votre configuration de serveur web ou votre document HTML.

Questions Fréquentes

Content Security Policy (CSP) est un en-tête de réponse HTTP qui indique au navigateur quelles sources de contenu il doit approuver. Sa défense principale est contre les attaques XSS (Cross-Site Scripting). CSP protège également contre les attaques par injection de données, le clickjacking (avec frame-ancestors) et les problèmes de contenu mixte.

default-src est le fallback pour tout type de ressource qui n'a pas sa propre directive spécifique. Définissez toujours default-src comme base ; cela garantit que les types de ressources oubliés ont un comportement restrictif par défaut plutôt qu'aucune restriction.

unsafe-inline autorise tous les scripts et styles inline, ce qui annule la majeure partie de la protection XSS. Les nonces sont plus sûrs : le serveur génère un nonce aléatoire par requête et l'ajoute à l'en-tête CSP et à chaque balise script inline de confiance. Le navigateur n'exécute que les scripts inline avec un nonce correspondant, les scripts injectés ne peuvent donc pas le revendiquer.

report-uri indique au navigateur où envoyer des rapports JSON lors d'une violation CSP. Utilisez d'abord le mode Content-Security-Policy-Report-Only pour voir les violations sans rien bloquer, puis renforcez la politique en vous basant sur les rapports.

Mettez en liste blanche l'origin exact plutôt que d'utiliser des wildcards. Par exemple : script-src 'self' https://cdn.jsdelivr.net — et non script-src *. Pour Google Fonts, vous avez besoin à la fois de style-src https://fonts.googleapis.com et de font-src https://fonts.gstatic.com.

Oui, mais avec des limitations. Un meta tag fonctionne dans le head HTML, mais ne peut pas utiliser les directives frame-ancestors, report-uri ou sandbox. De plus, le meta tag ne protège que les ressources chargées après que le navigateur l'ait analysé. Les en-têtes HTTP sont fortement préférés pour une protection complète.

L'absence de default-src (pas de directive fallback), l'utilisation de unsafe-inline dans script-src ou style-src, l'utilisation de unsafe-eval (permet l'exécution dynamique de code) et les origins wildcard (*). Ce sont les erreurs CSP les plus fréquentes trouvées lors des audits de sécurité.

Non. Tout fonctionne dans votre navigateur. Rien n'est envoyé à un serveur ni stocké nulle part.

Qu'est-ce que Content Security Policy ?

Content Security Policy (CSP) est un en-tete HTTP qui dit au navigateur quelles sources de contenu il doit approuver. Voyez-le comme une liste blanche: si un script, feuille de style, image ou police ne vient pas d'une source approuvee, le navigateur le bloque. C'est votre defense la plus forte contre les attaques XSS.

Pourquoi la syntaxe CSP est penible a ecrire a la main

Un en-tete CSP reel peut facilement faire 500+ caracteres avec des dizaines de directives. Un point-virgule mal place casse tout. Cet outil vous donne une interface visuelle: cases a cocher, menus deroulants et champs de domaines personnalises qui generent automatiquement une syntaxe CSP valide.

Les erreurs CSP les plus courantes

La plus grande est d'utiliser unsafe-inline pour les scripts. La deuxieme est l'origine wildcard (*). La troisieme est d'oublier default-src. Cet outil a un validateur integre qui signale tous ces problemes.

Demarrer avec CSP

Commencez avec une politique en mode rapport uniquement pour voir ce qui casserait sans bloquer quoi que ce soit. Surveillez les rapports, corrigez les violations, puis passez en mode application.

Confidentialite

Votre configuration CSP ne quitte jamais votre navigateur. Pas d'appels serveur, pas de stockage, pas de tracking.

Sécurité et Confidentialité

La sécurité de vos données est notre priorité

Traitement Local

Tout le traitement se fait dans votre navigateur

Aucun Transfert de Données

Vos données ne sont pas envoyées à nos serveurs

Aucun Stockage de Données

Aucune donnée n'est stockée ou partagée

Chiffrement SSL

Chiffrement SSL pour une connexion sécurisée

Aussi sur MoreOnlineTools