Comment configurer une Content-Security-Policy dans WordPress

Content-Security-Policy (CSP) est l'un des en-têtes de sécurité les plus puissants disponibles, mais c'est aussi l'un des plus délicats à mettre en place correctement sur WordPress. La raison est simple : le coeur de WordPress, les thèmes et les extensions adorent tous utiliser des scripts et styles inline. Une CSP stricte les bloque par défaut, ce qui signifie que votre site peut casser de manière inattendue si vous ne planifiez pas soigneusement. Ce guide vous accompagne tout au long du processus, de la compréhension de ce que fait la CSP jusqu'au déploiement d'une politique prête pour la production.

Pourquoi la CSP est particulièrement difficile sur WordPress

La plupart des sites WordPress reposent fortement sur des schémas que la CSP est conçue pour restreindre. Voici les problèmes les plus courants que vous rencontrerez :

• Scripts inline : de nombreuses extensions injectent du JavaScript directement dans le HTML via des balises <script> sans attribut src. Les page builders comme Elementor, WPBakery et Divi le font de manière intensive.
• Styles inline : le Customizer WordPress, les blocs Gutenberg et la plupart des thèmes ajoutent des attributs style ou des blocs <style> à la page. Une CSP stricte sans 'unsafe-inline' pour les styles cassera l'apparence visuelle de votre site.
• Utilisation d'eval() : certaines extensions utilisent la fonction eval() de JavaScript ou des constructions similaires, ce qui nécessite la directive 'unsafe-eval'.
• Ressources tierces : Google Analytics, Google Fonts, reCAPTCHA, vidéos YouTube intégrées, widgets de réseaux sociaux. Chacune nécessite sa propre entrée CSP.

Pour toutes ces raisons, vous ne devriez jamais copier une CSP d'un autre site et la coller dans votre configuration WordPress. Chaque site WordPress a une combinaison unique d'extensions et de thèmes, donc chaque CSP doit être adaptée individuellement.

Commencez par le mode Report-Only pour découvrir ce qui casserait

La façon la plus sûre de commencer est avec l'en-tête Content-Security-Policy-Report-Only. Cet en-tête se comporte exactement comme la CSP, sauf qu'il ne bloque réellement rien. Au lieu de cela, il enregistre les violations dans la console du navigateur afin que vous puissiez voir ce que votre politique empêcherait. Rien ne casse sur votre site, mais vous obtenez une visibilité totale.

Ajoutez ceci à votre fichier .htaccess (Apache) :

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';"
</IfModule>

Ou pour Nginx :

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';" always;

Laissez ceci en place pendant au moins quelques jours et parcourez toutes les pages importantes de votre site (accueil, articles de blog, formulaire de contact, paiement WooCommerce le cas échéant). Chaque page peut charger différentes extensions et ressources.

Comment trouver les violations CSP dans la console du navigateur

Après avoir activé le mode Report-Only, ouvrez votre site dans Chrome ou Firefox et appuyez sur F12 pour ouvrir les DevTools. Allez dans l'onglet Console. Les violations CSP apparaissent comme des messages d'avertissement qui ressemblent à ceci :

[Report Only] Refused to load the script 'https://www.googletagmanager.com/gtag/js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'".

Chaque message de violation vous indique exactement ce qui a été bloqué et quelle directive en est la cause. Collectez tous ces messages et utilisez-les pour construire votre liste d'autorisation. Visitez chaque page importante de votre site, y compris les pages avec formulaires, sliders, cartes et toute page chargeant des extensions spécifiques.

Comprendre les directives CSP clés pour WordPress

Voici les directives que vous devrez très probablement configurer :

