10 septembre 2025Français

Une analyse approfondie de la Content Security Policy (CSP) et son rôle crucial pour atténuer les attaques JavaScript, protégeant vos applications web du XSS.

En-têtes de sécurité Web : Content Security Policy et l'exécution de JavaScript

Dans le paysage numérique complexe d'aujourd'hui, la sécurité des applications web est primordiale. L'une des défenses les plus efficaces contre diverses attaques, en particulier le Cross-Site Scripting (XSS), est l'utilisation des en-têtes de sécurité Web. Parmi ceux-ci, la Content Security Policy (CSP) se distingue comme un mécanisme puissant pour contrôler les ressources qu'un navigateur est autorisé à charger pour une page donnée. Cet article fournit un guide complet pour comprendre et mettre en œuvre efficacement la CSP afin de protéger vos applications web et vos utilisateurs.

Comprendre les en-têtes de sécurité Web

Les en-têtes de sécurité Web sont des en-têtes de réponse HTTP qui donnent des instructions au navigateur sur la manière de se comporter lors du traitement de certains types de contenu. Ils constituent un élément crucial d'une stratégie de défense en profondeur, agissant de concert avec d'autres mesures de sécurité pour atténuer les risques.

Parmi les en-têtes de sécurité web les plus couramment utilisés, on trouve :

Content Security Policy (CSP) : Contrôle les ressources que l'agent utilisateur est autorisé à charger.
HTTP Strict Transport Security (HSTS) : Force les navigateurs à utiliser HTTPS.
X-Frame-Options : Protège contre les attaques de type Clickjacking.
X-Content-Type-Options : Empêche les vulnérabilités de type MIME-sniffing.
Referrer-Policy : Contrôle la quantité d'informations de référent à inclure dans les requêtes.
Permissions-Policy (anciennement Feature-Policy) : Permet un contrôle granulaire sur les fonctionnalités du navigateur.

Cet article se concentre principalement sur la Content Security Policy (CSP) et son impact sur l'exécution de JavaScript.

Qu'est-ce que la Content Security Policy (CSP) ?

La CSP est un en-tête de réponse HTTP qui vous permet de définir une liste blanche de sources à partir desquelles le navigateur est autorisé à charger des ressources. Cela inclut JavaScript, CSS, les images, les polices et d'autres actifs. En définissant explicitement ces sources de confiance, vous pouvez réduire considérablement le risque d'attaques XSS, où des scripts malveillants sont injectés dans votre site web et exécutés dans le contexte des navigateurs de vos utilisateurs.

Considérez la CSP comme un pare-feu pour votre navigateur, mais au lieu de bloquer le trafic réseau, elle bloque l'exécution de code non fiable.

Pourquoi la CSP est-elle importante pour l'exécution de JavaScript ?

JavaScript est un langage puissant qui peut être utilisé pour créer des expériences web dynamiques et interactives. Cependant, sa flexibilité en fait également une cible de choix pour les attaquants. Les attaques XSS impliquent souvent l'injection de code JavaScript malveillant dans un site web, qui peut ensuite être utilisé pour voler les identifiants des utilisateurs, rediriger les utilisateurs vers des sites de phishing ou dégrader le site web.

La CSP peut prévenir efficacement ces attaques en restreignant les sources à partir desquelles JavaScript peut être chargé et exécuté. Par défaut, la CSP bloque tout le JavaScript en ligne (code dans les balises <script>) et le JavaScript chargé depuis des domaines externes. Vous activez ensuite sélectivement les sources de confiance à l'aide des directives CSP.

Les directives CSP : Les briques de votre politique

Les directives CSP définissent les types de ressources qui peuvent être chargées et les sources à partir desquelles elles peuvent l'être. Voici quelques-unes des directives les plus importantes :

