Configuration des en-têtes de sécurité HTTP sur WordPress

La plupart des navigateurs modernes prennent en charge une variété d'en-têtes de sécurité HTTP pour améliorer la sécurité de votre site Web WordPress, mieux protéger vos visiteurs contre les classes d'attaques de navigateur telles que le détournement de clic, les scripts intersites et d'autres attaques courantes, et même améliorer la confidentialité des visiteurs de votre site. en ligne.

Cet article donne un aperçu de ce que sont ces en-têtes de sécurité HTTP, explique leur fonctionnement et leur portée. Il explique également comment vous pouvez ajouter ces en-têtes de sécurité HTTP à votre site Web pour améliorer la sécurité de votre site Web WordPress.

Qu'est-ce qu'un en-tête de sécurité HTTP ?

Les en-têtes de sécurité HTTP sont une série d'en-têtes HTTP ¹ échangés entre un client Web (navigateur) et un serveur Web qui sont utilisés pour spécifier les paramètres liés à la sécurité de la communication HTTP entre un client Web et un serveur. L'activation des en-têtes de sécurité sur votre site Web WordPress peut améliorer la résilience de votre site Web contre les attaques courantes, notamment les scripts intersites (XSS) et le détournement de clics.

Comment les en-têtes de sécurité HTTP peuvent améliorer la sécurité de WordPress

Les en-têtes de sécurité HTTP peuvent aider à améliorer la sécurité de votre site Web WordPress en demandant au navigateur d'activer une variété de fonctionnalités de sécurité en conséquence. Dans de nombreux cas, la mise en œuvre des bons en-têtes est une affaire délicate et peut même avoir des résultats différents (ou être totalement inefficace) dans les navigateurs plus anciens, il est donc préférable d'essayer toute modification dans un environnement de test ou de mise en scène avant d'appliquer toute modification sur un site WordPress en direct.

Les en-têtes de sécurité HTTP les plus couramment utilisés

Quels en-têtes font quoi ? Plongeons-nous dans un aperçu de certains des en-têtes de sécurité HTTP les plus importants et les plus couramment utilisés.

Strict-Transport-Sécurité

L'en-tête HTTP Strict-Transport-Security demande au navigateur d'appliquer HTTP Strict Transport Security (HSTS) ² . Un en-tête HSTS indique au navigateur visiteur de toujours accéder au site via HTTPS (au lieu de HTTP), même si l'utilisateur (ou un attaquant essayant de lancer une attaque Man-in-the-Middle) tente d'accéder au site via HTTP, le le navigateur basculera de force sur HTTPS, même si HTTP n'est pas disponible - dans une telle mesure, vous ne devez activer HSTS que si vous avez activé HTTPS et fonctionne correctement sans problèmes de contenu mixte ³ .

L'en-tête de réponse HTTP HTTP Strict Transport Security (HSTS) suivant active HSTS pour une durée d'un an (31536000 secondes).

Strict-Transport-Security: max-age=31536000

Politique de sécurité du contenu

L'en-tête de sécurité HTTP Content-Security-Policy est un en-tête HTTP avec beaucoup de puissance et de configurabilité. Il configure la politique de sécurité du contenu (CSP) du navigateur, qui est un ensemble de fonctionnalités de sécurité présentes dans les navigateurs modernes et qui fournit une couche de sécurité supplémentaire qui aide à détecter et à atténuer les attaques telles que les scripts intersites (XSS) et les attaques par injection de données.

La politique de sécurité du contenu (CSP) est également notoirement difficile à obtenir, car les bons paramètres CSP dépendront très largement du site Web en question et devraient être fortement testés avant le déploiement - à tel point qu'il a une soeur Content-Security-Policy -Rapport-Seulement ⁴ En-tête HTTP utilisé uniquement pour tester CSP.

Ce qui suit est un exemple d'une politique de sécurité du contenu (CSP) assez simple qui permet uniquement de charger des actifs à partir de l'origine à partir de laquelle le site Web est servi.

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

Cependant, la politique de sécurité du contenu (CSP) est beaucoup plus configurable que celle illustrée dans cet exemple simple. CSP inclut d'autres directives telles que script-src , style-src et img-src pour spécifier les sources à partir desquelles le navigateur peut charger des actifs (par exemple CSS, images et polices). Pour une liste complète de la façon dont CSP peut être configuré, consultez les directives de référence rapide de la politique de sécurité du contenu.

X-Content-Type-Options

L'en-tête de sécurité HTTP X-Content-Type-Options est un en-tête non standard respecté par tous les principaux navigateurs qui empêche les attaques de type Cross-site Scripting (XSS) causées par le reniflage de type MIME ⁵ . Lorsqu'il est présent, cet en-tête indique au navigateur de suivre strictement les types MIME définis dans l'en-tête HTTP Content-Type, et que le navigateur ne doit pas essayer de détecter le type MIME correct pour les données de réponse elles-mêmes. L'en-tête a une seule directive — nosniff.

