Cybersécurité · fiche technologique
CSP et en-têtes de sécuritéFiche technologique · Cybersécurité
Mettre en place une CSP et des en-têtes de sécurité
Les en-têtes de sécurité sont des consignes que votre site envoie au navigateur de vos visiteurs. La plus puissante, la politique de sécurité des contenus (CSP), limite ce que vos pages peuvent exécuter. Voici quand elle convient, et comment nous la déployons en commençant par l'observer.
Le besoin
Ce qu'apportent les en-têtes de sécurité.
Un en-tête de sécurité n'ajoute aucune fonction visible pour vos visiteurs : il retire des possibilités à un attaquant.
Chaque réponse de votre serveur s'accompagne de lignes techniques, les en-têtes HTTP. Certaines donnent au navigateur des consignes de prudence : n'ouvrir le site qu'en HTTPS, ne pas deviner le type d'un fichier, ne pas se laisser afficher dans le cadre d'un autre site. Elles se posent au niveau du serveur, sans modifier le contenu des pages, et se contrôlent facilement. Le site de Crawler Agency en applique d'ailleurs plusieurs : HTTPS imposé, type de fichier respecté, informations de provenance réduites, fonctions du navigateur limitées.
La politique de sécurité des contenus, ou CSP, est l'en-tête le plus puissant et le plus exigeant. Elle indique au navigateur quelles sources de scripts il peut exécuter. Si un attaquant parvient à glisser du code dans une page, le navigateur le refuse. L'OWASP la présente comme une seconde ligne de défense : elle rend une faille plus difficile à exploiter, sans jamais dispenser de la corriger.
Elle suppose de savoir précisément ce que charge votre site : scripts maison, statistiques, vidéo, paiement, chat. C'est pourquoi nous la concevons avec vous, au cas par cas, et la déployons d'abord en observation. Ces protections s'inscrivent dans notre démarche de sécurisation des applications et des API.
Une couche de plus, pas un substitut
La CSP ne nettoie pas les données saisies. Elle limite les dégâts si un contrôle a échoué : les deux protections se cumulent.
Une politique qui se mesure avant de s'appliquer
Un mode d'observation permet de voir ce que la politique bloquerait, sans rien bloquer. C'est la seule façon raisonnable de la poser sur un site existant.
Un inventaire utile au-delà de la sécurité
Dresser la liste de ce que charge réellement votre site fait souvent apparaître des services oubliés, doublons ou inutiles.
Applications concrètes
Ce qu'on en fait, concrètement.
Six protections distinctes, qui peuvent se déployer ensemble ou l'une après l'autre selon la nature de votre site.
Limiter l'effet d'un script injecté
Si du code étranger se glisse dans une page, la CSP empêche le navigateur de l'exécuter tant qu'il ne porte pas la marque attendue.
Empêcher l'affichage dans le cadre d'un site pirate
Interdire ou restreindre l'intégration de vos pages dans celles d'un autre site, technique utilisée pour piéger un clic.
Imposer une connexion toujours chiffrée
Demander au navigateur de ne contacter votre site qu'en HTTPS, même si le visiteur saisit une adresse ancienne.
Encadrer les services tiers
Décider quels scripts de statistiques, de chat ou de paiement peuvent s'exécuter, et lesquels de leurs chargements annexes sont admis.
Limiter ce que le navigateur communique
Réduire les informations sur la page d'origine transmises aux autres sites, et empêcher le navigateur de deviner le type d'un fichier.
Désactiver les fonctions inutiles du navigateur
Interdire à vos pages l'accès à la caméra, au micro ou à la position si elles n'en ont aucun usage.
Un exemple lisible
Une politique stricte, ligne par ligne.
Dix lignes d'en-têtes de réponse qui rassemblent une CSP à nonce et les en-têtes de sécurité les plus courants. Chaque ligne a une raison d'être.
- Seuls les scripts portant le nonce sont exécutés. Le nonce est une valeur aléatoire, renouvelée à chaque réponse. 'strict-dynamic' étend la confiance d'un script autorisé aux scripts qu'il charge.
- Plus aucun objet embarqué (object-src) et plus de balise base pour détourner les adresses relatives (base-uri).
- Aucun site ne peut afficher vos pages dans un cadre. Cette directive ne retombe pas sur default-src et remplace l'ancien en-tête X-Frame-Options.
- Les violations sont envoyées au point de collecte nommé à la ligne suivante : c'est ce qui rend l'observation utile.
- Le navigateur retient pendant un an (31 536 000 secondes) de n'utiliser que HTTPS, sous-domaines compris. À allonger seulement si le certificat se renouvelle sans faille.
- Caméra, micro et position sont désactivés pour la page et ses cadres. Réglage à adapter si votre site en a l'usage.
Content-Security-Policy:
script-src 'nonce-{ALEATOIRE}' 'strict-dynamic';
object-src 'none'; base-uri 'none';
frame-ancestors 'none';
report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Faire le bon choix
Une CSP : maintenant, ou plus tard ?
Les en-têtes simples conviennent presque partout. La CSP, plus exigeante, ne se justifie pas de la même façon pour tous les sites.
Elle convient quand
- Votre site affiche du contenu venant d'utilisateurs (commentaires, avis, profils) ou reprend des paramètres d'adresse : une injection de script est un scénario réaliste, et la CSP en réduit l'effet.
- Votre espace connecté manipule des données sensibles (comptes clients, back-office, paiement) : une seconde ligne de défense se justifie.
- Vos pages peuvent être produites côté serveur, ou permettre d'insérer un nonce dans le rendu : la politique à nonce devient praticable.
- Vous acceptez une phase d'observation avant l'application, et quelqu'un lira les rapports.
Il vaut mieux l'éviter, ou la compléter, quand
- Votre site repose sur de nombreux scripts en ligne et gestionnaires d'événements écrits à la main, sans budget pour les réécrire : mieux vaut d'abord poser les en-têtes simples.
- Vous ne contrôlez ni les en-têtes ni le rendu de la plateforme : une balise meta apporte une protection partielle, sans protection d'imbrication ni point de collecte des violations.
- Vous comptez sur la CSP pour compenser des failles connues et non corrigées : elle les rend plus difficiles à exploiter, elle ne les supprime pas.
- Chaque blocage serait réglé par une exception rapide : ajouter 'unsafe-inline' ou 'unsafe-eval' affaiblit la politique au point de la vider de son sens.
Le parcours, étape par étape
Un déploiement progressif.
Une CSP se pose en observant d'abord, puis en appliquant. Cette progression évite de découvrir un blocage en production.
Inventorier
Nous listons ce que vos pages chargent réellement : scripts, styles, polices, cadres et services tiers.
Observer
La politique est publiée en mode Report-Only : rien n'est bloqué, mais chaque infraction est signalée.
Corriger
Nous traitons les rapports : scripts en ligne à protéger ou déplacer, services à autoriser, gestionnaires d'événements à réécrire.
Appliquer
La politique passe en mode bloquant. Une version plus stricte peut continuer d'être observée en parallèle.
Surveiller
Un nouveau service tiers ou une nouvelle fonction peut déclencher de nouvelles infractions : les rapports restent lus.
Le mode Report-Only s'appuie sur l'en-tête Content-Security-Policy-Report-Only. Il peut coexister avec une politique appliquée.
Notre façon de l'intégrer
Comment nous l'intégrons.
Les en-têtes simples d'abord, la CSP ensuite, toujours en deux temps : observer, puis appliquer.
Mesurer l'existant
Nous relevons les en-têtes que vos pages envoient aujourd'hui et ce qu'elles chargent, y compris les services tiers dont plus personne ne se souvient.
Poser les en-têtes simples
HTTPS imposé, type de fichier respecté, informations de provenance réduites, fonctions du navigateur limitées. Nous vérifions le renouvellement du certificat avant d'allonger la durée de l'obligation HTTPS.
Concevoir la CSP avec vous
Nonce ou empreintes, tolérance pour vos services tiers, règles d'imbrication : la politique est rédigée pour votre site et publiée en observation.
Appliquer, puis suivre
Une fois les rapports sans surprise, la politique est appliquée. Nous convenons avec vous de qui lit les rapports et de ce qui déclenche une révision.
Aller plus loin
De la technologie au projet.
La technologie se choisit après le besoin : voici les expertises qui portent le projet, et les technologies voisines à comparer.
Expertises métier
- Sécurisation des applications et APILa démarche globale de protection côté application, dans laquelle s'inscrivent ces en-têtes.
- Sécurisation des infrastructures webServeurs, certificats et configuration, là où les en-têtes sont posés.
- Hébergement, maintenance et infogéranceLe suivi dans la durée d'un site dont l'hébergement permet de maîtriser ses en-têtes.
- Audit de sécurité des applications webContrôler ce qui est réellement envoyé par vos pages et ce que la politique laisse passer.
Technologies voisines
Toutes les technologies du pôle
Questions fréquentes
Les questions qu'on nous pose sur la CSP.
Des réponses courtes, pour décider si la CSP vaut l'effort sur votre site.
Sources
Fiche relue en novembre 2026.
Une CSP peut-elle casser un site existant ?
Oui, c'est le risque principal. Dès qu'une politique contient script-src ou default-src, les scripts en ligne, les gestionnaires d'événements écrits dans les balises et la fonction eval sont bloqués par défaut. D'où le mode Report-Only : il montre ce qui serait bloqué avant d'appliquer la politique. C'est la méthode que nous recommandons. Voir aussi la sécurisation des infrastructures web.
Nonce ou liste de domaines autorisés : que choisir ?
Les documentations de référence recommandent les politiques dites strictes, fondées sur un nonce ou une empreinte. Les listes de domaines sont difficiles à tenir juste et laissent souvent passer des sources trop larges. Le nonce demande que les pages soient produites à chaque requête ; l'empreinte convient mieux aux pages statiques, mais elle doit être recalculée à chaque modification du script.
La CSP est-elle compatible avec les scripts de statistiques et de chat ?
Souvent, oui, grâce à 'strict-dynamic' : la confiance accordée à un script autorisé s'étend à ceux qu'il charge. La documentation MDN précise toutefois que cela rend la politique moins sûre si ces scripts créent des éléments à partir de sources injectables. Nous évaluons chaque service avec vous avant de l'autoriser.
Un site statique peut-il utiliser une CSP à nonce ?
Pas telle quelle : un nonce doit changer à chaque réponse et ne doit pas être prévisible, donc le serveur ne peut pas servir un fichier identique à tous. Deux voies existent : produire les pages dynamiquement pour y insérer le nonce, ou employer des empreintes de scripts, qui restent valables tant que les scripts ne changent pas. Le choix dépend de votre hébergement.
Peut-on remplacer l'en-tête par une balise meta ?
En partie seulement. La balise meta prend en charge l'essentiel des protections contre les scripts, mais pas l'interdiction d'imbrication (frame-ancestors), ni le mode Report-Only, ni le point de collecte des violations. Elle dépanne quand vous ne contrôlez pas le serveur ; l'en-tête reste la méthode complète, à utiliser dès que votre hébergement le permet.
Un site à protéger côté navigateur ?
Décrivez-nous ce que charge votre site : nous vous disons quels en-têtes poser tout de suite, et si une CSP vaut l'effort dans votre cas.