Headers de sécurité WordPress : activer CSP, HSTS et X-Frame-Options sans casser le site

Pourquoi renforcer WordPress avec des headers de sécurité

Les headers HTTP sont des garde-fous livrés par ton serveur ou ton CDN au navigateur. Ils encadrent précisément ce que la page peut charger, qui peut l’encadrer (iframe), comment le transport doit se dérouler (HTTPS strict), etc. Au-delà des plugins, ces règles côté serveur agissent comme une ceinture de sécurité : elles bloquent les comportements dangereux par défaut et réduisent la surface d’attaque. Résultat : moins d’XSS exploitables, moins de détournements de contenu, et un SEO indirectement favorisé par une meilleure fiabilité perçue et par la performance (car le nettoyage des ressources est souvent l’occasion de rationaliser les chargements).

Concrètement, CSP contrôle les sources autorisées pour les scripts, styles, images, polices, connexions AJAX/WebSocket, iframes, etc. HSTS oblige le navigateur à utiliser HTTPS, empêchant le downgrade vers HTTP. X-Frame-Options (et son remplaçant moderne frame-ancestors en CSP) empêche l’intégration malveillante de ta page dans un iframe tiers (clickjacking). Une bonne stratégie consiste à déployer par étapes, avec Content-Security-Policy-Report-Only au début pour observer les violations sans rien casser.

Méthode sans casse : commence par le Report-Only

Le mode Report-Only de CSP n’applique pas le blocage : il envoie simplement des rapports quand quelque chose violerait la politique. Tu vois ainsi toute la réalité de ton site (thème, plugins, pixels marketing, iframes), sans perturber tes visiteurs. Tu ajustes ensuite ta liste blanche jusqu’à faire disparaître les alertes, puis tu passes en application stricte.

Le pipeline gagnant en 5 étapes

1. Inventaire : parcours quelques pages clés (accueil, article, page produit, panier, checkout, formulaire, pages avec cartes/vidéos) et liste les domaines contactés : JS, CSS, images, fonts, iframes, API, WebSocket.
2. Report-Only : active une CSP d’observation qui loggue les violations (console navigateur + endpoint de rapport).
3. Ajustements : affine script-src, style-src, font-src, img-src, connect-src, frame-src… Retire progressivement les assouplissements dangereux ('unsafe-inline', 'unsafe-eval').
4. Tests métier : vérifie chaque parcours critique (inscription, paiement, recherche, envoi de formulaire, lecture vidéo, carte).
5. Application stricte : quand le bruit est retombé, active Content-Security-Policy (non report) et surveille.

Note sur HSTS : il n’existe pas de report-only pour HSTS. Pour limiter le risque, commence avec un max-age très bas (par ex. 300 secondes), puis augmente progressivement jusqu’à 6 mois ou 1 an avant de considérer le preload.

CSP WordPress : une politique solide qui n’étrangle pas ton site

Une CSP trop restrictive va casser des fonctions clés. Une CSP trop permissive perd son intérêt. L’objectif : une liste blanche précise et maintenable, avec un plan pour se débarrasser des 'unsafe-inline' et 'unsafe-eval'.

Point de départ : une CSP de base en Report-Only

Voici un exemple générique pour un site WordPress classique avec Google Fonts, un peu de tracking et des vidéos YouTube. Adapte les domaines à ton stack réel.

Content-Security-Policy-Report-Only: \  default-src 'self'; \  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com https://www.google.com https://www.gstatic.com https://www.recaptcha.net 'unsafe-inline'; \  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; \  font-src 'self' https://fonts.gstatic.com data:; \  img-src 'self' data: https:; \  connect-src 'self' https://www.google-analytics.com https://stats.g.doubleclick.net; \  frame-src 'self' https://www.youtube-nocookie.com https://player.vimeo.com https://www.google.com; \  base-uri 'self'; \  frame-ancestors 'self'; \  form-action 'self'; \  report-uri https://csp.example.com/report; \  report-to csp-endpoint

Explications rapides : default-src 'self' verrouille tout par défaut. Les directives script-src, style-src, font-src ouvrent finement. frame-src autorise YouTube/Vimeo et certains widgets Google. report-uri/report-to centralisent les violations. Commence ainsi, navigue intensément sur le site, puis lis les rapports pour découvrir les domaines à ajouter.

Sortir proprement des scripts inline : nonces et hashes

