Politique de sécurité du contenu

Qu'est-ce qu'une politique de sécurité du contenu ?

Une politique de sécurité du contenu, ou CSP (Content Security Policy), est un en-tête de réponse HTTP qui indique précisément au navigateur quelles sources de scripts, feuilles de style, images, polices et autres ressources une page web est autorisée à charger. Tout ce qui n'est pas explicitement autorisé par la politique est bloqué par le navigateur avant de pouvoir s'exécuter, quelle que soit la façon dont le contenu s'est retrouvé sur la page. C'est important car cela ferme directement le principal mécanisme derrière les attaques par script intersite (XSS) : même si un attaquant parvient à injecter une balise script malveillante dans une page, une CSP bien configurée empêche le navigateur de jamais l'exécuter.

La CSP est délivrée comme un en-tête HTTP standard plutôt que comme du code applicatif, ce qui en fait une dernière ligne de défense qui s'applique quelle que soit la façon dont la page a été construite ou le framework qui l'a générée.

‍

Comment fonctionne une politique de sécurité du contenu

Une CSP est un ensemble de directives, chacune contrôlant un type de ressource, envoyées dans un unique en-tête HTTP :

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data:; style-src 'self' 'unsafe-inline'

Ici, default-src 'self' définit la règle par défaut (uniquement l'origine propre de la page), script-src autorise les scripts depuis l'origine de la page plus un CDN de confiance, img-src autorise aussi les data URI intégrées pour les images, et style-src autorise les styles en ligne. Le navigateur évalue chaque requête de ressource par rapport à la directive correspondante et bloque silencieusement tout ce qui sort de la liste autorisée, en général avec un avertissement dans la console que les développeurs peuvent inspecter.

‍

Directives CSP courantes

• default-src : liste de sources par défaut appliquée à toute directive non explicitement définie.
• script-src : sources autorisées pour le JavaScript, la directive la plus déterminante pour bloquer le XSS.
• style-src : sources autorisées pour le CSS, y compris si les styles en ligne sont permis.
• img-src / font-src / frame-src : sources autorisées respectivement pour les images, polices et iframes intégrées.
• connect-src : destinations autorisées pour les connexions fetch, XHR et WebSocket initiées par la page.

‍

Mode appliqué vs mode rapport seul

‍

Bonnes pratiques et pièges courants

• Démarrer en mode rapport seul sur un environnement proche de la production pour voir ce qu'une politique stricte casserait avant de l'appliquer.
• Éviter unsafe-inline et unsafe-eval pour script-src autant que possible ; ils affaiblissent nettement la protection de la politique contre le XSS.
• Lister explicitement les domaines tiers (analytics, widgets, intégrations) plutôt que d'utiliser un joker, ce qui viderait la politique de son sens.
• Réauditer la politique dès qu'un nouveau script ou intégration tiers est ajouté au site ; un domaine oublié provoque un dysfonctionnement silencieux plutôt qu'une erreur visible.
• Combiner la CSP avec d'autres en-têtes de sécurité, comme un certificat SSL forçant le HTTPS, pour une protection en couches plutôt que de reposer sur la seule CSP.

‍

Pourquoi ça compte pour la sécurité

Le script intersite reste l'une des vulnérabilités web les plus courantes, et une CSP est l'une des rares défenses qui fonctionne même après qu'un attaquant a déjà trouvé un moyen d'injecter un script dans une page, en empêchant le navigateur de l'exécuter. Les moteurs de recherche et outils d'analyse de sécurité traitent de plus en plus la présence d'en-têtes de sécurité, CSP incluse, comme un signal de confiance, et les audits d'hébergement ou d'agence signalent souvent son absence. Pour les sites gérant des formulaires, des connexions ou des données de paiement, une CSP est un ajout à faible effort et fort impact pour la posture de sécurité globale d'un site.

‍

La politique de sécurité du contenu chez BeBranded

Nous configurons les en-têtes de sécurité, dont une politique de sécurité du contenu quand la stack d'hébergement le permet, dans le cadre du durcissement technique que nous appliquons aux sites et applications web que nous construisons. Cela s'ajoute au HTTPS forcé et à des choix d'hébergement fiables comme socle pour tout site destiné aux clients. Voir notre service website pour savoir comment nous traitons la sécurité et les fondations techniques sur les sites que nous construisons.