Comment activer une Content Security Policy sans casser le checkout de votre e‑commer

Une Content Security Policy, ou CSP, aide à définir quelles ressources le navigateur peut charger ou exécuter lors de la visite d’une page. Pour une entreprise, le défi ne consiste généralement pas à en comprendre l’objectif, mais à l’appliquer sans interrompre un paiement, un formulaire, l’analytique, le chat ou toute intégration qui soutient l’activité quotidienne. Une politique appliquée brutalement peut transformer une mesure défensive en incident commercial.

La manière prudente de mettre en place une CSP consiste à la traiter comme un processus de contrôle des dépendances : savoir quel service charge chaque ressource, pourquoi elle est nécessaire, qui l’approuve et sur quelles pages elle doit fonctionner. Cette approche permet de progresser par étapes, de commencer par les parcours critiques et de réduire les autorisations inutiles sans supposer qu’une configuration générique conviendra à tous les sites web.

Le problème : des dépendances invisibles sur les pages critiques

Sur un site d’entreprise ou une boutique en ligne, le navigateur peut charger des scripts, des images, des connexions et des cadres depuis de nombreux fournisseurs. Certains répondent à des besoins clairs, comme une passerelle de paiement ou une carte ; d’autres peuvent provenir d’un ancien plugin, d’une balise de campagne temporaire ou d’un outil que personne n’a examiné depuis longtemps. Le problème concret est de perdre la visibilité sur ces dépendances et d’autoriser davantage que nécessaire par crainte que quelque chose cesse de fonctionner.

L’en-tête HTTP Content-Security-Policy permet d’indiquer depuis quelles sources une page peut charger ou exécuter des ressources. Il peut contribuer à atténuer certaines attaques d’injection de contenu et XSS, mais il doit être adapté à chaque site et à ses intégrations réelles. Il n’est donc pas recommandé de commencer en copiant une politique trouvée sur un autre site web : le point de départ doit être le comportement autorisé de l’application elle-même. [2]

• Donnez la priorité à la connexion, à l’espace client, aux formulaires, au panier et au checkout.
• Recensez chaque tiers avec son domaine, sa fonction, les pages concernées et son responsable interne.
• Incluez les connexions aux CRM, ERP ou autres API utilisées depuis le navigateur.

Ce que couvre une CSP et quelles sont ses limites

Une CSP agit dans le navigateur qui rend le HTML : elle peut notamment limiter les scripts exécutés, les connexions sortantes, les images, les formulaires et les sites pouvant intégrer une page. Des directives telles que script-src, connect-src, img-src, form-action, base-uri et frame-ancestors doivent répondre à un besoin précis, et non à une recette universelle. [2] [3]

Elle ne remplace ni la correction des vulnérabilités, ni la validation des entrées, ni l’encodage des sorties, ni la revue du code. OWASP présente la CSP comme une défense supplémentaire contre les XSS, et non comme un remplacement des mesures principales. Elle ne rend pas non plus un fournisseur externe sûr simplement parce que son domaine figure dans une liste autorisée ; chaque autorisation reste une décision liée au risque et à l’exploitation. [1]

• Évitez d’approuver des domaines avec des caractères génériques ou « au cas où ».
• Ne banalisez pas unsafe-inline ou unsafe-eval comme solution permanente.
• Lorsque l’architecture le permet, envisagez des nonces par réponse ou des hachages afin d’autoriser des scripts précis.

D’abord inventorier et observer, ensuite bloquer

Avant d’imposer des restrictions, préparez un inventaire par modèle ou parcours métier. Distinguez, par exemple, la page produit, l’accès au compte et le checkout. Une passerelle peut nécessiter des ressources qui n’apparaissent pas sur le reste du site, et une politique distincte pour cette zone peut être plus facile à gérer qu’une exception large appliquée à l’ensemble du domaine. Effectuez les tests uniquement dans des environnements et systèmes pour lesquels une autorisation explicite existe.

