Générateur de header CSP
Construire, importer et vérifier un header Content Security Policy dans ton navigateur, puis copier des snippets pour Apache, Nginx, Netlify et Vercel.
Ce générateur de header Content Security Policy écrit une CSP que tu peux vraiment mettre en prod, directement dans ton navigateur, donc rien de ce que tu colles ne quitte la page. Pars d'un profil pour WordPress, un site statique, un dashboard SaaS, un strict starter ou une API, ou colle un header que tu fais déjà tourner et laisse l'outil démêler les directives. Il corrige discrètement les guillemets courbes que WordPress massacre, puis signale ce qui est risqué : unsafe-inline, unsafe-eval, les wildcards et les sources en simple http, et il note le résultat. Choisis report-only ou enforce, ajoute un nonce et un endpoint de rapport, puis copie des snippets prêts pour Apache, Nginx, Netlify, Vercel et un fallback en meta tag. Un panneau de déploiement trace le chemin sûr, parce que le bon réflexe est de tester en report-only avant de forcer quoi que ce soit en prod.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Constructeur, importeur, vérificateur de risques et générateur de snippets serveur pour Content Security Policy
Une CSP que j'avais écrite à la main a fait tomber un site pendant vingt minutes. J'avais oublié l'hôte d'analytics. Du coup j'ai bâti ça pour ne plus jamais refaire exactement cette erreur. Tu choisis un preset (WordPress, un site statique, un dashboard, une API) ou tu colles un header que tu fais déjà tourner, et l'outil démêle le truc. Il signale ce qui est risqué. Il t'écrit un header en report-only ou en enforce. Puis il te file des snippets que tu colles direct dans Apache ou Nginx ou Netlify ou Vercel. Et franchement, il te tanne pour que tu testes d'abord, parce que cette leçon-là, je l'ai apprise avec un site en prod et une grosse boule au ventre.
Sors le header en report-only d'abord. Crois-moi sur ce coup-là. Une CSP, ça paie son écot. Mais déploie-la en enforce avec un seul hôte manquant et tes pubs s'éteignent, tes analytics arrêtent de remonter, tes embeds et tes formulaires meurent en silence, et la moitié de tes plugins se mettent à râler.
Un générateur de header Content Security Policy se déploie avec soin, pas en copier-coller aveugle
Bon, voilà le topo avec une CSP. Le bon jour, elle émousse le cross-site scripting et claque la porte au mixed content et à tout le bazar tiers que tu n'as jamais demandé. Le mauvais jour, une seule source manquante et elle flingue un script, une feuille de style, une police, une image, un embed, un formulaire ou tes analytics, et la page casse, point. C'est toute cette tension qui m'a donné envie d'un builder qui me met le vrai header sous les yeux, me dit ce que je sacrifie au passage, signale le durcissement que j'oublie toujours, puis recrache les snippets pour que je teste avant que quoi que ce soit parte en prod.
C'est ce que fait l'outil. Pensé pour livrer, pas pour faire le malin. Il y a des profils pour WordPress, les sites statiques, le SaaS, et un strict starter dans lequel tu peux grandir. Il avale un header que tu colles, corrige discrètement les guillemets courbes que WordPress adore massacrer, et gueule à la seconde où il repère unsafe-inline, unsafe-eval, un wildcard ou une source en simple http. Report-only ou enforce, c'est toi qui vois. Des snippets pour Apache, Nginx, Netlify, Vercel, plus un fallback en meta tag pour quand tu es coincé. Je ne te promets pas une policy parfaite en un clic. Personne ne peut. Je veux juste que tu en livres une meilleure sans mettre la prod par terre.
Comment tester une Content Security Policy
Bascule-la en report-only. Puis clique vraiment partout sur les pages qui rapportent ou qui font du vrai boulot : la home, un article, le login, tout ce qui a un formulaire ou un checkout, un embed YouTube, un emplacement pub, tes analytics, les commentaires, les écrans d'admin. Ouvre la console. Lis ce dont elle se plaint, et rajoute uniquement les hôtes que tu utilises pour de vrai. Ne sois pas feignant à coller un wildcard. Une fois que les rapports arrêtent de hurler, tu peux passer en enforce, et garde un oeil dessus à chaque fois que tu touches un plugin, un thème ou quoi que ce soit dans tag manager, parce que c'est en général ça qui casse le truc d'après.
- default-src, c'est ton filet de sécurité. C'est le fallback quand rien de plus précis ne correspond.
- script-src, c'est celle qui m'empêche de dormir, parce que les scripts, c'est là que le XSS te tombe dessus pour de vrai.
- object-src 'none' élimine les vieilleries de plugins façon Flash dont tu ne voudras plus jamais.
- base-uri 'self' empêche un base tag injecté de réécrire tranquillement la cible de tes URLs.
- frame-ancestors décide qui a le droit de mettre ta page dans une iframe. Les clickjackers, eux, n'y ont pas droit.
Exemples courants de debug CSP
Un script qui se fait bloquer ? Rajoute l'hôte exact dont elle se plaint, pas un wildcard que tu regretteras d'ici vendredi. Coincé avec des inline scripts parce que WordPress ou tag manager refusent de lâcher ? Reste en report-only et note un nonce, ou un refactor, pour plus tard. Mais ne masque pas le problème. Les polices qui ne chargent pas, c'est le grand classique, parce que deux directives sont en jeu en même temps : style-src pour la feuille de style du fournisseur CSS, et font-src pour les fichiers de police eux-mêmes. Cette deuxième-là, les gens l'oublient à chaque fois. Embed YouTube disparu ? Presque toujours un frame-src à qui il manque l'hôte YouTube. Et quand un formulaire arrête d'envoyer en silence et que tu n'as vraiment aucune idée du pourquoi, va regarder form-action en premier.
Sources et pour aller plus loin
Questions fréquentes
Faut-il commencer en report-only ?
Toujours. Sur un site en prod, je n'envisage même pas une autre façon de faire. Le report-only balance chaque violation dans la console sans rien casser du tout pour tes visiteurs, donc tu vois le tableau complet avant qu'un seul utilisateur ne remarque que quelque chose cloche.
unsafe-inline, c'est toujours mauvais ?
Ça perce un trou dans la protection exacte que tu es en train de monter. Donc oui, pas top. Je me trompe peut-être, mais je le tolère un temps sur un site WordPress retors qui ne veut pas se tenir, rangé dans la dette que je dois et que je compte rembourser. Jamais un réglage que je laisse là pour toujours de gaieté de coeur.
Est-ce que je peux mettre la CSP dans un meta tag ?
Tu peux. Une fois tous les trente-six du mois, tu y es obligé. Mais un vrai header HTTP gagne à chaque fois, parce qu'il est plus fiable et qu'il porte des directives qu'un meta tag ne sait tout simplement pas exprimer. Je ne descends au meta tag que quand poser des headers est vraiment hors de portée, genre sur un hébergement mutualisé verrouillé.
Contre quoi protège une Content Security Policy ?
Surtout contre le cross-site scripting et le contenu injecté. Tu lui donnes la liste des hôtes depuis lesquels tes scripts, tes styles et tout le reste ont le droit de charger. Tout ce qui n'est pas sur cette liste, y compris du code qu'un attaquant glisse en douce, ne s'exécute jamais.
Pourquoi éviter unsafe-inline et unsafe-eval ?
Ils te rendent la clé même que la CSP était censée retirer. unsafe-inline laisse tourner les inline scripts injectés. unsafe-eval transforme des chaînes en code vivant, ce qui est exactement le truc que tu cherches à empêcher. Pour les bouts d'inline que tu ne peux vraiment pas éviter, prends plutôt un nonce ou un hash.
Comment déployer une CSP sans casser le site ?
Commence par Content-Security-Policy-Report-Only, comme ça les violations s'accumulent dans tes rapports pendant que rien n'est réellement bloqué. Descends la liste et autorise les sources légitimes. Ce n'est qu'une fois les rapports devenus silencieux que tu glisses le header en enforce. Lent et un peu ennuyeux, c'est la bonne approche.