Politique de sécurité du contenu : `meta http-equiv`

La politique de sécurité du contenu est une politique appliquée par le navigateur qui limite les ressources qu'une page peut charger et exécuter. C'est la défense la plus solide contre les attaques XSS : même si un attaquant injecte une balise <script>, le navigateur refuse de l'exécuter, sauf si la politique l'autorise.

CSP peut être envoyé comme en-tête de réponse HTTP (Content-Security-Policy: ...) ou comme balise meta dans HTML : <meta http-equiv="Content-Security-Policy" content="...">. L'en-tête est préférable ; la balise meta est utile lorsque vous ne pouvez pas contrôler le serveur.

default-src sert de solution de repli pour les types de ressources non spécifiés. script-src, style-src, img-src, connect-src (XHR/fetch), font-src et frame-src limitent chacun leur type de ressource. Autorisez explicitement certaines origines ou utilisez 'self' pour limiter l'accès à la même origine.

'self' (entre guillemets) désigne l'origine de la page elle-même. script-src 'self' signifie « exécuter uniquement les scripts hébergés sur la même origine que la page ». C'est la base de la plupart des politiques ; ajoutez des CDN externes précis si nécessaire.

Par défaut, CSP bloque toutes les balises <script> intégrées et les attributs gestionnaires d'événements (onclick). C'est la protection la plus solide contre XSS : un <script> injecté ne peut pas s'exécuter parce qu'il est intégré. Déplacez tous les scripts dans des fichiers externes référencés par src.

Pour les scripts intégrés nécessaires, utilisez un nonce : le serveur génère un jeton aléatoire pour chaque requête, le définit comme script-src 'nonce-RANDOM' dans CSP et ajoute nonce="RANDOM" aux balises <script> légitimes. Les scripts injectés ne possèdent pas le nonce et sont bloqués.

'unsafe-inline' réautorise les scripts et les styles intégrés. 'unsafe-eval' réautorise eval() et new Function(). Ces deux options affaiblissent fortement CSP ; utilisez-les uniquement en dernier recours pendant une migration et prévoyez de les supprimer.

CSP transmis par une balise meta ne peut pas utiliser la directive report-uri ni les autres fonctions de génération de rapports. Il prend également effet plus tard qu'un en-tête : tout ce qui précède la balise meta n'est pas protégé. Les en-têtes sont nettement meilleurs ; n'utilisez la balise meta qu'en solution de repli.

Testez une nouvelle politique sans perturber le site : Content-Security-Policy-Report-Only: .... Le navigateur signale les violations sans les bloquer, ce qui vous permet d'affiner la politique jusqu'à ce qu'elle autorise toutes les ressources légitimes avant de passer à l'application effective.

Oublier style-src 'unsafe-inline' bloque les styles intégrés, souvent produits par les environnements de développement. Oublier connect-src bloque les requêtes AJAX vers les API. Testez toujours d'abord la politique en mode de rapport uniquement et examinez la console pour repérer les ressources bloquées.

Une CSP stricte combine script-src 'nonce-RANDOM' 'strict-dynamic' pour les scripts et une liste d'autorisation restrictive pour tout le reste. 'strict-dynamic' permet aux scripts munis d'un nonce de charger d'autres scripts sans devoir tous les répertorier — c'est bien plus facile à maintenir que des listes d'autorisation par origine.

Comment CSP se défend-il contre les attaques XSS, même lorsqu'un attaquant réussit à injecter une balise script ?

CSP est une politique appliquée par le navigateur qui limite les scripts, styles, images et autres ressources pouvant être chargés. Transmettez-la via un en-tête de réponse (méthode préférable) ou une balise meta. Utilisez des nonces pour les scripts intégrés nécessaires, évitez unsafe-inline et unsafe-eval, et testez d'abord en mode de rapport uniquement. Une CSP stricte avec 'nonce-X' 'strict-dynamic' constitue la base moderne.