WordPress (et certains plugins) injectent souvent du JavaScript inline. En CSP stricte, ces blocs sont bloqués, sauf si tu utilises un nonce (aléatoire, par requête) ou un hash du contenu inline. La voie pragmatique : passer progressivement aux nonces pour les scripts de ton thème et des plugins sous contrôle.

Exemple minimaliste côté thème pour ajouter un nonce CSP aux balises <script> générées par WordPress et envoyer l’en-tête correspondant :

// functions.php (thème enfant recommandé)add_action('send_headers', function () {    if (!is_ssl()) { return; }    // Génère un nonce par requête et stocke-le pour réutilisation    $nonce = base64_encode(random_bytes(16));    global $wpb_csp_nonce; $wpb_csp_nonce = $nonce;    // Version report-only pour commencer    header("Content-Security-Policy-Report-Only: " .        "default-src 'self'; " .        "script-src 'self' 'nonce-{$nonce}' https://www.googletagmanager.com; " .        "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; " .        "font-src 'self' https://fonts.gstatic.com data:; " .        "img-src 'self' data: https:; " .        "connect-src 'self'; " .        "frame-src 'self' https://www.youtube-nocookie.com; " .        "report-uri https://csp.example.com/report;");});// Ajoute l’attribut nonce aux scripts enfilésadd_filter('script_loader_tag', function ($tag, $handle, $src) {    global $wpb_csp_nonce; if (!$wpb_csp_nonce) { return $tag; }    // Ajoute nonce à toutes les balises <script> avec src    if (false !== strpos($tag, '<script ')) {        $tag = str_replace('<script ', "<script nonce=\"{$wpb_csp_nonce}\" ", $tag);    }    return $tag;}, 10, 3);// Pour les scripts inline contrôlés par le thèmefunction wpb_inline_script_with_nonce($code){    global $wpb_csp_nonce;    echo "<script nonce=\"{$wpb_csp_nonce}\">{$code}</script>";}

Ensuite, remplace les blocs inline bricolés dans les templates par des scripts enfilés via wp_add_inline_script() et ajoute le nonce comme ci-dessus. Pour des plugins tiers incontrôlables, accepte temporairement 'unsafe-inline' en Report-Only, puis remonte les problèmes aux éditeurs ou isole ces fonctionnalités sur des templates dédiés avec une CSP plus permissive.

Gérer correctement les polices (Google Fonts et locales)

Les polices sont souvent la première source de violations. Trois bonnes pratiques :

• Autoriser les bonnes origines : style-src https://fonts.googleapis.com et font-src https://fonts.gstatic.com.
• Passer en local quand c’est possible pour simplifier la CSP et améliorer la confidentialité.
• Préconnecter : <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> pour accélérer le chargement.

Iframes et widgets (YouTube, Maps, formulaires)

