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

Les en-têtes de sécurité sont des en-têtes de réponse HTTP qui indiquent aux navigateurs d'activer des fonctionnalités de sécurité intégrées. La plupart des sites WordPress n'ont pas plusieurs de ces en-têtes par défaut, car ni le coeur de WordPress ni la plupart des hébergeurs ne les configurent automatiquement. La bonne nouvelle est que les ajouter ne prend que quelques minutes, et l'amélioration de la sécurité est significative. Ce guide couvre chaque en-tête de sécurité important, explique ce que fait chacun, et vous montre comment les ajouter tous en une seule fois.

Quels en-têtes de sécurité chaque site WordPress devrait-il avoir ?

Voici la liste complète des en-têtes de sécurité recommandés avec leurs valeurs et ce contre quoi ils protègent :

• X-Frame-Options: SAMEORIGIN : empêche votre site d'être chargé dans une iframe sur un autre domaine. Cela arrête les attaques de clickjacking où un site malveillant superpose des boutons invisibles sur votre page.
• X-Content-Type-Options: nosniff : empêche les navigateurs de deviner le type MIME d'un fichier. Sans cela, un attaquant pourrait téléverser un fichier qui ressemble à une image mais contient du JavaScript, et le navigateur pourrait l'exécuter.
• Referrer-Policy: strict-origin-when-cross-origin : contrôle la quantité d'informations d'URL partagées lorsque les utilisateurs cliquent sur des liens vers d'autres sites. Ce paramètre envoie l'URL complète pour les requêtes de même origine mais seulement le domaine pour celles d'origine croisée, protégeant les paramètres d'URL sensibles.
• Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() : désactive les fonctionnalités du navigateur que votre site n'utilise pas. Les parenthèses vides signifient "personne n'est autorisé à utiliser cette fonctionnalité", ce qui empêche les scripts malveillants d'accéder à la caméra, au microphone ou à la localisation.
• Strict-Transport-Security: max-age=31536000; includeSubDomains : force les navigateurs à toujours utiliser HTTPS. Voir notre guide HSTS dédié pour les détails sur un déploiement sûr.
• X-XSS-Protection: 1; mode=block : un en-tête hérité pour les anciens navigateurs qui active le filtre XSS intégré. Les navigateurs modernes l'ont déprécié au profit de la CSP, mais cela ne fait pas de mal de l'inclure pour la rétrocompatibilité.
• Content-Security-Policy : l'en-tête de sécurité le plus puissant (et complexe). Voir notre guide CSP dédié pour une explication complète.

Comment prioriser : quels en-têtes ajouter en premier

Si vous ajoutez des en-têtes de sécurité pour la première fois, voici l'ordre qui vous donne la plus grande amélioration de sécurité avec le moins de risques :

1. X-Content-Type-Options : aucun risque de casser quoi que ce soit. Ajoutez-le simplement.
2. X-Frame-Options : sûr sauf si vous intégrez intentionnellement votre site dans des iframes sur d'autres domaines (peu probable pour la plupart des sites WordPress).
3. Referrer-Policy : risque très faible. La valeur recommandée strict-origin-when-cross-origin est déjà le comportement par défaut dans les navigateurs modernes.
4. Permissions-Policy : faible risque sauf si votre site utilise réellement les API de caméra, microphone ou géolocalisation.
5. X-XSS-Protection : en-tête hérité, aucun risque.
6. Strict-Transport-Security : nécessite d'abord un HTTPS fonctionnel. Suivez un déploiement progressif (voir notre guide HSTS).
7. Content-Security-Policy : risque le plus élevé de casser des choses sur WordPress. Commencez toujours en mode Report-Only (voir notre guide CSP).

Ajout de tous les en-têtes via Apache .htaccess

C'est la méthode la plus courante pour les sites WordPress sur hébergement mutualisé. Ouvrez le fichier .htaccess dans le répertoire racine de WordPress et ajoutez le bloc suivant. Placez-le avant la section # BEGIN WordPress pour garder les choses organisées :