Le mode Content-Security-Policy-Report-Only permet de recevoir des alertes de non-conformité sans encore bloquer les ressources. Il est utile pour identifier les dépendances sur une période couvrant l’usage réel : campagnes actives, paiements, inscriptions, formulaires et différents appareils. Les alertes ne constituent pas une liste automatique de domaines à approuver ; elles servent de base pour enquêter, classifier et décider. [4]

• Attribuez un responsable à l’examen de chaque non-conformité.
• Distinguez les ressources légitimes, les dépendances obsolètes et les comportements inconnus.
• Conservez une politique validée vers laquelle revenir au moyen d’une procédure de réversion autorisée.

Définir des règles minimales et protéger les rapports

Après avoir examiné les alertes, n’autorisez que les origines nécessaires à chaque fonction. script-src régit les scripts ; connect-src, les connexions initiées par le navigateur ; img-src, les images ; et form-action, les destinations autorisées pour l’envoi de formulaires. frame-ancestors mérite une vérification spécifique : cette directive contrôle quels sites peuvent afficher la page dans un iframe ; il faut donc d’abord confirmer s’il existe des portails, du support ou d’autres intégrations légitimes. [2]

Les rapports CSP exigent également des contrôles. Ils peuvent contenir des données non fiables ; celles-ci doivent donc être validées et assainies avant d’être stockées, affichées dans un tableau de bord ou utilisées dans des automatisations. Évitez qu’un rapport génère à lui seul une exception dans la politique : toute modification requiert une revue humaine, un propriétaire et une justification technique et opérationnelle. [5]

• Documentez le motif et la date de chaque origine approuvée.
• Testez le paiement complet, la récupération de mot de passe, l’envoi des formulaires et les confirmations.
• Si un tiers modifie ses domaines ou ses ressources, réévaluez le besoin avant d’élargir les autorisations.

Mise en production et maintenance continue

Le passage en mode d’application doit être réalisé progressivement et avec une vérification fonctionnelle. Dans un exemple hypothétique, une boutique peut d’abord activer la politique dans l’espace compte, confirmer que la connexion et la récupération de mot de passe fonctionnent, puis intégrer le checkout après avoir testé le flux de paiement avec la passerelle autorisée. Si un blocage critique survient, appliquez la réversion documentée, consignez ce qui s’est produit et corrigez la règle ou la dépendance avant de réessayer.

La CSP doit être intégrée au processus de modification du site web. Un nouveau plugin, pixel publicitaire, chat, fournisseur de paiement ou automatisation peut nécessiter des ressources supplémentaires et doit passer par une revue avant sa publication. Un audit de protection web peut aider à organiser cet inventaire, examiner les configurations et valider les parcours autorisés ; il ne supprime pas la responsabilité de maintenir la politique alignée sur l’architecture et l’activité.

• Incluez la revue de la CSP dans l’intégration des fournisseurs et les déploiements.
• Retirez les autorisations lorsqu’une intégration est supprimée.
• Examinez périodiquement les pages critiques et les changements apportés par des tiers.

Questions fréquentes

Une Content Security Policy empêche-t-elle toutes les attaques XSS ?

Non. Elle peut réduire l’impact de certains scénarios d’injection et de XSS en limitant les ressources que le navigateur accepte, mais elle constitue une couche complémentaire. L’application doit continuer à appliquer la validation des entrées, l’encodage des sorties, l’assainissement lorsque cela est approprié et la revue du code.

Dois-je utiliser la même CSP sur l’ensemble du site web ?

Pas nécessairement. Les pages peuvent avoir des dépendances différentes. Le checkout, par exemple, peut nécessiter des ressources d’une passerelle qui ne doivent pas être autorisées sur une page informative. La décision dépend de l’architecture et doit être testée sur des parcours autorisés et représentatifs.

Que faire si le mode Report-Only génère beaucoup d’alertes ?

Classez-les avant de modifier la politique. Identifiez la page concernée, la ressource, son fournisseur, sa fonction et son responsable interne. N’approuvez que ce qui est nécessaire, retirez les anciennes dépendances lorsque cela est possible et traitez les données des rapports comme non fiables avant de les afficher ou d’automatiser des actions à