Content Security Policy WordPress : Guide Complet CSP Anti-XSS 2026

Pourquoi votre site WordPress a besoin d’une CSP en 2026

Les attaques XSS (Cross-Site Scripting) représentent 47 % de l’ensemble des vulnérabilités WordPress découvertes en 2025, selon le rapport annuel de Patchstack. Malgré les mises à jour régulières, un plugin mal codé, une thème mal configuré ou une simple injection dans un formulaire peuvent suffire à compromettre l’ensemble de vos visiteurs.

Pourtant, une mesure simple, native au navigateur et ne nécessitant aucun plugin payant existe : la Content Security Policy. Bien configurée, elle neutralise la grande majorité des attaques XSS même si la faille est présente dans votre code. En 2025, seulement 8 % des sites WordPress avaient une CSP active, selon l’Observatoire Mozilla — ce qui représente une opportunité massive de vous distinguer.

Dans ce guide, vous apprendrez à implémenter une CSP efficace sur WordPress, à éviter les erreurs courantes, et à tester votre configuration sans risque pour votre site. Pour aller plus loin sur les attaques XSS elles-mêmes, consultez notre article dédié : XSS WordPress : comment détecter et prévenir les attaques Cross-Site Scripting.

Comprendre les directives CSP essentielles pour WordPress

Une CSP est définie via un en-tête HTTP Content-Security-Policy. Chaque directive contrôle une catégorie de ressource. Voici les plus importantes pour un site WordPress :

Les directives de base

• default-src : source par défaut pour toutes les ressources non spécifiées
• script-src : sources autorisées pour les fichiers JavaScript — c’est la directive anti-XSS la plus critique
• style-src : sources pour les feuilles de style CSS
• img-src : sources pour les images
• font-src : sources pour les polices (Google Fonts, etc.)
• connect-src : autorise les appels AJAX/fetch/WebSocket
• frame-src : contrôle les iframes embarquées (YouTube, Vimeo, etc.)
• object-src 'none' : bloque Flash et autres plugins — toujours mettre à none
• base-uri 'self' : empêche les attaques de détournement de base URL
• form-action 'self' : interdit l’envoi de formulaires vers des domaines tiers

Les valeurs de source

• 'self' : votre domaine uniquement
• 'none' : aucune source autorisée
• 'unsafe-inline' : ⚠️ autorise les scripts/styles inline — à éviter autant que possible
• 'unsafe-eval' : ⚠️ autorise eval() — à éviter absolument
• 'nonce-XYZ' : autorise un script spécifique identifié par un jeton unique
• 'strict-dynamic' : propagation de confiance via nonce pour les scripts dynamiques

Implémenter une CSP sur WordPress : 3 méthodes

Méthode 1 : Via le fichier .htaccess (Apache)

Si votre hébergeur utilise Apache (la majorité des hébergements WordPress mutualisés), c’est la méthode la plus simple. Ajoutez ces lignes dans votre .htaccess, avant la section WordPress :

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://www.google-analytics.com; frame-src https://www.youtube.com https://www.google.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

Pour aller plus loin sur la sécurisation de votre .htaccess, lisez notre guide : Sécuriser le fichier .htaccess WordPress : Guide Complet 2026.

Méthode 2 : Via functions.php ou un plugin personnalisé

Cette approche est préférable si vous souhaitez un contrôle programmatique ou si vous utilisez un serveur Nginx :

// À placer dans le functions.php du thème enfant
function securitewp_add_csp_header() {
    $csp = "default-src 'self'; ";
    $csp .= "script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; ";
    $csp .= "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; ";
    $csp .= "font-src 'self' https://fonts.gstatic.com; ";
    $csp .= "img-src 'self' data: https:; ";
    $csp .= "object-src 'none'; ";
    $csp .= "base-uri 'self'; ";
    $csp .= "form-action 'self';";
    
    header("Content-Security-Policy: " . $csp);
}
add_action('send_headers', 'securitewp_add_csp_header');

Important : utilisez toujours un thème enfant pour ce type de modification. Une mise à jour du thème parent effacerait votre code.

Méthode 3 : Via les plugins de sécurité

Si vous préférez une interface graphique, plusieurs plugins intègrent la gestion CSP :

• Sucuri Security : paramètre CSP dans les options d’en-têtes HTTP
• WP Headers and Security : interface dédiée à tous les en-têtes de sécurité
• Headers Security Advanced & HSTS WP : solution légère et bien documentée

Consultez notre guide sur les en-têtes de sécurité HTTP pour WordPress pour une vue complète de tous les headers à configurer (HSTS, X-Frame-Options, etc.).

La méthode recommandée : CSP en mode Report-Only d’abord

Déployer une CSP stricte d’emblée sur un site WordPress existant est risqué : vous pourriez casser des fonctionnalités (éditeur Gutenberg, plugins de page builder, scripts tiers). La bonne pratique est de commencer par le mode Report-Only.

Au lieu de bloquer les violations, ce mode les enregistre uniquement. Utilisez l’en-tête :

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

Puis analysez les rapports pour identifier toutes les ressources légitimes à autoriser avant de passer à la politique réelle. Des services comme Report URI (report-uri.com) ou Mozilla Observatory offrent des tableaux de bord gratuits pour analyser vos violations CSP.

Les problèmes CSP les plus courants sur WordPress (et leurs solutions)