default-src : Sert de solution de repli pour les autres directives de récupération. Si une directive spécifique n'est pas définie, default-src est utilisée.
script-src : Spécifie les sources autorisées pour le code JavaScript.
style-src : Spécifie les sources autorisées pour les feuilles de style CSS.
img-src : Spécifie les sources autorisées pour les images.
font-src : Spécifie les sources autorisées pour les polices.
media-src : Spécifie les sources autorisées pour les fichiers audio et vidéo.
object-src : Spécifie les sources autorisées pour les plugins (par ex., Flash).
frame-src : Spécifie les sources autorisées pour les cadres (<frame>, <iframe>).
connect-src : Spécifie les origines autorisées pour les requêtes réseau (par ex., XMLHttpRequest, Fetch API, WebSockets).
base-uri : Restreint les URL qui peuvent être utilisées dans l'élément <base> d'un document.
form-action : Restreint les URL vers lesquelles les formulaires peuvent être soumis.
upgrade-insecure-requests : Ordonne au navigateur de mettre à niveau toutes les URL non sécurisées (HTTP) vers des URL sécurisées (HTTPS).
block-all-mixed-content : Empêche le navigateur de charger des ressources via HTTP lorsque la page est chargée en HTTPS.

Chaque directive peut accepter une variété d'expressions de source, notamment :

* : Autorise les ressources de n'importe quelle source (généralement non recommandé).
'self' : Autorise les ressources de la même origine (schéma, hôte et port) que le document.
'none' : Interdit les ressources de toutes les sources.
'unsafe-inline' : Autorise l'utilisation de JavaScript et de CSS en ligne (fortement déconseillé).
'unsafe-eval' : Autorise l'utilisation de eval() et des fonctions associées (fortement déconseillé).
'unsafe-hashes' : Autorise des gestionnaires d'événements en ligne spécifiques en fonction de leur hachage SHA256, SHA384 ou SHA512 (à utiliser avec prudence).
data: : Autorise les URI data: (par ex., images en ligne encodées en base64).
https://example.com : Autorise les ressources du domaine spécifié (et éventuellement du port) via HTTPS.
*.example.com : Autorise les ressources de n'importe quel sous-domaine de example.com.
nonce-{random-value} : Autorise des scripts ou styles en ligne spécifiques qui ont un attribut nonce correspondant (recommandé pour le code en ligne).
sha256-{hash-value} : Autorise des scripts ou styles en ligne spécifiques qui ont un hachage SHA256 correspondant (alternative aux nonces).

Mise en œuvre de la CSP : Exemples pratiques

Il existe deux manières principales de mettre en œuvre la CSP :

En-tête HTTP : Envoi de l'en-tête Content-Security-Policy dans la réponse HTTP. C'est la méthode privilégiée.
Balise <meta> : Utilisation d'une balise <meta> dans la section <head> du document HTML. Cette méthode a des limitations et n'est généralement pas recommandée.

Utilisation de l'en-tête HTTP

Pour définir l'en-tête CSP, vous devez configurer votre serveur web. Les étapes exactes varient en fonction de votre serveur (par ex., Apache, Nginx, IIS).

Voici quelques exemples d'en-têtes CSP :

CSP de base

Cette politique n'autorise que les ressources provenant de la même origine :

            Content-Security-Policy: default-src 'self';

Autoriser les ressources de domaines spécifiques

Cette politique autorise le JavaScript de https://cdn.example.com et les images de https://images.example.net :

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;

Utilisation des nonces pour les scripts en ligne

Cette politique autorise les scripts en ligne qui ont un attribut nonce correspondant :

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';

Dans votre HTML :

            <script nonce="rAnd0mN0nc3">
 // Votre script en ligne
</script>

Remarque : La valeur du nonce doit être générée de manière aléatoire pour chaque requête afin d'empêcher les attaquants de contourner la CSP.

Utilisation des hachages pour les scripts en ligne

Cette politique autorise des scripts en ligne spécifiques en fonction de leur hachage SHA256 :

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';

Pour générer le hachage SHA256, vous pouvez utiliser divers outils en ligne ou des utilitaires de ligne de commande (par ex., openssl dgst -sha256 -binary input.js | openssl base64).

Utilisation de la balise `<meta>`

Bien que non recommandée pour les politiques complexes, la balise <meta> peut être utilisée pour définir une CSP de base. Par exemple :

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Limitations de la balise <meta> :

