Un en-tête de sécurité n’est pas un rempart en lui-même : c’est une instruction envoyée au navigateur pour qu’il applique lui-même des restrictions supplémentaires. Le serveur dialogue ainsi directement avec le navigateur du visiteur, en plus du contenu de la page.
Les en-têtes les plus utiles sur WordPress
Content-Security-Policy restreint les sources de scripts et de styles autorisées, ce qui limite l’impact d’une injection XSS via un commentaire ou un champ mal filtré. X-Frame-Options (ou son successeur frame-ancestors dans la CSP) empêche qu’une page d’administration soit chargée dans une iframe malveillante. Strict-Transport-Security force le navigateur à toujours utiliser HTTPS une fois le certificat TLS validé une première fois.
Ajout via Nginx
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;Ces directives se placent dans le bloc server de la configuration de l’hôte virtuel, ou peuvent être injectées depuis PHP avec header() si l’accès au serveur web n’est pas possible.
À ne pas confondre avec
- Une extension de sécurité WordPress (type pare-feu applicatif) filtre les requêtes entrantes ; les en-têtes agissent, eux, sur le comportement du navigateur en sortie.
- Ajouter des en-têtes ne remplace jamais la mise à jour du cœur, des thèmes et des extensions : ils réduisent la surface d’attaque mais ne corrigent aucune vulnérabilité existante.
- Une CSP trop stricte peut casser l’affichage de l’éditeur de blocs si elle bloque certains scripts inline nécessaires à WordPress ; un test en environnement de recette est recommandé.