Les vidéos et cartes nécessitent d’ouvrir frame-src vers les bons domaines (ex. https://www.youtube-nocookie.com, https://player.vimeo.com, https://www.google.com pour Maps). Si ton site est intégré ailleurs (partenaires), ajuste frame-ancestors pour les autoriser explicitement. Évite les jokers * : autorise seulement ce qui est nécessaire.

HSTS WordPress : HTTPS obligatoire, sans se piéger

Strict-Transport-Security ordonne au navigateur d’utiliser exclusivement HTTPS. Une fois activé avec une durée longue, le retour en arrière est difficile. Procède ainsi :

1. Pré-requis : certificat TLS valide, redirections 301 HTTP→HTTPS partout, pas de contenu mixte.
2. Démarrage prudent : max-age=300; includeSubDomains pour 5 minutes. Observe les logs.
3. Montée en puissance : 1 jour, 1 semaine, 1 mois… jusqu’à 6–12 mois.
4. Option preload : seulement quand tout l’écosystème (sous-domaines) est 100 % prêt au HTTPS.

Strict-Transport-Security: max-age=300; includeSubDomains

Quand tout est OK, vise max-age=15552000 (180 jours) ou plus, puis éventuellement preload (après validation stricte des conditions).

X-Frame-Options et frame-ancestors : contrer le clickjacking

X-Frame-Options: SAMEORIGIN est largement supporté et simple à déployer. Sa version ALLOW-FROM est obsolète et imparfaitement supportée. La voie moderne est d’utiliser frame-ancestors dans CSP, plus expressive :

X-Frame-Options: SAMEORIGINContent-Security-Policy: frame-ancestors 'self' https://partenaire.exemple

Teste les pages qui doivent être intégrées dans un iframe par des partenaires et ajuste précisément la directive, sans ouvrir plus que nécessaire.

Configuration par serveur : Nginx, Apache et Cloudflare

Exemples Nginx

# /etc/nginx/conf.d/security.conf (inclus dans le bloc server)# Phase 1 : Report-Onlyadd_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src 'self' data: https:; connect-src 'self'; frame-src 'self'; report-uri https://csp.example.com/report" always;# HSTS (prudence au début)add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;# X-Frame-Options et autres headers utilesadd_header X-Frame-Options "SAMEORIGIN" always;add_header X-Content-Type-Options "nosniff" always;add_header Referrer-Policy "strict-origin-when-cross-origin" always;# Phase 2 : Application stricte (quand prêt)# add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-...'; style-src 'self'; ..." always;

Exemples Apache

# Active mod_headers# a2enmod headers && systemctl reload apache2# .htaccess ou VirtualHost<IfModule mod_headers.c>  Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src 'self' data: https:; connect-src 'self'; frame-src 'self'; report-uri https://csp.example.com/report"  Header always set Strict-Transport-Security "max-age=300; includeSubDomains"  Header always set X-Frame-Options "SAMEORIGIN"  Header always set X-Content-Type-Options "nosniff"  Header always set Referrer-Policy "strict-origin-when-cross-origin"</IfModule>

Cloudflare (sans toucher au serveur)

Cloudflare permet d’ajouter/modifier des headers en périphérie. Deux options simples :

1. Rules → Transform Rules → HTTP Response Header Modification : crée une règle “Set” pour Content-Security-Policy-Report-Only, une pour Strict-Transport-Security, et une pour X-Frame-Options.
2. Workers (souple, versionné) : intercepte la réponse et ajoute les headers.

// worker.jsexport default {  async fetch(request, env, ctx) {    const response = await fetch(request);    const newHeaders = new Headers(response.headers);    newHeaders.set('Content-Security-Policy-Report-Only', "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src 'self' data: https:; connect-src 'self'; frame-src 'self'; report-uri https://csp.example.com/report");    newHeaders.set('Strict-Transport-Security', 'max-age=300; includeSubDomains');    newHeaders.set('X-Frame-Options', 'SAMEORIGIN');    newHeaders.set('X-Content-Type-Options', 'nosniff');    newHeaders.set('Referrer-Policy', 'strict-origin-when-cross-origin');    return new Response(response.body, { status: response.status, statusText: response.statusText, headers: newHeaders });  }};

Construire une liste blanche propre et durable

La clé d’une CSP maintenable, c’est l’inventaire. Ouvre les DevTools, onglet Réseau et Console ; parcours les gabarits clés (blog, produit, panier, checkout, page de contact, pages avec iframes). Note chaque domaine tiers : CDN du thème, polices, analytics, pixels, payment, chat, vidéos, cartes. Essaie de regrouper par fonctionnalité : “vidéo” (YouTube/Vimeo), “analytics” (GTM/GA4), “paiement” (Stripe, PayPal), “support” (Intercom), etc. Cela t’aidera à justifier chaque entrée et à couper celles devenues inutiles.

Pour évaluer la solidité de ta politique, l’outil CSP Evaluator de Google est d’une aide précieuse : il met en évidence les failles d’une directive (par ex. unsafe-inline, jokers trop larges) et propose des pistes d’amélioration. En complément, référence-toi aux recommandations de l’OWASP Secure Headers Project pour t’assurer que tu couvres l’essentiel.

Tests, monitoring et rollback : éviter les régressions

Ce que tu dois tester absolument

• Navigation anonyme ET connectée (si comptes clients ou membres).
• Formulaires (contact, inscription, devis), y compris reCAPTCHA.
• Parcours e-commerce complet : recherche produit → panier → checkout → paiement → retour de paiement.
• Médias intégrés : YouTube/Vimeo, Google Maps, carrousels.
• Appels AJAX/REST : filtres produits, ajout panier, recherche instantanée.

Outils et commandes utiles

# Vérifier rapidement les headers d’une pagecurl -sI https://www.exemple.com | sed -n '/^Content-Security-Policy\|^Content-Security-Policy-Report-Only\|^Strict-Transport-Security\|^X-Frame-Options/p'# Vérifier la présence d’erreurs CSP dans la console# (Ouvre DevTools → Console et recharge plusieurs pages clés)

Collecter les rapports CSP

Mets en place un endpoint simple qui reçoit les rapports JSON (via report-uri ou report-to). Tu peux utiliser un service spécialisé, un Worker Cloudflare, ou une petite route sur WordPress (REST API ou admin-ajax.php) qui loggue proprement les événements (date, page, directive violée, domaine). Trie par fréquence et par criticité : certaines violations sont bénignes (favicon oublié) ; d’autres bloqueraient un paiement.

Plan de rollback

Si une régression survient en production : repasse immédiatement la CSP en Report-Only, vide le cache CDN, invalide les pages, puis corrige la directive fautive. Pour HSTS, si tu n’as pas encore un max-age long, repasse à une durée plus courte le temps de corriger la configuration HTTPS (certificats, redirections). Ce plan doit être documenté et testé, surtout si tu as des pics de trafic commerciaux.

Cas WordPress fréquents et solutions

WooCommerce et parcours de paiement

Les passerelles de paiement (Stripe, PayPal, PayPlug…) utilisent des iframes, des appels connect-src et parfois des scripts chargés dynamiquement. Ajoute uniquement les domaines nécessaires et valide chaque mode de paiement en mobile et desktop. Surveille aussi form-action si un formulaire est posté vers un domaine externe.

Google Tag Manager, Analytics et consentement

GTM peut injecter des tags vers de nombreux domaines. Si tu restreins script-src à GTM/GA, certains tags tiers ne fonctionneront pas. Deux approches : 1) tout centraliser via GTM et ouvrir seulement les domaines nécessaires, 2) réduire l’usage de tags tiers non essentiels. En parallèle, garde la conformité RGPD via un CMP qui ne déclenche les scripts marketing qu’après consentement, toujours cohérent avec ta CSP.

