Defaults.Exposed › Corrections › Content-Security-Policy (CSP)

Comment corriger Content-Security-Policy (CSP)

Une Content Security Policy est une règle de sécurité que votre site web remet au navigateur de chaque visiteur, lui indiquant exactement quel code est autorisé à s'exécuter. Sans elle, si du code malveillant atterrit un jour sur une page — via une zone de commentaires, une extension piratée, ou un script tiers — le navigateur l'exécutera librement, y compris du code qui copie discrètement les numéros de carte et mots de passe de vos clients pendant qu'ils les saisissent, le cadenas toujours affiché.

En clair, pour votre entreprise : Si votre site est un jour falsifié, du code malveillant peut lire les coordonnées bancaires et identifiants de vos clients directement depuis votre propre page de commande pendant que tout paraît parfaitement normal — vous laissant avec des rétrofacturations, des plaintes pour fraude, une violation de données à déclarer, et un échec à un contrôle que les équipes sécurité des clients plus importants utilisent pour faire caler ou tuer une affaire.

Ce que cela peut vous coûter

Du code caché se glisse dans l'une de vos pages et copie en silence chaque numéro de carte et mot de passe que vos clients saisissent à la commande, l'envoyant à un attaquant pendant que votre site paraît parfaitement normal — vous ne le découvrez qu'à l'arrivée des plaintes pour fraude.
Un escroc plante un faux formulaire « payer ici » sur votre vrai site web qui capture les paiements vers son propre compte ; les clients croient vous avoir payé, vous en veulent quand les marchandises n'arrivent jamais, et exigent leur argent.
L'équipe sécurité d'un client plus important scanne votre site, voit que cette protection élémentaire est désactivée, et la signale — faisant caler ou perdre le contrat jusqu'à ce que vous puissiez prouver que c'est corrigé.
Une violation remontant à une protection standard manquante devient un incident à déclarer : questions du régulateur, notifications aux clients, et une atteinte à la réputation qui coûte bien plus que la correction gratuite.

Pourquoi c'est important. Le cadenas prouve que la connexion à votre site est privée, mais il ne fait rien pour contrôler quel code s'exécute une fois le visiteur sur la page. Une Content Security Policy est la protection qui le fait — elle dit aux navigateurs d'ignorer tout script qui ne provient pas d'une source de confiance, de sorte qu'un seul champ, une seule publicité ou une seule extension falsifiés ne puissent être transformés en outil pour voler l'argent et les données de vos clients. C'est un contrôle noté sur votre tableau de bord, valant de vrais points, et l'une des premières choses qu'une revue de sécurité professionnelle recherche.

Ce que c’est, en clair

Quand quelqu’un visite votre site web, son navigateur télécharge votre page et exécute tout le code qui s’y trouve — les scripts qui font dérouler les menus, fonctionner les boutons, soumettre les formulaires de paiement, et ainsi de suite. Par défaut, le navigateur fait confiance à tout. Il n’a aucun moyen de savoir quel code est authentiquement le vôtre et lequel a été glissé par quelqu’un d’autre.

Une Content Security Policy (souvent abrégée en CSP) est une courte liste de règles que votre site web attache à chaque page, disant au navigateur : « n’exécute que le code provenant de ces sources que j’ai approuvées, et refuse tout le reste. » C’est la différence entre une boîte de nuit qui laisse entrer n’importe qui et une autre avec une liste d’invités à l’entrée.

La raison pour laquelle cela compte tant, c’est que les sites web sont falsifiés en permanence — pas toujours en piratant votre serveur, mais par les portes dérobées que la plupart des sites laissent ouvertes : un champ de commentaire, une zone de recherche, une extension obsolète, un script tiers pour la publicité ou l’analyse, ou un widget de discussion. Si un attaquant parvient à placer ne serait-ce qu’une ligne de son propre code sur l’une de vos pages, le navigateur l’exécute comme s’il était le vôtre. À partir de là, il peut lire tout ce que vos clients saisissent — numéros de carte, mots de passe, adresses — et l’envoyer discrètement ailleurs. Une Content Security Policy ferme cette porte en refusant d’exécuter quoi que ce soit provenant d’une source que vous n’avez pas approuvée.

