Introduire CSP avec Report-Only : déploiement pratique

Commencer dans un environnement de test

Sauvegardez les en-têtes de réponse actuels et la configuration du proxy. Recensez les origines nécessaires à la connexion, aux paiements, au CAPTCHA, aux polices et à l’analyse du trafic. Conservez la CSP déjà imposée : une politique d’observation ne la remplace ni ne l’assouplit. Prévoyez un retour arrière avant de modifier l’en-tête.

Ajouter une politique candidate dans Nginx

Placez cette directive dans le bloc server ou location approprié du site de test. C’est un exemple d’observation restrictif, pas une politique prête pour la production. Il autorise les sources de même origine et signale les scripts intégrés et les sources externes, sans les bloquer à lui seul.

Le paramètre always inclut les réponses d’erreur. Dans Nginx 1.26.3, définir add_header dans un location imbriqué empêche l’héritage des directives add_header du niveau supérieur. Préservez les en-têtes de sécurité existants et examinez chaque route concernée. N’ajoutez pas aveuglément une seconde copie d’un en-tête déjà fourni par l’application.

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;

Examiner une réponse réelle et le comportement du navigateur

Exécutez nginx -t pour votre installation avant de recharger le service. Ouvrez la page de test dans les outils de développement : confirmez la présence de Content-Security-Policy-Report-Only dans la réponse, puis observez la console en utilisant la page. Cet exemple sert à l’observation dans le navigateur ; il ne configure pas de collecte de rapports côté serveur.

Pour collecter les rapports, configurez un point de réception HTTPS fonctionnel et Reporting-Endpoints avec report-to. L’ancien report-uri a une sémantique de données et une compatibilité différentes. Limitez la taille des données et leur conservation : les URL des rapports peuvent contenir des données d’utilisateurs. N’envoyez pas de rapports à une adresse d’exemple.

Utiliser un test contrôlé avant et après

Notre test isolé utilise un script externe de même origine et un script intégré. Avec cet en-tête Report-Only, les deux s’exécutent et la violation du script intégré est signalée. Lorsque la même politique est imposée via Content-Security-Policy, le script externe s’exécute et le script intégré est bloqué. Testez vos propres pages : cet exemple ne certifie pas les intégrations tierces.

Autorisez chaque source nécessaire de façon délibérée. Pour le code intégré indispensable, utilisez des nonces générés par l’application ou des empreintes vérifiées plutôt qu’une autorisation large unsafe-inline. Un nonce doit être imprévisible et renouvelé à chaque réponse ; copier une valeur fixe n’est pas une solution.

Imposer progressivement et vérifier le retour arrière

Une fois les parcours représentatifs validés, transférez la politique testée dans l’en-tête imposé, d’abord en environnement de test. Vérifiez à nouveau connexion, récupération, paiement, intégrations et pages d’erreur. Plusieurs politiques imposées cumulent leurs restrictions ; un nouvel en-tête ne peut pas assouplir celui qui existe. Restaurez la configuration sauvegardée si des parcours légitimes échouent.

check.uk.app observe les en-têtes renvoyés ; il n’exécute pas l’application pour valider la couverture CSP. Environnement de test : Nginx 1.26.3 et Microsoft Edge basé sur Chromium, le 26 septembre 2026. Aucune CSP de production n’a été modifiée pour cet exemple.