En-têtes de Sécurité HTTP pour WordPress : Guide Complet 2026

Pourquoi votre site WordPress est vulnérable sans en-têtes de sécurité HTTP

Selon le rapport Patchstack 2025, 97 % des vulnérabilités WordPress proviennent de plugins ou thèmes — mais une part non négligeable des attaques réussies exploite l'absence de protections côté navigateur. Les en-têtes HTTP de sécurité constituent la dernière ligne de défense entre votre serveur et le navigateur de vos visiteurs.

Sans ces en-têtes correctement configurés, votre site WordPress reste exposé à :

• Attaques XSS (Cross-Site Scripting) : injection de scripts malveillants dans vos pages
• Clickjacking : votre site encapsulé dans une iframe invisible pour tromper vos visiteurs
• MIME sniffing : le navigateur exécute des fichiers comme du code, même si ce n'est pas leur type déclaré
• Écoutes réseau : connexions non chiffrées capturées en clair
• Fuites d'informations via Referer : transmission de données sensibles à des tiers

Un audit sur SecurityHeaders.com révèle que plus de 80 % des sites WordPress publics obtiennent la note D ou F en matière d'en-têtes de sécurité. Ce guide va changer ça.

Les 6 en-têtes de sécurité HTTP indispensables pour WordPress

1. Content-Security-Policy (CSP)

L'en-tête Content-Security-Policy est le plus puissant — et le plus complexe. Il définit précisément quelles sources de contenu (scripts, styles, images, polices) le navigateur est autorisé à charger.

Exemple de base pour WordPress :

Content-Security-Policy : default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data : https:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'

⚠️ WordPress utilise massivement 'unsafe-inline' pour ses scripts. Commencez en mode report-only pour identifier les blocages avant de passer en mode actif.

2. HTTP Strict-Transport-Security (HSTS)

HSTS force le navigateur à toujours utiliser HTTPS pour votre domaine, même si l'utilisateur tape http://. Cela élimine les attaques de type SSL stripping.

Strict-Transport-Security : max-age=31536000; includeSubDomains; preload

Important : n'activez HSTS qu'une fois votre certificat SSL parfaitement configuré et stable. Un max-age de 31 536 000 secondes (1 an) est recommandé pour l'inclusion dans la liste HSTS preload des navigateurs.

3. X-Content-Type-Options

Cet en-tête empêche le navigateur de deviner (« sniffer ») le type MIME d'un fichier. Sans lui, un fichier texte contenant du JavaScript pourrait être exécuté comme du code.

X-Content-Type-Options : nosniff

Simple, court, indispensable. À activer sans exception sur tout site WordPress.

4. X-Frame-Options

Protège contre les attaques de clickjacking en empêchant votre site d'être intégré dans un <iframe> externe.

X-Frame-Options : SAMEORIGIN

Utilisez DENY pour interdire tout iframe, ou SAMEORIGIN pour n'autoriser que les iframes de votre propre domaine. Notez que la directive frame-ancestors de la CSP remplace progressivement cet en-tête dans les navigateurs modernes.

5. Referrer-Policy

Contrôle les informations envoyées dans l'en-tête Referer lorsqu'un visiteur clique sur un lien quittant votre site.

Referrer-Policy : strict-origin-when-cross-origin

Cette valeur envoie uniquement l'origine (sans le chemin ni les paramètres) lors des navigations cross-origin, protégeant les URL sensibles de vos utilisateurs connectés.

6. Permissions-Policy

Successeur de Feature-Policy, cet en-tête contrôle l'accès aux fonctionnalités du navigateur (caméra, microphone, géolocalisation) par votre site et les iframes embarquées.

Permissions-Policy : camera=(), microphone=(), geolocation=(), payment=(self)

Pour un site WordPress standard (sans e-commerce), désactiver caméra, micro et géolocalisation est une bonne pratique défensive.

Comment ajouter les en-têtes de sécurité sur WordPress

Méthode 1 : Via .htaccess (serveurs Apache)

C'est la méthode la plus courante sur les hébergements mutualisés. Ajoutez ces lignes dans votre fichier .htaccess, avant le bloc WordPress :

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data : https:; font-src 'self' data:; frame-ancestors 'self'"
</IfModule>

Après modification, vérifiez que votre site fonctionne toujours correctement — la CSP peut bloquer des ressources légitimes selon votre thème et vos plugins.

Méthode 2 : Via nginx.conf