X-Content-Type-Options: nosniff

En-têtes de sécurité HTTP anciens ou inutilisés

Il existe également un certain nombre d'en-têtes de sécurité HTTP anciens et inutilisés. Ils ne sont plus utilisés ou ne fonctionnent plus car ils ont été introduits en tant que correctifs temporaires, expérimentations ou même initiatives non standard qui ont depuis été obsolètes ou entièrement remplacées. Vous trouverez ci-dessous une liste de ces en-têtes de sécurité HTTP.

En-têtes de sécurité HTTP remplacés par Content-Security-Policy

X-Frame-Options

L'en-tête de sécurité HTTP X-Frame-Options est un en-tête désormais obsolète qui a été introduit pour la première fois par Microsoft Internet Explorer (et adopté par d'autres navigateurs avec divers degrés d'uniformité et de compatibilité) pour protéger les navigateurs contre les scripts intersites (XSS), le détournement de clics et d'autres attaques qui reposent sur un site Web placé à l'intérieur d'un iframe.

Cet en-tête a maintenant été remplacé par la directive frame-ancestors Content Security Policy (CSP). Il est conseillé d'utiliser CSP avec la directive frame-ancestors à la place de X-Frame-Options.

X-XSS-Protection

L'en-tête de sécurité HTTP X-XSS-Protection était un en-tête non standard introduit pour activer ou désactiver les protections du navigateur contre les attaques de type Cross-site Scripting (XSS). En pratique, cet en-tête était souvent facile à contourner pour les attaquants et, par conséquent, il est ignoré par la plupart des navigateurs modernes.

Public-Key-Pins

L'en-tête de sécurité HTTP Public-Key-Pins utilisé pour configurer la fonctionnalité de sécurité Public Key Pinning (HPKP) qui a été introduite dans Google Chrome et Firefox pour empêcher l'usurpation de certificat TLS. HPKP a fonctionné en demandant au serveur Web de fournir au navigateur un ensemble de hachages cryptographiques des clés publiques de certificat TLS utilisées par le site Web, que le navigateur utiliserait à son tour pour comparer avec les certificats qu'il reçoit du serveur lors de requêtes ultérieures. Le problème était que HPKP était assez compliqué à gérer et entraînait fréquemment des erreurs de configuration qui pouvaient complètement désactiver l'accès au site Web - en tant que tel, il n'est plus recommandé de l'utiliser.

Ajout d'en-têtes de sécurité HTTP dans WordPress

Les en-têtes de sécurité HTTP fonctionnent mieux lorsqu'ils sont configurés sur votre serveur Web ou, le cas échéant, votre réseau de diffusion de contenu (CDN) ou votre pare-feu d'application Web. Cela permet de les envoyer à chaque demande. Alternativement, bien que moins idéal, vous pouvez utiliser un plugin WordPress pour définir ces en-têtes pour vous.

Maintenant que nous avons couvert l'objectif des en-têtes de sécurité HTTP, voici quelques façons de les activer sur votre site Web WordPress.

Ajout d'en-têtes de sécurité HTTP dans WordPress à l'aide d'Apache HTTP Server

Voici un exemple de configuration pour Apache HTTP Server requise pour activer HTTP Strict Transport Security (HSTS), X-Content-Type-Options et une simple politique de sécurité du contenu.

<ifModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000"
Header set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "default-src 'self'"
</ifModule>

Ajout d'en-têtes de sécurité HTTP dans WordPress à l'aide de Nginx

De même, voici un exemple de la configuration pour Nginx requise pour activer HTTP Strict Transport Security (HSTS), X-Content-Type-Options et une simple politique de sécurité du contenu.

server {
add_header Strict-Transport-Security "max-age=31536000; always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
}

Ajout d'en-têtes de sécurité HTTP dans WordPress à l'aide d'un plugin

Alternativement, bien que moins efficace (puisqu'il s'appuie sur WordPress lui-même pour modifier les en-têtes), l'utilisation d'un plugin WordPress peut être le moyen le plus simple d'ajouter des en-têtes de sécurité HTTP à votre site Web WordPress. Des plugins tels que le plugin Redirection vous permettent d'ajouter des en-têtes HTTP personnalisés à votre site Web.

Comment vérifier les en-têtes de sécurité HTTP pour un site Web

Une fois que vous avez ajouté des en-têtes de sécurité HTTP sur votre site Web WordPress, vous devez vous assurer qu'ils sont correctement configurés et fonctionnent comme prévu. Le moyen le plus simple de tester cela consiste à utiliser un outil gratuit appelé Security Headers ⁶ .

L'utilisation de l'outil Security Headers est aussi simple que d'entrer l'URL de votre site Web et d'appuyer sur "Scan". Vous recevrez ensuite une note de A+ à F ainsi qu'une explication de la façon dont cette note a été déterminée.