Content Security Policy (CSP) : qu’est-ce que c’est ?

Elle utilise des méta-éléments ou des en-têtes pour donner le feu vert ou bloquer le contenu chargé sur votre site web. La CSP (Content Security Policy) apporte une couche supplémentaire de protection et est largement recommandée pour tous les administrateurs de site web.

Découvrez, dans cet article, la CSP et pourquoi elle est aussi importante.

Content Security Policy (CSP), kézako ?

Une Content Security Policy (CSP) ou stratégie de sécurité de contenu a pour but d’améliorer la sécurité des sites web.

Pour cela, elle détecte et réduit un certain nombre d’attaques dont les attaques Cross-Site Scripting (XSS) et les injections de code. Ces attaques ont généralement pour but la diffusion de malware, le défacement de site ou le vol de données.

La CSP est un en-tête HTTP renvoyé par le serveur web pour indiquer aux navigateurs des utilisateurs les sources autorisées à charger du contenu sur le site visité.

Par exemple, si vous utilisez un service externe pour faire l’inclusion de polices d’écritures particulières, vous pouvez indiquer aux navigateurs des utilisateurs les serveurs autorisés pour :

• le chargement des fichiers de polices d’écritures sur votre site,
• et les serveurs qui ne le sont pas.

La première spécification de la CSP date de février 2015. Elle fut ensuite mise à jour en décembre 2016 et continue d’évoluer.

Pourquoi une stratégie de sécurité de contenu est-elle importante ?

Un Content Security Policy ajoute une seconde couche de protection contre différentes attaques. Elle protège ainsi l’utilisateur et le site internet à la fois pour :

Réduire ou atténuer les scripts intersites

Le principal avantage de définir une Content Security Policy (CSP) est de détecter et d’atténuer les attaques XSS.

Ces attaques exploitent la confiance du navigateur web dans le contenu fourni par le serveur pour lui imposer l’exécution de scripts malveillants.

Le code malicieux injecté récupère toutes les saisies de l’utilisateur :

• données personnelles,
• identifiants,
• mots de passe…

L’attaquant accède ainsi aux données de l’utilisateur et contourne l’authentification. Il peut même compromettre le compte et garder un accès permanent.

💡Tout cela arrive sans que l’utilisateur ne se doute de rien.

Dans la réalité, les XSS sont omniprésents et constituent l’un des défauts les plus courants des applications web.

Ce type de faille représente plus de 60 % des paiements dans le cadre du Vulnerability Reward Program de Google. Google bloque votre site lorsqu’il identifie un code malveillant, il bloque ainsi l’accès de vos clients.

Grâce à une CSP stricte, les administrateurs de serveur peuvent réduire ou éliminer la possibilité d’exploiter une faille XSS.

Pour cela, ils doivent définir les domaines internet auxquels les navigateurs des clients doivent faire confiance pour l’exécution de scripts.

Les navigateurs compatibles avec CSP n’exécutent donc que les scripts provenant de domaines présents sur la liste blanche définie. Par contre, ils ignorent tous les autres scripts y compris les attributs de gestion d’événements HTML.

Limiter ou empêcher les écoutes du trafic

En plus de restreindre les domaines de confiance, les serveurs peuvent également spécifier les protocoles à utiliser.

Ils peuvent par exemple forcer l’utilisation du HTTPS pour le chargement du contenu afin d’améliorer la sécurité des applications web.

Une Content Security Policy complète implique d’implémenter le protocole HTTPS dans le transfert de données. Cela implique également de :

• marquer tous les cookies avec l’attribut sécurisé,
• et de mettre en place des redirections automatiques des pages HTTP vers HTTPS.

Par ailleurs, les sites peuvent utiliser des en-têtes HTTPS Strict-Transport-Security pour garantir que les navigateurs des utilisateurs se connectent au site uniquement via des canaux cryptés en TLS.

Quand utiliser une CSP ?

La grande majorité des applications web complexes présentent une grande vulnérabilité au XSS et auraient tout intérêt à utiliser CSP.

L’utilisation d’une CSP est particulièrement recommandée pour les applications qui gèrent des données sensibles telles que :

• les consoles de gestion des appareils,
• les interfaces utilisateurs d’administration,
• ou tout autre produit hébergeant des fichiers ou des messages créés par l’utilisateur.

Dans les cadres modernes (modèles de fermeture), l’utilisation de CSP s’avère relativement simple et génère un retour sur investissement important en termes de sécurité additionnelle.

Quand utiliser d’autres mécanismes de sécurité ?

CSP est un mécanisme de sécurité supplémentaire pour les applications sécurisées sans vulnérabilités connues.

Cependant, dans certains cas, adopter une politique de sécurité de contenu ne peut pas être le meilleur choix. Il vaudrait mieux alors se concentrer sur d’autres solutions ayant un plus fort impact sur la sécurité :

Les applications statiques – Les applications web sans cookies ni fonctionnalités de connexion et hébergées sur leurs propres domaines ou sous-domaines présentent une faible vulnérabilité au XSS.