<IfModule mod_headers.c>
    # Empêcher le clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"

    # Empêcher le MIME-type sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Contrôler les informations de référence
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Restreindre les fonctionnalités du navigateur
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

    # Forcer HTTPS (à ajouter uniquement si SSL fonctionne complètement)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # Protection XSS pour les navigateurs hérités
    Header always set X-XSS-Protection "1; mode=block"
</IfModule>

Quelques points à garder à l'esprit :

• L'enveloppe IfModule garantit qu'Apache ne génère pas d'erreur 500 si mod_headers n'est pas activé sur votre serveur.
• L'utilisation de Header always set (au lieu de simplement Header set) garantit que les en-têtes sont envoyés sur toutes les réponses, y compris les pages d'erreur.
• Si vous avez déjà un bloc <IfModule mod_headers.c> dans votre .htaccess, ajoutez les lignes Header individuelles à l'intérieur de ce bloc existant au lieu de créer un doublon.

Ajout de tous les en-têtes via Nginx

Si votre site WordPress fonctionne sur Nginx (courant avec les hébergeurs WordPress managés comme Kinsta, Cloudways, GridPane ou SpinupWP), ajoutez ces lignes à l'intérieur de votre bloc server :

# En-têtes de sécurité
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-XSS-Protection "1; mode=block" always;

Notes importantes spécifiques à Nginx :

• Le mot-clé always envoie l'en-tête sur tous les codes de réponse (y compris 4xx et 5xx). Sans lui, Nginx n'envoie les en-têtes que sur les réponses 2xx.
• Si vous avez un bloc location séparé qui gère PHP (par exemple, location ~ .php$), vous devrez peut-être y ajouter aussi les en-têtes, selon votre configuration Nginx. Nginx n'hérite pas des directives add_header des blocs parents si le bloc enfant a son propre add_header.
• Après avoir effectué des changements, testez et rechargez toujours : sudo nginx -t && sudo systemctl reload nginx.

Ajout des en-têtes via PHP dans WordPress

Si vous ne pouvez pas accéder aux fichiers de configuration du serveur, vous pouvez envoyer les en-têtes de sécurité depuis PHP. Ajoutez ceci au functions.php de votre thème ou à une extension personnalisée spécifique au site :

function iwp_add_security_headers() {
    if ( is_admin() ) {
        return;
    }

    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()' );
    header( 'X-XSS-Protection: 1; mode=block' );
}
add_action( 'send_headers', 'iwp_add_security_headers' );

La vérification is_admin() ignore la zone d'administration WordPress pour éviter les conflits potentiels avec les fonctionnalités d'administration. Notez que cette approche PHP a une limitation : elle ne s'applique qu'aux pages traitées par WordPress. Les fichiers statiques (images, CSS, JS, polices) servis directement par votre serveur web ne porteront pas ces en-têtes. Pour une couverture complète, la configuration au niveau du serveur est toujours le meilleur choix.

Extensions WordPress pour les en-têtes de sécurité

Si vous préférez une approche basée sur des extensions, ces options offrent une interface conviviale pour gérer les en-têtes de sécurité :

• HTTP Headers : une extension gratuite avec une interface complète pour configurer tous les en-têtes de sécurité. Elle prend en charge X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy et plus encore. Vous configurez tout depuis l'admin WordPress sans toucher à aucun fichier.
• Really Simple SSL Pro : la version premium inclut un module d'en-têtes de sécurité qui vous permet d'activer ou désactiver des en-têtes individuels. Elle fournit aussi des recommandations et explique chaque en-tête.
• Headers Security Advanced & HSTS WP : une extension axée spécifiquement sur les en-têtes de sécurité. Elle couvre tous les en-têtes majeurs et inclut des préréglages pour les configurations courantes.
• Security Headers de Jeremykendall : une option légère qui ajoute tous les en-têtes recommandés avec des valeurs par défaut sensées.

Bien que les extensions soient pratiques, elles ont des compromis. Si l'extension est désactivée, mise à jour avec un bug ou supprimée, vos en-têtes de sécurité disparaissent instantanément. Pour les sites en production, la configuration au niveau du serveur est plus fiable car elle ne dépend pas de WordPress ou d'une extension active.

