Comment déployer une Content Security Policy avant que les lecteurs signalent les pages cassées

Commencez le déploiement d’une Content Security Policy par l’observation et un ensemble représentatif de pages. Une politique copiée peut rendre l’accueil apparemment sûr tout en cassant les médias d’un article, un paiement ou l’aperçu éditorial. L’objectif est de restreindre l’exécution indésirable tout en préservant les fonctions réellement voulues par la publication.

La spécification CSP distingue une politique appliquée de Content-Security-Policy-Report-Only, qui permet au navigateur de surveiller une proposition sans l’imposer. Ce mode sert à comprendre ses effets. Il n’apporte pas la protection de cette proposition appliquée et ne désactive pas une politique distincte déjà en vigueur.

Cartographier le site réellement exploité

Listez les types de pages et parcours représentatifs avant d’écrire les règles. Incluez un article courant, une page multimédia, la recherche, les éditions traduites et les fonctions commerciales réelles. N’ajoutez pas de services imaginaires. Une publication statique sans comptes, suivi ni scripts de paiement possède d’autres dépendances qu’un service d’abonnement.

Pour chaque parcours, identifiez scripts, styles, images, polices, cadres et connexions nécessaires. Notez le responsable et le rôle de chaque dépendance externe. Un nom d’hôte aperçu dans le navigateur est un indice, pas une autorisation automatique de tout ce qu’il diffuse. Demandez si la fonction a sa place sur la page avant d’ajouter une exception.

Inspectez les véritables en-têtes de réponse et le circuit de livraison. La politique peut être ajoutée à l’origine, par l’hébergement ou dans une couche de diffusion. Si plusieurs endroits contribuent, établissez la configuration de référence avant modification. Sinon, un développeur peut changer un réglage local tandis que les lecteurs reçoivent encore une autre politique.

Livrer la proposition dans un en-tête report-only

La spécification précise que la politique report-only n’est pas prise en charge dans un élément meta. Configurez l’en-tête HTTP par le processus de déploiement adapté au site. Gardez la politique appliquée actuelle en vue : observer une proposition supplémentaire ne prouve pas que toutes les restrictions existantes ont disparu.

Choisissez un dispositif de rapports pris en charge et confirmez que le point de réception accepte les données attendues. La référence MDN de l’en-tête explique livraison et configuration. Écrire une directive ne crée pas le service chargé de recevoir, stocker et examiner les rapports.

Limitez le premier essai pour qu’il reste compréhensible. Utilisez un environnement maîtrisé ou un déploiement restreint adapté, et conservez la configuration précédente. Testez la console du navigateur et le circuit de collecte. Sans rapports reçus, vérifiez le fonctionnement de la collecte avant de conclure à l’absence de violations.

Traitez les rapports entrants comme des données non fiables. Limitez la conservation inutile, protégez l’accès au collecteur et évitez les adresses sensibles dans les canaux d’incident largement partagés. Un rapport peut contenir des informations sur le contexte de la page d’un visiteur. Examinez la collecte avant d’adopter un prestataire externe, plutôt que de la considérer comme un simple tuyau neutre.

Transformer les rapports en décisions, pas en permissions croissantes

Regroupez les résultats par type de page, directive et ressource. Reproduisez les échecs représentatifs au travers des parcours prévus. Une extension ou un état inhabituel du navigateur peut produire du bruit : un rapport doit déclencher une enquête, pas autoriser automatiquement une source. À l’inverse, écarter toute entrée inattendue comme du bruit peut masquer un vrai défaut d’intégration.

Pour chaque dépendance légitime, décidez de la conserver, la remplacer ou la supprimer. Une liste croissante d’exceptions larges peut maintenir tous les anciens scripts en affaiblissant l’objectif. Le guide CSP d’OWASP présente notamment des approches plus fortes avec nonces ou empreintes. Elles exigent une génération et une livraison correctes, pas une valeur d’exemple fixe réutilisée.

Avec des nonces, surveillez particulièrement aperçus, langues et cache. L’en-tête et le balisage autorisé doivent correspondre au même dispositif de réponse. Utilisez l’examen des règles de cache lorsqu’une couche de diffusion modifie les réponses reçues. Une visite développeur réussie sans cache ne représente pas forcément la page publique mise en cache.

Appliquer lors d’un changement maîtrisé, puis observer

Définissez les critères d’acceptation par les fonctions, pas seulement par le silence des rapports. Les lecteurs peuvent-ils ouvrir les articles, lire les médias prévus et terminer les vrais paiements ? Les éditeurs peuvent-ils prévisualiser ? Les langues, écrans et consentements utiles ont-ils été testés ? Une collecte incomplète signifie qu’aucune violation enregistrée ne prouve pas l’exercice de tous les parcours.

Avant l’application, relevez version, tests, limites et procédure exacte de retour arrière. Utilisez un processus de préproduction et de restauration. Modifiez la politique appliquée par le circuit habituel, puis vérifiez les en-têtes livrés et les mêmes parcours sur le résultat en ligne. Gardez un responsable disponible pendant la première observation.

Après modification, examinez les rapports d’erreur avec les preuves fonctionnelles. Si une fonction légitime critique échoue, restaurez une configuration connue ou apportez une correction limitée et comprise. N’autorisez pas toutes les sources uniquement pour faire taire les alertes. La réparation doit pouvoir être rattachée à la dépendance et au comportement concernés.

Conservez inventaire et revue de politique pour les prochaines versions. Le retrait d’un fournisseur doit entraîner la suppression de ses permissions devenues inutiles ; l’ajout d’une fonction, un nouveau contrôle. CSP fonctionne mieux comme composante entretenue de la diffusion, avec sécurité applicative et contrôle d’accès, que comme un badge obtenu une fois en ajoutant un en-tête.