Ajouter une Content-Security-Policy sans casser votre site

Un scan de sécurité, un rapport Lighthouse ou votre hébergeur vous dit que le site n'a pas de Content-Security-Policy. La solution ressemble à un simple en-tête. Copier une politique trouvée sur un blog, la déployer, terminé. Puis le formulaire de réservation ne se charge plus, le widget de chat disparaît ou, pire, rien ne casse visiblement et vos Google Ads arrêtent de compter les conversions. Nous avons failli faire exactement cela sur notre propre site.

La réponse courte : commencez par Content-Security-Policy-Report-Only, pas par le vrai en-tête. Il signale ce que la politique bloquerait, sans rien bloquer. Collectez ces rapports auprès de vrais visiteurs pendant au moins une semaine, sur tous les types de pages, ajoutez ce qui est légitime, et ne passez à l'application qu'ensuite.

Ce que fait une Content-Security-Policy

C'est un en-tête HTTP qui indique au navigateur depuis quelles sources une page peut charger des scripts, des styles, des images, des polices, des frames et des connexions. Si un attaquant parvient à injecter un script (via une extension piratée, un script tiers compromis ou un formulaire qui ne nettoie pas ses entrées), le navigateur refuse de l'exécuter ou d'envoyer des données vers un serveur inconnu. C'est l'une des défenses les plus solides contre le cross-site scripting et les skimmers de cartes sur les pages de paiement.

Il est aussi courant de n'en avoir aucune. Quand nous avons analysé 1 482 boutiques en ligne avant le Black Friday, environ un tiers étaient signalées pour une Content-Security-Policy absente.

Pourquoi « ajouter simplement l'en-tête » casse des sites

Une politique est une liste blanche. Tout ce que vous oubliez est bloqué, sans que le visiteur le voie, avec une simple ligne dans la console du navigateur. Les victimes habituelles :

• Les balises d'analyse et de publicité. Google Analytics, Google Ads, Meta Pixel et Microsoft Clarity se chargent depuis plusieurs hôtes et redirigent souvent vers d'autres.
• Les contenus intégrés. Les outils de réservation (Calendly), les cartes, YouTube, les widgets de chat et les iframes de paiement ont chacun besoin de leurs propres sources de frame et de script.
• Les scripts inline. De nombreux frameworks et CMS placent de petits scripts directement dans la page. Une politique stricte les bloque, sauf si vous autorisez 'unsafe-inline' ou ajoutez un nonce (une valeur aléatoire par affichage de page).
• Les pages que personne ne teste. La page de contact, la page de remerciement après un formulaire, le paiement. Ce sont souvent elles qui chargent les scripts de conversion et de paiement.

Ce qui s'est passé sur notre propre site

Notre site fonctionne avec une politique en report-only depuis juillet 2026. Nous avons construit la première version à partir d'une trace réseau complète de la production, pas d'une supposition. Voici ce que cette trace et les rapports ont détecté. Chacun de ces points aurait cassé quelque chose si nous avions appliqué la politique dès le premier jour :

• Le ping de conversion Google Ads ne se déclenche que sur la page de contact. Une vérification de la page d'accueil ne le voit jamais. Appliquer la politique sans lui aurait empêché Ads de compter notre conversion principale : une demande de contact.
• Microsoft Clarity redirige vers un hôte Bing. Autoriser *.clarity.ms ne suffit pas ; la synchronisation d'ID passe par c.bing.com.
• Le pixel de remarketing d'Ads utilise le domaine du pays du visiteur, comme google.be ou google.co.th, et non google.com. La CSP n'a pas de joker pour cela. Nous listons donc les pays où nous vendons et acceptons un petit manque dans les données d'audience pour les autres.
• Un second hôte Ads est apparu sur chaque page. Le 19 octobre 2026, un nouveau passage sur six types de pages a montré que pagead2.googlesyndication.com se chargeait partout. Il n'était pas dans la trace de juillet. Notre propre scan de sécurité avait dit que la politique semblait correcte et que nous pouvions « simplement renommer l'en-tête ». Si nous l'avions fait, les conversions Ads seraient tombées à zéro sans la moindre erreur visible.