Ce que cela peut vous coûter

Ce n’est pas abstrait. L’attaque qu’une Content Security Policy prévient — du code injecté dans une page qui vole les données de vos propres clients — est derrière certaines des plus grandes violations de vol de cartes enregistrées. Voici comment cela tend à se dérouler pour une entreprise ordinaire :

Le skimmer invisible de la page de commande. Un attaquant glisse quelques lignes de code sur votre page de commande via une extension vulnérable ou un script tiers compromis. Chaque numéro de carte, nom et CVV que vos clients saisissent est copié et envoyé à l’attaquant en temps réel. Votre site a l’air et fonctionne parfaitement ; le cadenas est là. Vous le découvrez des semaines plus tard quand votre prestataire de paiement appelle au sujet d’un groupe de signalements de fraude remontant tous à votre boutique. Vous voilà face à des rétrofacturations, un audit de sécurité forcé, une éventuelle perte des droits de traitement des cartes, et une violation que vous pouvez être légalement tenu de déclarer.
Le faux formulaire de paiement. Un escroc injecte une boîte « payer ici » convaincante sur votre vrai site web. Les clients saisissent leurs informations en faisant confiance à votre marque ; l’argent et les données vont à l’attaquant. Les clients vous en veulent — et ils n’ont pas tort, car cela s’est produit sur votre site.
Le contrat perdu. L’équipe sécurité d’un prospect plus important effectue un scan automatisé de votre site dans le cadre d’une due diligence fournisseur. Une Content Security Policy absente apparaît immédiatement comme une lacune de gravité élevée. Pour un examinateur achats ou sécurité, cette seule protection manquante se lit comme « ce fournisseur ne fait pas les bases » — et l’affaire cale pendant qu’ils demandent une remédiation, ou part discrètement chez un concurrent qui a réussi le test.
La violation à déclarer. Quand une violation de données remonte à une protection standard, gratuite et manquante, elle cesse d’être de la malchance et commence à ressembler à de la négligence. Cela change les questions du régulateur, l’obligation de notification aux clients, et le coût — à la fois l’amende et l’atteinte à la réputation, qui persiste longtemps après la clôture de l’incident.
La publicité ou le widget compromis. Beaucoup de sites chargent du code provenant de tiers — régies publicitaires, polices, chat de support, analyse. Si l’un d’eux est compromis, le code malveillant file droit dans vos pages. Une Content Security Policy limite le rayon d’impact en n’autorisant que les sources extérieures précises auxquelles vous faites confiance, de sorte que la violation d’un fournisseur ne devienne pas automatiquement la vôtre.

Ce que c’est réellement (le détail)

Une Content Security Policy est livrée sous la forme d’un seul en-tête de réponse HTTP — une ligne que votre serveur web envoie avec chaque page. Sa valeur est un ensemble de directives, chacune nommant un type de contenu et les sources autorisées pour lui. Par exemple :

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

En clair, cela dit : par défaut, ne charge que les choses provenant de mon propre site ; n’exécute des scripts que de mon propre site ; n’autorise aucune extension à l’ancienne ; et ne laisse pas d’autres sites intégrer le mien dans un cadre.

À quoi ressemble le « bon » réglage. Notre contrôle ne se contente pas de chercher la présence de l’en-tête — il lit la politique directive par directive et note sa robustesse réelle, comme le ferait un examinateur de sécurité. Une politique forte :

Définit une base restrictive (default-src 'self') et ne l’élargit que pour les tiers de confiance précis que vous utilisez véritablement.
Évite les failles. Elle n’utilise pas 'unsafe-inline' ni 'unsafe-eval' pour les scripts, et n’utilise pas de joker (*) ni de sources de schéma nu (comme https:) pour les scripts — ceux-ci rouvrent en pratique la porte que la politique est censée fermer. Là où des scripts en ligne sont véritablement nécessaires, elle utilise un nonce ou un hachage pour que seul votre code approuvé précis s’exécute.
Verrouille l’encadrement avec frame-ancestors 'self' (cela bloque aussi l’attaque « intégrer votre site pour piéger vos clients ») et désactive les extensions héritées avec object-src 'none'.
Est en application, pas en report-only. Un en-tête Content-Security-Policy-Report-Only ne fait qu’observer ; il n’offre aucune protection à l’exécution. Notre contrôle ne lui attribue qu’une petite fraction du crédit et ne l’enregistre jamais comme une réussite. Vous n’êtes protégé qu’une fois la politique en application.