• default-src : la solution de repli pour tous les types de ressources non explicitement listés. Définissez ceci sur 'self' comme base.
• script-src : contrôle d'où le JavaScript peut être chargé. Vous aurez presque certainement besoin de 'unsafe-inline' sur WordPress. Si une extension utilise eval(), vous avez aussi besoin de 'unsafe-eval'.
• style-src : contrôle d'où le CSS peut être chargé. WordPress nécessite presque toujours 'unsafe-inline' ici.
• img-src : contrôle les sources d'images. Utilisez 'self' data: https: pour autoriser vos propres images, les data URIs (utilisées par de nombreuses extensions) et toute image en HTTPS.
• font-src : contrôle le chargement des polices. Si vous utilisez Google Fonts, ajoutez https://fonts.gstatic.com.
• connect-src : contrôle où JavaScript peut faire des requêtes réseau (AJAX, fetch, WebSocket). L'admin WordPress l'utilise intensivement pour la REST API et l'API Heartbeat.
• frame-src : contrôle quels domaines peuvent être chargés dans des iframes. Nécessaire pour les intégrations YouTube (https://www.youtube.com), Google Maps (https://www.google.com) et reCAPTCHA (https://www.google.com).
• media-src : contrôle les sources audio et vidéo. Généralement 'self' suffit sauf si vous intégrez des médias externes.
• object-src : contrôle les plugins comme Flash. Définissez sur 'none' car Flash est mort et cette directive empêche surtout les vecteurs d'attaque hérités.

Construire votre politique étape par étape

Commencez par une base restrictive et ajoutez des exceptions au fur et à mesure que vous découvrez des violations :

1. Commencez par une politique minimale : default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. Ajoutez unsafe-inline pour les scripts et styles : c'est presque toujours nécessaire sur WordPress. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. Ajoutez les URIs data: pour les images et polices : de nombreuses extensions utilisent des images encodées en base64. img-src 'self' data: https:; font-src 'self' data:;
4. Autorisez votre CDN : si vous utilisez un CDN comme Cloudflare ou BunnyCDN, ajoutez son domaine à script-src, style-src, img-src et font-src.
5. Ajoutez les services tiers un par un : pour chaque violation CSP dans la console, ajoutez le domaine spécifique à la directive correspondante.

Entrées d'autorisation courantes pour les sites WordPress

Voici une référence des domaines dont vous pourriez avoir besoin pour les intégrations WordPress populaires :

• Google Fonts : style-src https://fonts.googleapis.com et font-src https://fonts.gstatic.com
• Google Analytics / GA4 : script-src https://www.googletagmanager.com https://www.google-analytics.com et connect-src https://www.google-analytics.com https://analytics.google.com
• Google Maps : script-src https://maps.googleapis.com et frame-src https://www.google.com
• Intégrations YouTube : frame-src https://www.youtube.com https://www.youtube-nocookie.com
• reCAPTCHA : script-src https://www.google.com https://www.gstatic.com et frame-src https://www.google.com
• Gravatar : img-src https://secure.gravatar.com https://www.gravatar.com
• WordPress.org : img-src https://s.w.org https://ps.w.org (pour les icônes d'extensions/thèmes dans l'admin)

Un exemple complet de CSP pour WordPress

Voici une CSP réaliste pour un site WordPress qui utilise Google Analytics, Google Fonts, des intégrations YouTube et Gravatar. Adaptez-la à vos besoins spécifiques :

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

Extensions WordPress pour gérer la CSP

Si l'édition des fichiers de configuration serveur vous semble intimidante, ces extensions peuvent vous aider :

• HTTP Headers : une extension gratuite qui vous permet de définir tous les en-têtes de sécurité depuis l'admin WordPress. Elle prend en charge la CSP avec une interface conviviale où vous pouvez ajouter des sources par directive.
• Really Simple SSL Pro : inclut un module Content-Security-Policy avec journalisation des violations et corrections en un clic pour les problèmes courants.
• Extension CSP de Jeremykendall : une option légère qui se concentre uniquement sur la gestion de la CSP.

Gardez à l'esprit que les en-têtes CSP basés sur des extensions ne sont envoyés que pour les pages traitées par WordPress. Les ressources statiques servies directement par votre serveur web ne porteront pas l'en-tête. Pour une protection complète, la configuration au niveau du serveur est préférable.

Passer du mode Report-Only au mode d'application

Une fois que vous avez fonctionné en mode Report-Only pendant au moins une semaine et résolu toutes les violations, vous êtes prêt à basculer. Changez simplement le nom de l'en-tête de Content-Security-Policy-Report-Only à Content-Security-Policy. Gardez la console de votre navigateur ouverte pendant les premières heures et surveillez les violations que vous auriez pu manquer. Si quelque chose casse, vous pouvez toujours revenir au mode Report-Only pendant que vous le corrigez.

Vérifiez votre CSP avec InspectWP

Après avoir mis en oeuvre votre Content-Security-Policy, lancez un nouveau scan InspectWP. La section des en-têtes de sécurité de votre rapport montrera si un en-tête CSP est présent et s'il est en mode Report-Only ou en mode d'application. Utilisez ceci comme vérification rapide après chaque changement pour confirmer que votre politique est toujours envoyée correctement.