CSP : comprendre et déployer une politique
Auteur : Rédaction Domeny.ForSale Publié le
En bref : CSP, ou Content Security Policy, est un mécanisme de sécurité du navigateur qui permet de définir les sources depuis lesquelles une page peut charger des ressources et le code qu’elle peut exécuter. Il aide à limiter les conséquences des attaques XSS, c’est-à-dire l’injection d’un script malveillant dans une page. Une directive spécifique protège aussi contre l’intégration du site dans des cadres indésirables. Il est préférable de transmettre cette politique dans un en-tête de réponse HTTP et de la tester d’abord sans bloquer les ressources.
Comment fonctionne CSP et contre quoi protège-t-elle ?
Le navigateur charge habituellement les ressources indiquées dans le code de la page : scripts, feuilles de style, images ou polices. CSP ajoute un ensemble de règles à ce fonctionnement. Si une ressource ou un mode d’exécution du code ne respecte pas la politique, le navigateur le bloque et signale la violation dans les outils de développement.
CSP sert avant tout à limiter les attaques XSS (cross-site scripting). Une telle attaque consiste à faire exécuter le script d’un attaquant dans le contexte d’un site tiers. Par exemple, une faille dans un formulaire de commentaires peut permettre d’insérer du code JavaScript à la place d’un simple texte. Une politique CSP suffisamment restrictive peut empêcher l’exécution de ce code, même si l’application l’intègre par erreur à la page.
CSP contribue également à prévenir le clickjacking, ou détournement de clic : une page est intégrée dans un cadre et une surcouche trompeuse incite l’utilisateur à cliquer sur ses éléments. Cette protection repose sur la directive frame-ancestors. Définir uniquement des règles pour les scripts ne suffit pas à l’assurer.
CSP ne corrige toutefois pas les failles de l’application. Un encodage correct des données en sortie, un traitement sécurisé des contenus des utilisateurs et des mises à jour logicielles restent nécessaires. La politique constitue une couche de protection supplémentaire, et non un substitut à ces mesures.
Où configurer la politique CSP ?
L’emplacement recommandé est l’en-tête de réponse HTTP nommé Content-Security-Policy. Il peut être ajouté par l’application, le serveur web, un proxy inverse ou un CDN. Le navigateur doit recevoir cet en-tête avec le document HTML auquel il s’applique.
Certaines règles peuvent également être transmises au moyen d’une balise meta dotée de l’attribut http-equiv="Content-Security-Policy". Cette solution a des limites : la politique ne prend effet qu’après la lecture de la balise et ne prend en charge ni le mode de signalement sans blocage ni la directive frame-ancestors. Si vous avez accès à la configuration des réponses HTTP, privilégiez l’en-tête.
Vérifiez aussi qu’une autre couche de l’infrastructure n’ajoute pas déjà une politique CSP. Plusieurs politiques s’appliquent simultanément : un nouvel en-tête ne remplace pas automatiquement le précédent. Il peut donc restreindre davantage le fonctionnement du site.
Principales directives et exemple d’en-tête
Une directive est une règle individuelle de la politique. Les directives sont séparées par des points-virgules, et leur nom est suivi des sources autorisées ou de valeurs spéciales.
| Directive | Ce qu’elle contrôle |
|---|---|
default-src | Sources par défaut pour de nombreux types de ressources qui n’ont pas de règle propre |
script-src | Sources des scripts et conditions d’exécution de JavaScript |
style-src | Sources des feuilles de style et règles d’utilisation des styles intégrés |
img-src | Sources des images |
connect-src | Connexions initiées notamment par fetch et WebSocket |
object-src | Objets intégrés pris en charge par des éléments tels que object |
base-uri | Adresses autorisées dans l’élément base |
frame-ancestors | Pages autorisées à intégrer le document dans un cadre |
Pour un site simple utilisant uniquement ses propres fichiers, la configuration suivante peut servir de point de départ :
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
La valeur 'self' désigne la même origine : le schéma, le nom d’hôte et le port doivent correspondre. 'none' n’autorise aucune source. L’exemple ci-dessus interdit l’intégration de la page dans des cadres et bloque notamment les scripts écrits directement dans le document HTML ainsi que les attributs d’événement tels que onclick.
Cette configuration n’est pas universelle. Si le site utilise un système de paiement, un outil d’analyse ou des polices externes, il faut identifier les sources nécessaires et les ajouter aux directives correspondantes. default-src ne remplace pas toutes les règles : frame-ancestors, par exemple, nécessite une déclaration distincte.
Comment déployer CSP sans bloquer le site par erreur ?
La démarche la plus sûre consiste à identifier les dépendances réelles du site avant d’activer le blocage.
- Recensez les ressources et les intégrations. Ne vous limitez pas à la page d’accueil : incluez aussi la connexion, les formulaires, les paiements et l’espace utilisateur.
- Configurez l’en-tête
Content-Security-Policy-Report-Only. Le navigateur évaluera la politique proposée et signalera les violations, sans bloquer les opérations concernées. La collecte automatique des rapports nécessite une configuration supplémentaire du mécanisme de signalement et du service qui les reçoit. - Testez des parcours utilisateur complets. Consultez la console et le panneau réseau du navigateur. Distinguez les ressources nécessaires des intégrations superflues et des requêtes provenant des extensions du navigateur.
- Corrigez les règles et le code. Après les tests, passez la politique validée dans l’en-tête
Content-Security-Policy, puis surveillez les erreurs après le déploiement.
Ne faites pas disparaître les avertissements en ajoutant sans réflexion *, 'unsafe-inline' ou 'unsafe-eval'. De telles exceptions peuvent considérablement affaiblir la protection. Pour les scripts intégrés nécessaires, vous pouvez utiliser un nonce — une valeur imprévisible générée pour chaque réponse — ou un hash, c’est-à-dire une empreinte du contenu d’un script précis. Le nonce doit être identique dans l’en-tête et dans l’élément du script ; une valeur fixe copiée dans la configuration ne remplit pas ce rôle.
Commencez par une politique en mode de signalement dans un environnement de test, puis suivez un parcours complet, de l’arrivée sur le site jusqu’à l’envoi d’un formulaire ou à la finalisation d’un achat. Vous pourrez ainsi déterminer les autorisations réellement nécessaires avant que CSP ne commence à bloquer des ressources pour les utilisateurs.
À lire aussi : Qu’est-ce que MCP ?
À lire aussi