Une politique qui existe mais s’appuie sur 'unsafe-inline', 'unsafe-eval' ou des jokers obtiendra quand même une note médiocre — car en pratique elle n’offre qu’une faible protection réelle. Le but est une politique serrée, pas juste une politique quelconque.

Comment corriger (gratuit, ~1 à 2 heures)

Transmettez ceci à votre informaticien ou à la personne qui gère votre site web — la correction elle-même est entièrement gratuite. Nous facturons uniquement la surveillance de son maintien en place et de sa justesse dans le temps ; l’activer ne coûte rien. La raison pour laquelle cela prend une heure ou deux plutôt que quelques minutes est l’étape d’essai prudente qui l’empêche de bloquer accidentellement des parties de votre propre site.

Commencez en mode report-only — n’imposez pas encore. Ajoutez un en-tête de réponse Content-Security-Policy-Report-Only. Il observe et journalise ce qui serait bloqué sans rien bloquer réellement, de sorte que le site en direct continue de fonctionner pendant que vous apprenez ce dont chaque page dépend véritablement. (Important : le report-only à lui seul n’offre aucune protection aux visiteurs — ce n’est que la première étape sûre.)
Construisez la politique à partir de ce que votre site utilise réellement. Examinez les rapports pour trouver chaque source légitime de scripts, styles, polices et images — votre propre domaine, votre analyse, votre prestataire de paiement, votre hébergeur de polices, votre widget de discussion — et listez-les comme sources autorisées. Un bon point de départ est default-src 'self' plus des entrées explicites pour les tiers de confiance que vous utilisez réellement.
Évitez les failles qui anéantissent tout l’intérêt. Tenez-vous à l’écart de 'unsafe-inline' et 'unsafe-eval' pour les scripts, et évitez les sources joker comme * et les schémas nus comme https: pour les scripts — ceux-ci rouvrent exactement la brèche que la politique est censée fermer. Là où des scripts en ligne sont inévitables, utilisez un nonce ou un hachage pour que seul votre code approuvé précis s’exécute.
Verrouillez l’encadrement et les extensions. Ajoutez frame-ancestors 'self' (cela empêche aussi d’autres sites d’intégrer le vôtre pour piéger vos clients, et satisfait le contrôle de clickjacking associé) et object-src 'none' pour bloquer les attaques à base d’extensions héritées.
Passez de report-only à application. Une fois les rapports propres et le site fonctionnel, changez le nom de l’en-tête de Content-Security-Policy-Report-Only à Content-Security-Policy. C’est l’étape qui délivre réellement la protection — une politique en report-only seul ne le fait pas, et ne réussira pas le contrôle.

L’endroit où vous définissez l’en-tête dépend de votre plateforme :
- Cloudflare : Rules → Transform Rules → Modify Response Header → définissez Content-Security-Policy. (Vous pouvez aussi utiliser Cloudflare pour l’essai report-only.)
- Nginx : add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache : Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config) : ajoutez un en-tête de réponse HTTP personnalisé nommé Content-Security-Policy avec la politique comme valeur.
- Google Workspace / Microsoft 365 : ceux-ci font tourner votre messagerie, pas votre site web public, donc la politique se définit là où votre site est réellement hébergé (Cloudflare ou votre hébergeur web ci-dessus), et non dans votre console d’administration de messagerie.
Recontrôlez votre domaine pour confirmer que la politique apparaît désormais comme activée et en application, sans failles d’affaiblissement.

Erreurs fréquentes