reCAPTCHA et formulaires

Pour reCAPTCHA v2/v3, pense à script-src, frame-src et parfois connect-src vers google.com, gstatic.com et recaptcha.net. Teste tous les formulaires après chaque modification de CSP.

Back-office WordPress (/wp-admin)

L’administration charge beaucoup de scripts inline historiques. Applique une CSP plus permissive sur /wp-admin et stricte sur le frontal. Avec Nginx : deux blocs location ou deux add_header conditionnels. Avec Apache : règles .htaccess spécifiques sous wp-admin. Avec Cloudflare : une règle qui cible not(http.request.uri.path contains "/wp-admin") pour la politique stricte.

Multilingue, CDN d’images et sous-domaines

Si tu utilises un CDN d’images (WebP/AVIF dynamiques), n’oublie pas ce domaine dans img-src. Pour le multilingue, certains services chargent des fichiers de traduction à distance : ajoute-les à connect-src. Conserve une documentation à jour des domaines par fonctionnalité afin d’éviter les régressions à la prochaine refonte.

Checklist de déploiement progressif (CSP, HSTS, X-Frame-Options)

• Inventaire des domaines tiers par parcours clé.
• Activation CSP en Report-Only + endpoint de collecte.
• Nettoyage : retirer les domaines superflus, limiter les jokers.
• Gestion des scripts inline : nonces pour ton thème, plan de transition pour les plugins.
• Polices : passer en local ou autoriser précisément Fonts Google.
• Iframes : frame-src minimaliste, frame-ancestors pour contrôler qui peut intégrer.
• HSTS : démarrer à 300 s, monter graduellement, viser 6–12 mois.
• X-Frame-Options : SAMEORIGIN par défaut, exceptions via frame-ancestors.
• Tests fonctionnels complets (mobile/desktop, connecté/anonyme).
• Passage en application stricte + monitoring continu.
• Plan de rollback documenté.

Quand faire appel à des pros (et gagner du temps)

Déployer des headers solides demande de la méthode, des tests et parfois des arbitrages techniques avec ton thème et tes plugins. Si tu préfères te concentrer sur ton business, l’équipe WP Builders peut prendre en charge l’audit, la mise en place report-only, l’implémentation des nonces, la configuration Nginx/Apache/Cloudflare et la montée en application stricte — sans bloquer tes ventes ni tes formulaires. Nos interventions sont cadrées, versionnées et réversibles, avec un objectif : un WordPress plus sûr, plus propre et plus prévisible.

Conclusion : sécurité pragmatique, zéro casse

Les headers securite wordpress ne doivent ni ralentir ton équipe, ni brider tes fonctionnalités. Avec une csp wordpress en report-only csp d’abord, puis en application stricte, un hsts wordpress progressif et un x frame options sobre, tu crées un bouclier efficace. Ajoute à cela une discipline de tests, un monitoring clair et des configs reproductibles pour securiser nginx apache cloudflare, et ton site gagne en robustesse sans perdre en agilité. Et si tu veux l’assurance d’un déploiement propre du premier coup, on est là pour t’épauler.