Tester vos en-têtes avec des outils en ligne

Après avoir ajouté vos en-têtes, vérifiez-les avec ces outils gratuits :

• securityheaders.com : entrez votre URL et obtenez une note de A+ à F avec une analyse détaillée des en-têtes présents et manquants. Visez au moins une note A.
• observatory.mozilla.org : l'outil de Mozilla effectue une analyse plus complète, y compris l'évaluation de la CSP et la sécurité des cookies.
• DevTools du navigateur : appuyez sur F12, allez dans l'onglet Network, cliquez sur la requête du document principal et faites défiler jusqu'à Response Headers pour voir exactement ce que votre serveur envoie.

Vous pouvez aussi vérifier depuis la ligne de commande :

curl -sI https://example.com

Cela affiche tous les en-têtes de réponse, y compris vos en-têtes de sécurité nouvellement ajoutés.

Considérations CDN et reverse proxy

Si votre site WordPress est derrière un CDN comme Cloudflare, Sucuri ou Fastly, sachez que le CDN peut supprimer, écraser ou ajouter ses propres en-têtes. Voici ce que vous devez savoir :

• Cloudflare : ne supprime pas les en-têtes de sécurité par défaut, donc les en-têtes définis sur votre serveur d'origine passeront. Cloudflare offre aussi ses propres paramètres d'en-têtes de sécurité dans le tableau de bord sous SSL/TLS > Edge Certificates (pour HSTS) et dans les règles managées.
• Sucuri : leur pare-feu peut ajouter automatiquement certains en-têtes de sécurité. Vérifiez les paramètres de votre tableau de bord Sucuri pour voir lesquels sont actifs et éviter les doublons.
• Fastly / KeyCDN / BunnyCDN : la plupart des CDN vous permettent d'ajouter des en-têtes de réponse personnalisés dans leur panneau de configuration. Cela peut être une bonne alternative si vous ne pouvez pas modifier la configuration serveur sur votre origine.

Si vous voyez des en-têtes en double dans votre réponse (par exemple, deux lignes X-Frame-Options), cela peut provoquer un comportement imprévisible du navigateur. Assurez-vous que chaque en-tête n'est défini qu'à un seul endroit : soit sur votre serveur d'origine, soit au niveau du CDN, mais pas les deux.

Erreurs courantes lors de l'ajout d'en-têtes de sécurité

• Blocs IfModule en double : si votre .htaccess a déjà un bloc <IfModule mod_headers.c> (peut-être d'une extension), en ajouter un deuxième peut causer des conflits. Fusionnez vos en-têtes dans le bloc existant.
• Définir les en-têtes uniquement via PHP : cela manque tous les fichiers statiques. Utilisez la configuration au niveau du serveur pour une couverture complète.
• Écraser les en-têtes dans des blocs location (Nginx) : si un bloc location enfant a un add_header quelconque, il remplace tous les en-têtes du bloc parent. Vous devez répéter tous les en-têtes dans chaque bloc location qui définit le sien.
• Ne pas tester après les mises à jour d'extensions : une mise à jour d'extension ou un changement de thème peut supprimer vos en-têtes basés sur PHP. Retestez toujours après des changements majeurs.
• Oublier les sous-domaines : si vous avez des sous-domaines (staging, mail, etc.), assurez-vous qu'ils ont aussi des en-têtes de sécurité configurés. Les attaquants ciblent souvent le sous-domaine le plus faible.

Vérifiez vos en-têtes de sécurité avec InspectWP

Après avoir ajouté tous les en-têtes, lancez un nouveau scan InspectWP sur votre site WordPress. La section sécurité de votre rapport liste chaque en-tête de sécurité et affiche son statut. Chaque en-tête présent et correctement configuré apparaîtra en vert. Les en-têtes manquants apparaissent en rouge ou jaune, selon leur importance. Utilisez la fonctionnalité de rapport automatique d'InspectWP pour surveiller vos en-têtes au fil du temps et détecter toute régression causée par des changements de serveur ou des mises à jour d'extensions.