S’arrêter au report-only. L’erreur de loin la plus fréquente : une politique est ajoutée en mode report-only, tout le monde passe à autre chose, et le site n’est jamais réellement protégé. Le report-only ne bloque rien. Vous devez passer en application.
Recourir à 'unsafe-inline' pour que « ça marche ». Quand la politique bloque un script en ligne légitime, la solution rapide est d’autoriser tous les scripts en ligne — mais cela rouvre exactement le trou que la politique était censée fermer. Utilisez plutôt un nonce ou un hachage.
Utiliser un joker. Un simple * (ou https:) dans script-src autorise des scripts de n’importe où, ce qui signifie que la politique n’offre presque aucune protection réelle et obtiendra quand même une note basse.
Oublier les sources tierces. Imposer une politique stricte sans d’abord lister les services extérieurs légitimes que vous utilisez (analyse, polices, widgets de paiement) peut casser des parties de votre propre site — ce qui est précisément pourquoi l’étape d’essai report-only existe.
Ne la définir que sur la page d’accueil. La politique doit couvrir chaque page, en particulier les pages de commande, de connexion et de compte — ce sont celles qui valent la peine d’être attaquées.
La traiter comme un substitut du cadenas. Une Content Security Policy et HTTPS/HSTS protègent des choses différentes. Vous les voulez tous ; l’un ne couvre pas pour l’autre.

FAQ

Je ne suis pas technique — puis-je m'en occuper moi-même ?

Vous n'avez pas besoin de comprendre les détails. C'est un réglage ajouté par la personne qui gère votre site web ou votre hébergement, et sur des services comme Cloudflare c'est largement guidé. Transmettez-leur la section « Comment corriger » ci-dessous. C'est gratuit ; la seule précaution est qu'il faut le déployer prudemment d'abord en mode surveillance seule pour ne pas bloquer accidentellement des parties de votre propre site — ce que couvrent justement les étapes.

J'ai déjà le cadenas et un certificat SSL — mon site n'est-il pas sécurisé ?

Le cadenas sécurise la livraison de votre page ; il ne contrôle pas ce qui s'exécute à l'intérieur. Si du code malveillant finit un jour sur une page — via une extension piratée, une publicité compromise, ou un champ injecté — le cadenas ne l'empêchera pas de voler des données. Une Content Security Policy est la couche qui limite ce qui est autorisé à s'exécuter en premier lieu. Ils protègent des choses différentes, et vous voulez les deux.

Activer cela pourrait-il casser mon site ?

C'est possible si on l'active agressivement d'un seul coup, car cela peut bloquer des scripts légitimes que vous utilisez réellement. C'est pourquoi l'approche standard consiste à commencer en mode « report-only » (surveillance) qui observe sans bloquer, à corriger tout ce qu'il signale, et seulement alors à l'imposer. Fait ainsi, c'est sans danger — et l'étape d'essai est intégrée à la correction ci-dessous.

Nous l'avons déjà mis en mode « report-only » — sommes-nous couverts ?

Non, et c'est le faux sentiment de sécurité le plus fréquent. Le mode report-only observe et journalise ce qui serait bloqué, mais il ne bloque rien — les visiteurs n'ont aucune protection réelle. Ce n'est que la première étape sûre. Notre contrôle n'attribue au report-only qu'une petite fraction du crédit d'une vraie politique et ne l'enregistrera pas comme une réussite. Vous n'êtes protégé qu'une fois passé en mode d'application.

Cela affecte-t-il notre score, ou est-ce juste consultatif ?

Cela affecte votre score. Le contrôle Content Security Policy est noté et vaut jusqu'à 25 points dans la catégorie Sécurité web. Une politique absente ou faible est classée en gravité élevée et tire votre note vers le bas — et c'est exactement le genre de lacune sur laquelle porte le questionnaire de sécurité d'un client.

Notre développeur a ajouté une politique mais le score reste bas — pourquoi ?

Une politique peut exister tout en étant faible. Les coupables les plus fréquents sont des failles comme « unsafe-inline » et « unsafe-eval » pour les scripts, ou des sources joker (un simple *), qui rouvrent exactement la brèche que la politique est censée fermer. Notre contrôle lit la politique directive par directive et pénalise ces faiblesses — une politique qui autorise n'importe quoi ne vaut guère mieux que pas de politique du tout. La correction consiste à durcir les règles de scripts à l'aide de nonces ou de hachages au lieu de ces failles.