Article SEO SEO Technique

En-têtes de sécurité WordPress : guide complet pour protéger votre site

Sommaire de l'article

Introduction

Les en-têtes de sécurité HTTP jouent un rôle crucial dans la protection d’un site WordPress contre de nombreuses attaques web courantes. Correctement configurés au niveau du serveur ou d’un pare-feu applicatif, ils ajoutent une couche de défense supplémentaire en indiquant au navigateur comment charger les ressources, gérer les scripts, chiffrer les échanges et protéger les données des utilisateurs.

Sans ces en-têtes, même un site à jour et protégé par un plugin de sécurité reste plus exposé aux attaques de type XSS (cross-site scripting), injection de scripts, clickjacking, ou fuites d’informations via l’en-tête Referer. Les en-têtes de sécurité ne remplacent pas les autres mesures (mises à jour, mots de passe forts, sauvegardes, WAF, etc.), mais ils complètent efficacement votre stratégie globale de sécurité.

Dans cet article, vous allez découvrir :

  • Ce que sont exactement les en-têtes HTTP et les principaux en-têtes de sécurité WordPress.
  • Les en-têtes essentiels à mettre en place (CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, etc.).
  • Les bonnes pratiques pour les configurer sur Apache, Nginx, via un plugin WordPress ou un CDN / WAF.
  • Des exemples concrets de directives et d’erreurs à éviter pour ne pas casser votre site.
  • Les outils pour analyser et tester vos en-têtes de sécurité.

Ce guide détaillé vous permettra de renforcer significativement la sécurité de votre site WordPress et d’améliorer la confiance de vos visiteurs, tout en restant compatible avec les bonnes pratiques de performance et de référencement.

Qu’est-ce qu’un en-tête HTTP ?

Un en-tête HTTP est une information envoyée par le serveur web au navigateur avant le corps de la réponse. Ces métadonnées servent à indiquer :

  • le type de contenu renvoyé (HTML, JSON, image, fichier, etc.) ;
  • la façon dont le navigateur doit traiter la réponse (mise en cache, sécurité, encodage, cookies, etc.) ;
  • des informations de diagnostic ou de contrôle (redirections, compression, langue, etc.).

Concrètement, lorsqu’un visiteur accède à votre site, son navigateur reçoit d’abord une série d’en-têtes, puis le code HTML et les autres ressources. Parmi ces en-têtes figurent les en-têtes de sécurité, qui donnent au navigateur des consignes strictes pour gérer le contenu et réduire la surface d’attaque.

En-têtes de sécurité WordPress : rôle et enjeux

Les en-têtes de sécurité HTTP sont conçus pour limiter ou bloquer des comportements que les attaquants exploitent fréquemment. Voici quelques exemples de menaces contre lesquelles ils peuvent aider :

  • Cross-Site Scripting (XSS) : injection de scripts malveillants dans les pages, souvent via des champs de formulaire ou des contenus mal filtrés.
  • Clickjacking : intégration de votre site dans une iframe invisible pour tromper l’utilisateur et lui faire cliquer sur des éléments à son insu.
  • Injection de contenu non autorisé : chargement de scripts ou ressources depuis des domaines tiers compromis.
  • Fuites de données : exposition involontaire de l’URL complète (avec paramètres sensibles) via le référent.
  • Attaques liées au type MIME : exécution de contenu alors qu’il ne devrait être que téléchargé ou traité comme un autre type.

En configurant correctement ces en-têtes, vous indiquez explicitement au navigateur ce qu’il a le droit de charger, d’exécuter ou d’afficher, ce qui réduit drastiquement l’impact potentiel d’une vulnérabilité applicative ou d’une configuration serveur imparfaite.

Principaux en-têtes de sécurité à connaître

1. Content-Security-Policy (CSP)

Content-Security-Policy (CSP) est l’un des en-têtes de sécurité les plus puissants. Il permet de définir précisément les sources autorisées pour chaque type de ressource :

  • script-src pour les scripts JavaScript,
  • style-src pour les feuilles de style CSS,
  • img-src pour les images,
  • font-src pour les polices,
  • frame-src ou child-src pour les iframes,
  • connect-src pour les requêtes AJAX / API, etc.

Une politique CSP de base peut, par exemple, n’autoriser que les ressources chargées depuis votre propre domaine :

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

Vous pouvez ensuite affiner les directives pour autoriser certains CDN de scripts ou de polices, par exemple :

Content-Security-Policy: default-src 'self'; script-src 'self' https://ajax.googleapis.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:;

CSP est particulièrement efficace contre de nombreuses attaques XSS, mais une configuration trop stricte ou mal adaptée peut casser des fonctionnalités de votre thème ou de vos plugins. Il est donc recommandé de :

  • commencer par un mode Content-Security-Policy-Report-Only pour analyser les violations sans bloquer immédiatement ;
  • tester sur un environnement de préproduction avant la mise en production ;
  • ajuster progressivement les sources autorisées en fonction des besoins réels du site.

2. Strict-Transport-Security (HSTS)

HTTP Strict Transport Security (HSTS) force le navigateur à utiliser uniquement HTTPS pour communiquer avec votre site, y compris lors des visites suivantes. L’objectif est d’éviter :

  • les attaques de type « downgrade » où l’attaquant tente de forcer une connexion en HTTP non chiffré ;
  • les interceptions de trafic (man-in-the-middle) sur des connexions non sécurisées.

Un en-tête HSTS typique ressemble à ceci :

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

Ce paramétrage indique au navigateur :

  • de se souvenir pendant un an (31536000 secondes) que le site doit être consulté uniquement en HTTPS ;
  • d’appliquer cette règle également aux sous-domaines ;
  • de pouvoir être inclus dans la liste de préchargement HSTS des navigateurs (option preload).

Attention : HSTS ne doit être activé que si votre site est déjà entièrement accessible en HTTPS (sans contenu mixte, sans sous-domaine restant en HTTP). Une mauvaise configuration peut rendre un site temporairement inaccessible en cas de problème de certificat.

3. X-Content-Type-Options

L’en-tête X-Content-Type-Options avec la valeur nosniff empêche le navigateur de tenter de « deviner » le type de contenu lorsque le serveur l’a mal indiqué. Ce comportement de détection automatique, appelé MIME sniffing, peut être exploité pour exécuter du code malveillant.

Un exemple de configuration simple :

X-Content-Type-Options: nosniff

Cet en-tête est léger, facile à mettre en place et recommandé pour la quasi-totalité des sites WordPress. Il complète efficacement d’autres mécanismes de protection contre les attaques XSS et les téléchargements de fichiers.

4. X-Frame-Options

X-Frame-Options protège contre le clickjacking en contrôlant si votre site peut être affiché dans une