Les grandes applications qui ont été victime de XSS dans le passé ou qui présentent des failles connues dans les Frameworks ou modèles qu’elles utilisent. Une CSP à elle seule ne fournira pas une protection suffisante dans ces cas. La meilleure solution consiste donc à réparer le code vulnérable ou à investir dans des correctifs.

Comment configurer une règle CSP ?

Mettre en place une politique de sécurité de contenu (CSP) nécessite d’utiliser un en-tête HTTP Content-Security-Policy. Voici une procédure en trois étapes pour le faire :

1 – Définir votre règle CSP

La première étape consiste à définir les politiques ou directives ainsi que les valeurs sources indiquant les ressources à autoriser ou à restreindre.

Parmi les directives les plus communes, nous avons :

default-src: définit la politique par défaut utilisée dans tous les cas (fonts, CSS, JavaScript, Frames, etc.) lorsqu’elle a la valeur ‘self’.

Script-src : définit les sources de scripts autorisées

Style-src : définit les sources de feuilles de styles (CSS) autorisées

Object-src: définit les sources de plugins autorisées (ex : <embed> ou <object>)

img-src : définit les sources d’images ou d’icônes autorisées (ex : rel= »icon »)

media-src : définit les sources d’éléments multimédias autorisées (ex : <vidéo>, <audio>)

frame-src : définit les sources autorisées pour le chargement des trames (frame ou iframe)

font-src : définit les sources autorisées pour le chargement de fichiers de polices

connect-src : applique la CSP aux connexions à partir d’un XMLHttpRequest (AJAX) ou d’un WebSocket

bade-uri :autorise les URL dans l’attribut src de n’importe quelle balise

report-uri ou Content-Security-Policy-Report-Only : recevoir les rapports sans appliquer la politique de sécurité de contenu.

Add-header: ajoute un en-tête pour la Content Security Policy

2 – Tester votre règle CSP

Vous pouvez tester votre CSP pour être sûr d’avoir bien inclus les origines de domaines de confiance nécessaires à votre site.

Vous pouvez notamment :

• utiliser l’en-tête HTTP Response sur Content-Security-Policy-Report-Only pour recevoir des alertes de violation de votre Content Security Policy sans que la règle soit appliquée,
• configurer la directive report-uri avec une URL où vous recevrez les rapports sur les violations CSP.

3 – Mettre en œuvre la Content Security Policy

Il existe deux grandes configurations pour appliquer votre règle CSP.

La première option, moins populaire, fonctionne sur tous les navigateurs. La deuxième par contre nécessite de définir l’en-tête de réponse HTTP.

1 La configuration Meta Tags

Il est possible d’activer votre CSP dans le code HTML de la page en utilisant la balise HTML.

Pour cela, vous devez définir la balise <meta> dans le <head> pour que la règle s’applique dès que possible. Cela ressemble à ceci :

<head>

<meta http-equiv= « Content-Security-Policy »

content = »default-src ‘auto’ ; img-src * »>

</head>

2 La configuration de l’en-tête de réponse http CSP

C’est la méthode la plus appropriée pour implémenter une CSP par w3 ; elle fonctionne sur la plupart des navigateurs.

Ici, on utilisera Content-Security-Policy sans l’élément Report-Only. Notons que la plupart des règles appliquées à votre en-tête de réponse se produiront dans le fichier de configuration de votre serveur.

Pour ce faire, vous devez identifier le serveur sur lequel votre site web fonctionne et définir votre en-tête de réponse.

IIS (Services d’information sur internet)

• Accédez à votre gestionnaire IIS et sélectionnez votre site web sur la gauche
• Sélectionnez l’icône En-têtes de réponse HTTP
• Cliquez sur « ajouter » et entrez le nom et la valeur de l’en-tête.

Vous pouvez également ajouter votre stratégie de sécurité de contenu directement dans le fichier web.config. selon vos directives, cela ressemblera à ceci :

<system.webServer>

<httpProtocol>

<customHeaders>

<add name= »Content-Security-Policy » value= »default-src ‘self’; img-src* » />

</customHeaders>

</httpProtocol>

</system.webServer>

Découvrez plus d’informations sur la modification des en-têtes de réponse HTTP.

Nginx

Vous pouvez modifier l’en-tête de réponse en ajoutant une directive [add_header] dans les fichiers de configurations correspondants dans les blocs du serveur. Selon vos règles, cela ressemblera à ceci :

add_header Content-Security-Policy »default-src ‘self’ ; img-src * »

Apache

Sur un serveur apache, vous devez définir le Content Security Policy dans le fichier .htaccess de votre site ou dans VirtualHost ou httpd.conf.

Cela ressemblera à ceci selon vos directives :

Header set Content-Security-Policy-Report-Only « default-src ‘self’; img-src * »

Surtout, n’oubliez pas de supprimer l’élément Report-Only après la phase de test.

Sur le même sujet : Comment protéger votre site internet des violations de données ?