Gutenberg / l’éditeur bloque

Gutenberg utilise des scripts inline et des workers. Ajoutez 'unsafe-inline' à script-src pour l’administration (wp-admin), et restreignez uniquement le front-end. Vous pouvez conditionner l’application de la CSP via PHP :

if (!is_admin()) {
    header("Content-Security-Policy: ...");
}

Les plugins de page builder (Elementor, Divi)

Ces plugins utilisent massivement les scripts inline. La solution propre est d’utiliser des nonces CSP — un jeton unique par requête que WordPress peut injecter automatiquement. Depuis WordPress 6.4, la fonction wp_nonce_field() intègre ce mécanisme.

Google Analytics / Tag Manager

Ajoutez ces domaines à vos directives :

script-src https://www.googletagmanager.com https://www.google-analytics.com;
connect-src https://www.google-analytics.com https://analytics.google.com;

Les polices Google Fonts

style-src https://fonts.googleapis.com;
font-src https://fonts.gstatic.com;

CSP et la récente attaque supply chain Smart Slider 3 Pro

L’attaque supply chain qui a frappé Smart Slider 3 Pro en avril 2026 (version 3.5.1.35) illustre parfaitement pourquoi la CSP seule ne suffit pas. Le malware injectait du code PHP côté serveur — un vecteur que la CSP ne couvre pas, puisqu’elle n’opère que dans le navigateur.

Cependant, une CSP stricte aurait pu limiter les dommages côté client : en bloquant les connexions vers le serveur C2 (wpjs1.com) via la directive connect-src, elle aurait empêché l’exfiltration de données sensibles depuis les navigateurs des visiteurs.

⚠️ La CSP est une couche de défense parmi d’autres. Elle ne remplace pas les mises à jour régulières, l’audit de vos plugins, ni la surveillance de votre site. Retrouvez toutes les mesures essentielles dans notre Checklist Sécurité WordPress 2026.

Tester et valider votre CSP WordPress

Avant de considérer votre CSP comme opérationnelle, testez-la avec ces outils gratuits :

• Mozilla Observatory (observatory.mozilla.org) : note votre site de A à F avec recommandations détaillées
• CSP Evaluator (csp-evaluator.withgoogle.com) : outil Google pour analyser la robustesse de votre politique
• Security Headers (securityheaders.com) : vérifie tous vos en-têtes de sécurité en un coup d’œil
• Outils développeur Chrome/Firefox : onglet Console → les violations CSP y apparaissent en rouge

Une bonne CSP WordPress devrait viser au minimum le grade B sur Mozilla Observatory, avec pour objectif le grade A.

FAQ — Content Security Policy WordPress

La CSP est-elle compatible avec tous les hébergeurs WordPress ?

Oui, dans la quasi-totalité des cas. Sur Apache (hébergements mutualisés), la méthode .htaccess fonctionne sur O2switch, OVH, Ionos, Hostinger, etc. Sur Nginx, vous devrez modifier la configuration serveur ou passer par PHP (functions.php). Certains hébergeurs gérés (WP Engine, Kinsta) permettent de définir des en-têtes custom via leur interface.

La CSP peut-elle casser mon site WordPress ?

Oui, si mal configurée. C’est pourquoi le mode Content-Security-Policy-Report-Only est indispensable avant toute mise en production. Testez toujours sur un environnement de staging d’abord. Les erreurs les plus fréquentes concernent les scripts inline de Gutenberg et les ressources tierces (Google Fonts, analytics).

Faut-il une CSP si j’ai déjà un pare-feu applicatif (WAF) ?

Oui, les deux sont complémentaires. Le WAF filtre les requêtes malveillantes côté serveur ; la CSP agit côté navigateur. Selon Patchstack, seulement 26 % des attaques d’exploitation de vulnérabilités sont bloquées par les hébergeurs — le reste dépend de vos propres protections. La défense en profondeur (plusieurs couches de sécurité) est l’approche recommandée par le NIST et l’OWASP.

Quelle est la différence entre CSP et X-Frame-Options ?

X-Frame-Options est un en-tête plus ancien qui empêche uniquement le clickjacking (votre site embarqué dans une iframe). La CSP couvre ce cas avec la directive frame-ancestors, en plus de dizaines d’autres vecteurs d’attaque. On recommande d’utiliser les deux pour maximiser la compatibilité avec les anciens navigateurs.

Conclusion : la CSP, un bouclier essentiel pour votre WordPress

La Content Security Policy est l’une des protections les plus puissantes disponibles pour WordPress — et l’une des plus sous-utilisées. En bloquant l’exécution de scripts non autorisés directement dans le navigateur de vos visiteurs, elle forme une dernière ligne de défense contre les attaques XSS, qu’elles proviennent d’une faille dans un plugin, d’une injection dans votre base de données, ou d’une compromission de votre chaîne d’approvisionnement.

La mise en place prend moins d’une heure avec la méthode .htaccess ou functions.php décrite dans ce guide. Commencez en mode Report-Only, observez les violations pendant quelques jours, ajustez, puis activez la politique définitive.

Votre site WordPress n’est pas encore sécurisé à 100 % ? L’équipe SecuriteWP réalise des audits de sécurité complets et des interventions post-hack pour vous remettre sur pied rapidement. Contactez-nous →