Ne peut pas être utilisée pour spécifier la directive report-uri.
N'est pas aussi largement prise en charge que l'en-tête HTTP.
Moins flexible et plus difficile à gérer pour les politiques complexes.

Mode CSP de rapport uniquement (Report-Only)

Avant d'appliquer une CSP, il est fortement recommandé d'utiliser l'en-tête Content-Security-Policy-Report-Only. Cela vous permet de surveiller l'impact de votre politique sans réellement bloquer de ressources. Le navigateur signalera toute violation à une URL spécifiée, vous permettant d'affiner votre politique avant de la déployer en production.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;

Vous devrez configurer un point de terminaison côté serveur (par ex., /csp-report) pour recevoir et traiter les rapports CSP. Ces rapports sont généralement des objets JSON qui contiennent des informations sur la directive violée, l'URI bloquée et d'autres détails pertinents.

Erreurs courantes de CSP et comment les éviter

La mise en œuvre de la CSP peut être difficile, et il est facile de commettre des erreurs qui peuvent soit affaiblir votre sécurité, soit casser votre site web. Voici quelques pièges courants à éviter :

Utiliser 'unsafe-inline' et 'unsafe-eval' : Ces directives désactivent essentiellement les protections offertes par la CSP et doivent être évitées autant que possible. Utilisez des nonces ou des hachages pour les scripts en ligne et évitez d'utiliser eval().
Utiliser * : Autoriser des ressources de n'importe quelle source va à l'encontre de l'objectif de la CSP. Soyez aussi spécifique que possible lors de la définition de votre politique.
Ne pas tester de manière approfondie : Testez toujours votre CSP en mode de rapport uniquement avant de l'appliquer. Surveillez les rapports et ajustez votre politique si nécessaire.
Configurer incorrectement le report-uri : Assurez-vous que votre point de terminaison report-uri est correctement configuré pour recevoir et traiter les rapports CSP.
Oublier de mettre à jour votre CSP : À mesure que votre site web évolue, votre CSP peut avoir besoin d'être mise à jour pour refléter les changements dans vos dépendances de ressources.
Politiques trop restrictives : Des politiques trop restrictives peuvent casser votre site web et frustrer les utilisateurs. Trouvez un équilibre entre sécurité et convivialité.

CSP et bibliothèques tierces

De nombreux sites web dépendent de bibliothèques et de services tiers, tels que les CDN, les fournisseurs d'analyse et les widgets de médias sociaux. Lors de la mise en œuvre de la CSP, il est important de prendre en compte ces dépendances et de s'assurer que votre politique leur permet de charger correctement les ressources.

Voici quelques stratégies pour gérer les bibliothèques tierces :

Mettre explicitement sur liste blanche les domaines des fournisseurs tiers de confiance : Par exemple, si vous utilisez jQuery depuis un CDN, ajoutez le domaine du CDN à votre directive script-src.
Utiliser l'intégrité des sous-ressources (SRI) : La SRI vous permet de vérifier que les fichiers que vous chargez à partir de sources tierces n'ont pas été altérés. Pour utiliser la SRI, vous devez générer un hachage cryptographique du fichier et l'inclure dans la balise <script> ou <link>.
Envisager d'héberger les bibliothèques tierces sur votre propre serveur : Cela vous donne plus de contrôle sur les ressources et réduit votre dépendance vis-à-vis des fournisseurs externes.

Exemple avec SRI :

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>

CSP et applications monopages (SPA)

Les SPA reposent souvent fortement sur JavaScript et la génération de code dynamique, ce qui peut rendre la mise en œuvre de la CSP plus difficile. Voici quelques conseils pour sécuriser les SPA avec la CSP :

