La Content Security Policy, ou CSP, est une politique de sécurité envoyée dans les en-têtes HTTP. Elle complète les protections du serveur en donnant au navigateur une liste précise des scripts, styles, images, polices et connexions autorisés.
À quoi sert une CSP ?
Lorsqu’une page contient du contenu injecté, le navigateur peut être amené à exécuter un script ou à charger une ressource contrôlée par un tiers. Une CSP restrictive réduit cette possibilité : tout ce qui n’est pas explicitement autorisé est bloqué.
Elle est particulièrement utile contre certaines conséquences d’une faille XSS. Elle peut empêcher l’exécution d’un script non autorisé, limiter les destinations auxquelles une page se connecte et interdire l’intégration du site dans une iframe malveillante.
Une CSP n’efface toutefois pas la vulnérabilité d’origine. La validation des entrées, l’échappement des sorties, les mises à jour et les autres contrôles applicatifs restent indispensables.
Les directives essentielles
| Directive | Rôle | Point de vigilance |
|---|---|---|
default-src | Définit la règle de repli | Commencer par une valeur restrictive |
script-src | Contrôle les scripts | Éviter les sources larges et les scripts inline |
style-src | Contrôle les feuilles de style | Extraire progressivement les styles inline |
img-src | Contrôle les images | N’autoriser que les schémas et domaines nécessaires |
connect-src | Limite les appels réseau du navigateur | Répertorier API, télémétrie et WebSocket utiles |
frame-ancestors | Décide qui peut intégrer la page | Utiliser 'none' si aucune iframe n’est nécessaire |
object-src | Contrôle les contenus intégrés historiques | 'none' convient à la plupart des sites modernes |
base-uri | Limite la balise base | Réduit les détournements d’URL relatives |
À quoi ressemble une politique restrictive ?
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'Cet exemple n’est pas à copier aveuglément. Un site qui utilise un service externe, une police distante ou une API devra déclarer précisément la source correspondante. L’objectif n’est pas d’accumuler les domaines autorisés, mais de partir du besoin réel.
Les configurations qui donnent une fausse impression de sécurité
La présence de l’en-tête ne suffit pas. Une politique peut être techniquement valide tout en restant très permissive.
*autorise une source beaucoup trop large ;'unsafe-inline'permet l’exécution de contenu directement présent dans la page ;'unsafe-eval'autorise des formes d’évaluation dynamique risquées ;- des schémas génériques comme
data:oublob:élargissent les contenus acceptés ; - une longue liste de domaines tiers augmente la surface de confiance ;
- une directive manquante peut laisser la règle de repli décider à sa place.
Le niveau de risque dépend du contexte. Par exemple, autoriser data: pour des images n’a pas le même impact que l’autoriser pour des scripts. L’analyse doit donc porter sur chaque directive et sur le type de ressource concerné.
Renforcer la CSP sans casser le site
- Inventorier les ressources réellement chargées. Relever les scripts, styles, images, polices, iframes et appels réseau nécessaires.
- Définir une politique restrictive. Commencer par
default-src 'self', puis ouvrir seulement les directives justifiées. - Tester en mode rapport. L’en-tête
Content-Security-Policy-Report-Onlypermet d’observer les violations sans bloquer les ressources. - Corriger les dépendances. Extraire les scripts et styles inline, supprimer les sources inutilisées et préférer les fichiers locaux lorsque cela a du sens.
- Activer progressivement le blocage. Vérifier les parcours essentiels sur ordinateur et mobile avant la généralisation.
- Surveiller les régressions. Une nouvelle intégration peut nécessiter un ajustement précis de la politique.
Comment vérifier la CSP d’un site ?
Dans les outils de développement du navigateur, ouvrez l’onglet Réseau, rechargez la page puis consultez les en-têtes de la réponse HTML. La console signale également les ressources bloquées et la directive concernée.
Vérifiez ensuite la politique effective : nombre de directives, sources trop larges, présence de valeurs risquées et protections comme frame-ancestors, object-src et base-uri. Un contrôle automatisé facilite cette lecture, mais le résultat doit toujours être interprété selon le fonctionnement réel du site.
Contrôlez les en-têtes de sécurité de votre domaine
L’audit TechAtelier analyse la CSP et les autres signaux HTTP d’un domaine afin de faire ressortir les directives absentes ou trop permissives.
Auditer un domaineUne protection utile lorsqu’elle reste précise
Une bonne CSP repose sur un principe simple : autoriser uniquement ce dont la page a besoin. Elle doit être testée, comprise et maintenue comme le reste de la configuration de sécurité.
Plus la politique est précise, moins un contenu inattendu dispose de possibilités dans le navigateur. Le meilleur résultat combine une application correctement sécurisée, une CSP restrictive et une surveillance régulière des changements.
Publié le 1er septembre 2026.