Pour les serveurs Nginx (VPS, cloud), ajoutez dans le bloc server de votre configuration :

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data : https:; font-src 'self' data:; frame-ancestors 'self'" always;

Rechargez ensuite nginx : sudo nginx -t && sudo systemctl reload nginx

Méthode 3 : Via functions.php de WordPress

Si vous n'avez pas accès à la configuration serveur, vous pouvez injecter les en-têtes via PHP dans le fichier functions.php de votre thème enfant :

add_action('send_headers', function() {
  header('X-Content-Type-Options : nosniff');
  header('X-Frame-Options : SAMEORIGIN');
  header('Referrer-Policy : strict-origin-when-cross-origin');
  header('Permissions-Policy : camera=(), microphone=(), geolocation=()');
  if (is_ssl()) {
    header('Strict-Transport-Security : max-age=31536000; includeSubDomains');
  }
});

⚠️ Cette méthode ne couvre pas les fichiers statiques (CSS, JS, images) servis directement par le serveur. Préférez la configuration serveur quand c'est possible.

Méthode 4 : Via un plugin WordPress

Si vous préférez une solution sans code, plusieurs plugins gèrent les en-têtes de sécurité :

• Wordfence : propose certains en-têtes dans ses options de durcissement
• Solid Security (anciennement iThemes Security) : interface complète pour les headers
• Headers Security Advanced & HSTS WP : plugin dédié, léger et efficace

Pour aller plus loin sur la sécurisation globale de votre installation, consultez notre checklist sécurité WordPress 2026 en 20 points et notre guide pour sécuriser le fichier wp-config.php.

Vérifier et tester vos en-têtes de sécurité

Une fois les en-têtes configurés, vérifiez-les avec ces outils gratuits :

• SecurityHeaders.com : analyse complète avec note de A+ à F
• Firefox / Chrome DevTools : onglet Network → cliquez sur votre domaine → Headers
• Mozilla Observatory : audit complet TLS + Headers + CSP

Visez au minimum la note B sur SecurityHeaders.com. La note A+ est atteignable en configurant une CSP stricte sans unsafe-inline, ce qui nécessite de refactoriser certains scripts WordPress.

Pour identifier d'autres failles de configuration, notre guide d'audit de sécurité WordPress vous guidera pas à pas.

FAQ : En-têtes de sécurité HTTP et WordPress

Les en-têtes HTTP peuvent-ils casser mon site WordPress ?

Oui, principalement la Content-Security-Policy si elle est trop restrictive. Commencez avec Content-Security-Policy-Report-Only pour tester sans bloquer, puis ajustez avant d'activer en mode actif.

Est-ce que mon hébergeur WordPress configure ces en-têtes automatiquement ?

Rarement. Selon l'étude Patchstack sur le mythe de l'hébergement sécurisé (janvier 2026), seulement 26 % des attaques sont bloquées par les hébergeurs. La configuration des en-têtes de sécurité reste généralement de la responsabilité du propriétaire du site.

HSTS est-il dangereux à activer ?

Il peut l'être si votre certificat SSL expire ou si vous revenez en HTTP. Avec un max-age long, votre site deviendra inaccessible en HTTP pour les visiteurs dont le navigateur a mémorisé l'en-tête. Assurez-vous d'avoir un renouvellement automatique SSL (Let's Encrypt) avant d'activer HSTS.

X-Frame-Options est-il encore utile en 2026 ?

Oui, pour la compatibilité avec les anciens navigateurs. Les navigateurs modernes utilisent désormais la directive frame-ancestors de la CSP, mais X-Frame-Options reste une couche défensive supplémentaire sans coût.

Conclusion : Sécurisez la couche navigateur de votre WordPress

Les en-têtes de sécurité HTTP sont une mesure de durcissement souvent négligée, pourtant rapide à mettre en place et très efficace. En quelques lignes dans votre .htaccess ou votre configuration nginx, vous ajoutez une couche de protection significative contre les attaques XSS, le clickjacking et les écoutes réseau.

Récapitulatif des en-têtes à activer en priorité :

1. ✅ X-Content-Type-Options : nosniff
2. ✅ X-Frame-Options : SAMEORIGIN
3. ✅ Strict-Transport-Security (si HTTPS stable)
4. ✅ Referrer-Policy : strict-origin-when-cross-origin
5. ✅ Permissions-Policy
6. ⚙️ Content-Security-Policy (à tester avant activation)

Votre site est toujours vulnérable ? SecuriteWP propose un audit complet et une remédiation sur-mesure. Découvrez nos services de sécurisation WordPress →