Éviter d'utiliser 'unsafe-eval' : Les SPA utilisent souvent des moteurs de modèles ou d'autres techniques qui reposent sur eval(). Envisagez plutôt d'utiliser des approches alternatives qui ne nécessitent pas eval(), comme les modèles précompilés.
Utiliser des nonces ou des hachages pour les scripts en ligne : Les SPA injectent souvent du code JavaScript de manière dynamique. Utilisez des nonces ou des hachages pour vous assurer que seul le code de confiance est exécuté.
Configurer attentivement la directive connect-src : Les SPA effectuent souvent des requêtes API vers divers points de terminaison. Assurez-vous de ne mettre sur liste blanche que les domaines nécessaires dans la directive connect-src.
Envisager d'utiliser un framework compatible avec la CSP : Certains frameworks JavaScript offrent un support intégré pour la CSP, ce qui facilite la mise en œuvre et la maintenance d'une politique de sécurité.

CSP et internationalisation (i18n)

Lors du développement d'applications web pour un public mondial, il est important de prendre en compte l'impact de la CSP sur l'internationalisation (i18n). Voici quelques facteurs à garder à l'esprit :

Réseaux de diffusion de contenu (CDN) : Si vous utilisez un CDN pour livrer les actifs de votre site web, assurez-vous de mettre sur liste blanche les domaines du CDN dans votre CSP. Envisagez d'utiliser différents CDN pour différentes régions afin d'optimiser les performances.
Polices externes : Si vous utilisez des polices externes (par ex., Google Fonts), assurez-vous de mettre sur liste blanche les domaines des fournisseurs de polices dans votre directive font-src.
Contenu localisé : Si vous servez différentes versions de votre site web pour différentes langues ou régions, assurez-vous que votre CSP est correctement configurée pour chaque version.
Intégrations tierces : Si vous vous intégrez à des services tiers spécifiques à certaines régions, assurez-vous de mettre sur liste blanche les domaines de ces services dans votre CSP.

Meilleures pratiques CSP : Une perspective globale

Voici quelques bonnes pratiques générales pour la mise en œuvre de la CSP, en tenant compte d'une perspective globale :

Commencer avec une politique restrictive : Débutez avec une politique qui bloque tout par défaut, puis activez sélectivement les sources de confiance.
Utiliser d'abord le mode de rapport uniquement : Testez votre CSP en mode de rapport uniquement avant de l'appliquer pour identifier les problèmes potentiels.
Surveiller les rapports CSP : Examinez régulièrement les rapports CSP pour identifier les vulnérabilités de sécurité potentielles et affiner votre politique.
Utiliser des nonces ou des hachages pour les scripts en ligne : Évitez d'utiliser 'unsafe-inline' et 'unsafe-eval'.
Être spécifique avec vos listes de sources : Évitez d'utiliser des jokers (*) sauf en cas de nécessité absolue.
Utiliser l'intégrité des sous-ressources (SRI) pour les ressources tierces : Vérifiez l'intégrité des fichiers chargés depuis les CDN.
Maintenir votre CSP à jour : Révisez et mettez à jour régulièrement votre CSP pour refléter les changements de votre site web et de ses dépendances.
Former votre équipe : Assurez-vous que vos développeurs et votre équipe de sécurité comprennent l'importance de la CSP et comment la mettre en œuvre correctement.
Envisager d'utiliser un générateur ou un outil de gestion de CSP : Ces outils peuvent vous aider à créer et à maintenir votre CSP plus facilement.
Documenter votre CSP : Documentez votre politique CSP et les raisons de chaque directive pour aider les futurs développeurs à la comprendre et à la maintenir.

Conclusion

La Content Security Policy est un outil puissant pour atténuer les attaques XSS et renforcer la sécurité de vos applications web. En définissant soigneusement une liste blanche de sources de confiance, vous pouvez réduire considérablement le risque d'exécution de code malveillant et protéger vos utilisateurs. La mise en œuvre de la CSP peut être un défi, mais en suivant les meilleures pratiques décrites dans cet article et en tenant compte des besoins spécifiques de votre application et de votre public mondial, vous pouvez créer une politique de sécurité robuste et efficace qui protège votre site web et vos utilisateurs dans le monde entier.

N'oubliez pas que la sécurité est un processus continu, et la CSP n'est qu'une pièce du puzzle. Combinez la CSP avec d'autres mesures de sécurité, telles que la validation des entrées, l'encodage des sorties et des audits de sécurité réguliers, pour créer une stratégie de défense en profondeur complète.