Deux leçons plus petites tirées du même travail. Chrome ignore upgrade-insecure-requests dans une politique en report-only et consigne une erreur dans la console, que Lighthouse compte ensuite contre vous. N'ajoutez donc cette directive qu'au passage à l'application. Ensuite, notre framework (SvelteKit) écrit un script d'hydratation inline, alors que notre hébergement n'autorise que des en-têtes fixes. 'unsafe-inline' sur les scripts reste donc en place jusqu'à l'ajout de nonces par requête. Une politique avec un compromis connu et documenté bloque quand même bien plus que l'absence de politique.

Comment déployer une CSP sans rien casser

1. Listez ce que vos pages chargent. Ouvrez les outils de développement du navigateur, onglet Network, et parcourez la page d'accueil, une page de contenu, la page de contact ou de réservation, le paiement et la page de remerciement. Notez chaque hôte.
2. Rédigez la politique à partir de cette liste. Commencez par default-src 'self' et ajoutez chaque hôte à la directive qui lui correspond : script-src, connect-src, img-src, frame-src, style-src, font-src.
3. Déployez-la en report-only, avec rapports. Envoyez-la sous la forme Content-Security-Policy-Report-Only avec à la fois report-to (plus un en-tête Reporting-Endpoints) et l'ancien report-uri. Tous les navigateurs ne prennent pas encore en charge report-to ; utilisez donc les deux. Ne consignez que la directive, l'hôte bloqué et le chemin de la page : les URL complètes peuvent contenir des données de visiteurs.
4. Lisez les rapports pendant une semaine. De vrais visiteurs utilisent d'autres navigateurs, extensions, pays et pages que vous. Ajoutez ce qui vous appartient ou appartient à vos outils ; ignorez le bruit des extensions de navigateur.
5. Revérifiez après chaque modification de balise. Les outils marketing changent d'hôtes sans prévenir. Repassez sur les mêmes types de pages après toute modification des balises ou de la politique.
6. Passez à l'application. Renommez l'en-tête en Content-Security-Policy, gardez les rapports et surveillez-les, ainsi que vos chiffres de conversion, les jours suivants.

Votre situation	Que faire
Le scan dit « pas de CSP », le site fonctionne bien	Démarrez en report-only cette semaine ; ne copiez pas une politique venue d'ailleurs
Vous avez ajouté une CSP et quelque chose ne marche plus	Repassez l'en-tête en report-only maintenant, puis corrigez la politique d'après les erreurs de la console
Vous diffusez des annonces Google Ads ou Meta	Testez les pages où les conversions se déclenchent et vérifiez les chiffres de conversion pendant quelques jours après l'application
Boutique en ligne avec un paiement	Testez un vrai paiement (en mode test) avec la politique en place ; les iframes de paiement ont besoin de leurs propres sources
WordPress avec beaucoup d'extensions	Attendez-vous à une longue liste ; les extensions qui injectent des scripts inline peuvent imposer 'unsafe-inline' pour l'instant

Besoin d'aide ?

Nous mettons en place une Content-Security-Policy de façon sûre : une trace de vos vraies pages, une phase report-only avec journalisation, puis le passage à l'application une fois les rapports propres. Vos statistiques et vos conversions sont vérifiées avant et après. Envoyez-nous l'adresse de votre site →

Vous dirigez une agence ? Nous le faisons sous votre nom, sous NDA. Voyez comment nous travaillons avec les agences →

À lire aussi

• Nous avons analysé 1 482 boutiques en ligne avant le Black Friday : voici ce que nous avons trouvé
• Site WordPress piraté : que faire dans la première heure
• Paiement qui ne fonctionne pas sur votre boutique en ligne ?

Source : MDN, Content-Security-Policy-Report-Only.