Content-Security-Policy : Protéger votre site sans bloquer vos utilisateurs

# linux # securite # nginx # avance # guide
Brandon Visca
Date de publication:

💡 TL;DR

  • La Content-Security-Policy est l’un des headers les plus puissants contre les attaques XSS
  • Mal configurée, elle bloque tes propres scripts et casse le site
  • Ce guide montre comment la configurer dans Nginx pas à pas, sans casser le frontend

Table des matières

Table des matières

Qu’est-ce qu’une Content-Security-Policy (CSP) ?

La CSP est un header HTTP qui indique au navigateur quelles ressources il est autorisé à charger (scripts, styles, images, etc.) et depuis quelles sources.

Son objectif principal : empêcher l’exécution de contenu non prévu dans la page, comme un script malveillant injecté par un attaquant (attaque XSS).

Prenons un exemple simple :

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

Cette directive interdit au navigateur de charger des ressources (scripts, images, etc.) depuis des domaines autres que le vôtre.

Pourquoi mettre en place une CSP ?

Voici quelques bénéfices clés :

Exemple d’attaque sans CSP

Un champ de commentaire non protégé peut permettre à un utilisateur malveillant d’injecter :

<script>alert('Vous avez été piraté');</script>

Sans CSP, le navigateur l’exécutera. Avec une bonne politique, il le bloquera purement et simplement.

Intégrer une CSP dans Nginx

Dans Nginx, la CSP se configure via une directive add_header dans votre bloc server {} ou location {}. Si le fonctionnement des blocs location ne vous est pas familier, ce guide sur les blocs location explique leur ordre de priorité, qui décide quel header s’applique où.

Exemple basique :

add_header Content-Security-Policy "default-src 'self'" always;

Mais en pratique, cela cassera tous vos scripts, styles et ressources provenant de CDNs externes (Bootstrap, jQuery, Google Fonts…).

Une configuration CSP souple et sécurisée

Voici une configuration équilibrée qui couvre la majorité des sites modernes sans tout bloquer :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' https: data:; connect-src 'self' https:; frame-ancestors 'self';" always;

Détails des directives :

💡 Tu peux affiner chaque directive selon les besoins de ton site.

CSP et environnement frontend moderne

Si tu utilises un framework comme Vue, React, Angular ou un CMS comme WordPress, il faut adapter la CSP :

Exemple spécifique WordPress avec CDN :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://code.jquery.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com;" always;

Astuce : mode report-only pour tester sans casser

Avant d’activer ta politique CSP, tu peux la tester en mode report-only. Tu vois les violations sans bloquer les ressources :

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https:;" always;

Couple ça avec une plateforme de monitoring CSP comme :

Où ajouter la CSP dans Nginx ?

Toujours dans le bloc server {} ou directement dans un location si tu veux l’appliquer uniquement sur des zones sensibles (/admin, /login, etc.). La CSP arrive rarement seule : elle se pose en général en même temps que les autres headers de sécurité.

Important : ajoute always pour que le header soit appliqué même sur les pages 404/500.

Une CSP bien réglée bloque l’exécution de scripts injectés, mais elle n’empêche pas de servir un fichier qui n’aurait jamais dû être exposé. Pour ce volet, voir protéger les fichiers sensibles et les uploads.

Conseils pratiques

Tester votre configuration

Voici les meilleurs outils pour valider ta politique CSP :

Avec une CSP bien configurée, ton site obtiendra facilement un score A ou A+ sur ces plateformes.

Cas réel : CSP dans un contexte scolaire (site avec sous-répertoires)

Si tu héberges des applications ou sites étudiants dans des sous-répertoires (/tata, /toto, etc.), tu peux appliquer une CSP globale dans un bloc avec regex :

location ~ ^/([a-z0-9-]+)(/.*)?$ {
    root /home/app/htdocs;
    try_files $uri $uri/ /$1/index.php?$args;

    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https:;" always;
}

En résumé

Ressources utiles

Share
Précédent
Limiter les risques sur Nginx : fichiers sensibles, uploads, méthodes HTTP
Suivant
Comment renforcer la sécurité de Nginx avec les headers HTTP essentiels