Comment ajouter des en-têtes de sécurité HTTP dans WordPress

Publié: 2023-05-18

WordPress est le système de gestion de contenu (CMS) le plus populaire au monde, exécutant plus de 43 % de tous les sites Web sur Internet.Cependant, son utilisation généralisée en fait une cible commune pour les pirates.

Les attaques par force brute, les vulnérabilités de téléchargement de fichiers et les attaques de script intersite contribuent toutes à la menace actuelle.

Heureusement, il existe plusieurs façons de rendre votre site Web plus sûr et moins sujet aux attaques. Et c'est là que les en-têtes HTTP entrent en scène.

En implémentant les en-têtes de sécurité HTTP, vous pouvez limiter les actions que les navigateurs et les serveurs peuvent effectuer sur votre site Web et ajouter une couche de sécurité supplémentaire. Ces en-têtes rendent beaucoup plus difficile pour les attaquants d'exploiter les vulnérabilités côté client.

Dans cet article, nous discuterons de ce que sont les en-têtes de sécurité HTTP et de la manière dont vous pouvez les implémenter efficacement sur votre site Web.

Que sont exactement les en-têtes de sécurité HTTP ?

Les en-têtes de sécurité HTTP sont un groupe de directives utilisées par les applications Web pour implémenter des défenses de sécurité dans les navigateurs Web. Ces en-têtes sont échangés entre le navigateur Web (le client) et le serveur pour identifier les paramètres de sécurité de la communication HTTP. Cet échange d'informations indique au navigateur comment se comporter tout au long de ses interactions avec votre site et régit des processus tels que l'affichage des erreurs et la gestion du cache.

Bien entendu, cette sécurité et cette efficacité supplémentaires dépendent largement du navigateur. Les navigateurs Web plus anciens n'auront pas le même niveau de sécurité ou de compatibilité et peuvent ne pas traiter correctement, entièrement ou même pas du tout les en-têtes de sécurité HTTP. Cela peut potentiellement signifier que, malgré tous vos efforts pour aider le visiteur à rester en sécurité, son navigateur obsolète le rend toujours vulnérable. En tant que développeurs de sites Web, nous devons faire tout notre possible, mais accepter que, du côté du visiteur, il est de sa responsabilité de s'assurer qu'il utilise un logiciel à jour sur son ordinateur. Tant qu'ils utilisent un navigateur Web moderne et à jour, notre utilisation des en-têtes de sécurité HTTP fonctionnera avec leur logiciel de navigation pour assurer leur sécurité.

Notre principale préoccupation, cependant, est que les en-têtes de sécurité HTTP empêchent votre site Web des attaques courantes telles que les scripts intersites et les attaques par force brute.Les moyens les plus efficaces d'implémenter ces en-têtes sont de les définir sur votre compte d'hébergement WordPress (niveau serveur) et d'utiliser un pare-feu d'application de site Web de niveau DNS tel que Cloudflare.

Mais vous devez vous rappeler que si l'ajout d'en-têtes de sécurité HTTP peut aider à améliorer la sécurité de votre site, ce n'est qu'un aspect de la sécurité du site Web et doit être utilisé conjointement avec d'autres mesures de sécurité. Cela inclut la mise à jour de vos applications et plugins, le cryptage de vos données sensibles et la sauvegarde des données du site et des fichiers de configuration.

Avant de discuter des différentes méthodes pour ajouter des en-têtes de sécurité, examinons chaque en-tête en détail et comprenons pourquoi il est important.Si vous connaissez déjà les en-têtes de sécurité, vous pouvez passer à la section ci-dessous.

Les types d'en-têtes de sécurité HTTP WordPress

Il existe plusieurs en-têtes de sécurité HTTP qui peuvent être utilisés avec votre site Web WordPress pour améliorer la protection. Jetons un coup d'œil à certains des plus importants.

1. En-tête de sécurité X-XSS Protection

Cet en-tête de sécurité est utilisé pour configurer le cross-site scripting (XSS), une vulnérabilité de sécurité qui permet à des tiers non authentifiés d' exécuter du code pour le compte d'un autre site Web dans le navigateur.

Il empêche de nombreuses attaques XSS sur votre site Web en empêchant le site de s'afficher si une attaque est détectée. X-XSS utilise l'option plus sûre de ne pas charger complètement le site plutôt que d'essayer de désinfecter la page en remplaçant les éléments potentiellement dangereux.

L'en-tête peut avoir l'une de ces valeurs :

  • X-XSS-Protection : 0 Désactive le filtrage XSS (non recommandé)
  • X-XSS-Protection : 1 Active le filtrage XSS, qui est généralement la valeur par défaut dans la plupart des navigateurs. Si une attaque XSS est détectée, le navigateur supprimera les parties dangereuses de la page (nettoyage).
  • Protection X-XSS : 1 ; mode=block Active le filtrage XSS, mais plutôt que de nettoyer la page, le navigateur empêchera le rendu de la page (recommandé)
  • Protection X-XSS : 1 ; report=<reporting-uri> Active le filtrage XSS. Le navigateur nettoiera la page et signalera la violation si une attaque de script intersite est détectée.

2. En-tête de sécurité des options X-Frame

L'en-tête de sécurité X-Frame-Options peut être utilisé pour empêcher différentes attaques par force brute et attaques DDOS , mais son utilisation la plus efficace est contre le détournement d'iframes et le détournement de clics sur votre site Web WordPress.Cet en-tête vous permet de décider si une page de votre site Web peut ou non être intégrée à l'aide d'éléments iframe dans le navigateur.

L'option X-Frame protège votre site Web contre le vol de clics en empêchant les iframes de se remplir avec votre site. Il a deux directives différentes parmi lesquelles vous pouvez choisir -DENY et SAMEORIGIN. Il fonctionne avec tous les navigateurs Web populaires, tels que Chrome, Safari, Firefox et Opera.

 Options X-Frame : DENY
 Options X-Frame : SAMEORIGINE

Lorsqu'il est spécifié avec DENY, l'en-tête X-Frame-Options provoquera un échec si un navigateur tente de charger la page dans un cadre lorsqu'il est chargé à partir d'autres sites. Les tentatives de le faire échoueront également lorsqu'elles seront chargées dans un iframe à partir du site d'origine. D'autre part, si nous spécifions SAMEORIGIN , nous pouvons toujours utiliser la page dans un cadre - tant que le site qui l'inclut dans un cadre est le même que celui qui dessert la page.

Cet en-tête est particulièrement important pour les pages Web contenant des informations sensibles et les pages qui intègrent des informations telles que les passerelles de paiement et les formulaires.

3. En-tête HTTP Strict Transport Security (HSTS)

Le HTTP Strict-Transport-Security est un en-tête de réponse de sécurité envoyé d'un serveur Web au navigateur Web d'un utilisateur pour l'informer que le site ne doit être accessible qu'en utilisant HTTP et jamais via HTTP non chiffré.

Cet en-tête fournit un mécanisme pour imposer l'utilisation de HTTPS par le navigateur , même si l'utilisateur tape « http:// » dans la barre d'adresse ou suit un lien HTTP.Cela peut également empêcher les utilisateurs d'ignorer les certificats SSL/TLS expirés ou invalides et d'autres avertissements du navigateur. La valeur HSTS est définie par navigateur qui visite le site Web. Il n'est pas défini par machine.

L'en-tête HSTS fournit une option pour inclure tous les sous-domaines - vous pouvez utiliser la directive "includeSubDomains" pour adopter le même niveau de sécurité à partir du domaine racine. Cela signifie que tout développement local avec le domaine (ou les sous-domaines) ne sera plus accessible via HTTP puisque le navigateur n'autorisera que le trafic HTTPS.

Par exemple, si vous avez des en-têtes HSTS sur example.com avec la directive « includeSubdomains » nécessaire, vous ne pourrez pas accéder aux sous-domaines de example.com via des connexions non sécurisées une fois que vous aurez visité example.com. Par conséquent, soyez prudent si vous choisissez d'utiliser "includeSubdomains" , cela pourrait avoir des implications pour vos autres domaines.

Une fois qu'un navigateur reçoit un en-tête HSTS d'un site, il se souviendra de la politique HSTS pendant la durée spécifiée et mettra automatiquement à niveau toutes les futures requêtes vers le site vers HTTPS. Cela permet d'éviter les attaques de l'homme du milieu, les écoutes clandestines et d'autres formes de falsification en garantissant que toutes les communications entre le navigateur et le serveur sont cryptées.

La syntaxe de cet en-tête est :

 # Sans directive includeSubDomains
<IfModule mod_headers.c>
Jeu d'en-tête Strict-Transport-Security : "max-age=63072000 ;"
</IfModule>
# Avec la directive includeSubDomains
<IfModule mod_headers.c>
Jeu d'en-tête Strict-Transport-Security "max-age=31536000 ; includeSubDomains ; préchargement" 
</IfModule>

La directive max-age=<expire-time> désigne le temps (en secondes) pendant lequel le navigateur doit se souvenir qu'un site ne peut être accédé qu'en utilisant HTTPS. Par exemple, dans l'exemple ci-dessus, l' âge maximum est fixé à deux ans. Si vous avez choisi d'avoir Servebolt CDN ou Accelerated Domains de Servbolt, vous aurez automatiquement 1 an de durée HSTS.

4. En-tête de politique de référence

Cet en-tête HTTP contrôle la quantité d'informations de référent envoyées via l'en-tête de référent qui doivent être incluses dans les requêtes. Il limite la quantité d'informations envoyées lorsqu'un visiteur du site clique sur un lien. Cela permet d'éviter la fuite d'informations sensibles vers d'autres sites Web , telles que l'URL d'une page contenant des informations privées.

Il peut avoir plusieurs valeurs - voici un bref aperçu :

  • no-referrer : l'en-tête Referer ne sera jamais envoyé, quelles que soient les circonstances.
  • No-referrer-when-downgrade : l'en-tête Referer ne sera pas envoyé lors de la navigation d'un site HTTPS vers un site HTTP.
  • Origine : l'en-tête Referer n'inclura que l'origine (schéma, hôte et port) de la page de référence.
  • Origin-when-cross-origin : l'en-tête Referer inclura l'URL complète de la page de référence lors de la navigation entre les pages de la même origine et uniquement l'origine lors de la navigation vers une origine différente.
  • Strict-origin : l'en-tête Referer n'inclura que l'origine de la page de référence et ne sera pas envoyé pour les demandes d'origine croisée.
  • Strict-origin-when-cross-origin : l'en-tête Referer inclura l'origine de la page de référence et ne sera pas envoyé pour les demandes d'origine croisée, sauf pour les origines du même site. Nous vous recommandons d'utiliser ce paramètre car il conserve l'utilité de l'en-tête tout en atténuant le risque de fuite de données.
  • Unsafe-url : l'en-tête Referer enverra l'origine, le chemin et la chaîne de requête lors de l'exécution de toute requête, quelle que soit la sécurité.

Pour une discussion approfondie sur l'en-tête de la politique de référence, lisez l'article de Google web.dev sur les meilleures pratiques pour la politique de référence .

5. En-tête X-Content-Type-Options

L'en-tête X-Content-Type-Options est envoyé par le serveur dans une réponse HTTP pour indiquer aux navigateurs les types MIME. Le but de cet en-tête est d' empêcher les navigateurs d'interpréter les fichiers comme un type MIME différent de celui spécifié dans l'en-tête.

Cet en-tête peut avoir une valeur unique de "nosniff". La syntaxe est la suivante :

 X-Content-Type-Options : nosniff

Il est très efficace contre les attaques de confusion MIME - l'utilisation de cet en-tête de sécurité peut empêcher le navigateur d'interpréter les fichiers de manière inattendue, ce qui pourrait entraîner des vulnérabilités de sécurité. Par exemple, si un attaquant télécharge un fichier avec une extension .jpg mais qui ne contient aucun contenu car il s'agit en fait d'un script, la définition de l'en-tête X-Content-Type-Options sur "nosniff" ne permettra pas au navigateur d'exécuter le script, protégeant ainsi les utilisateurs des violations potentielles.

6. En-tête de la politique de sécurité du contenu(CSP)

Content-Security-Policy est un en-tête de sécurité utilisé pour spécifier l'origine du contenu et fournit un mécanisme pour le contenu qui est autorisé à être chargé et exécuté dans un site Web ou une application Web. En spécifiant un ensemble de stratégies, cet en-tête peut restreindre les types de contenu autorisés sur une page Web et atténuer divers types de menaces de sécurité. Il s'agit d'une couche de sécurité supplémentaire contre les attaques de script intersite (XSS) et d'injection de données qui sont utilisées pour des crimes tels que le vol de données, la dégradation de sites et la distribution de logiciels malveillants.

En plus de contrôler les types de ressources qui peuvent être chargées, l'en-tête Content-Security-Policy fournit également un moyen d'indiquer au navigateur comment il doit gérer toute violation des politiques spécifiées dans l'en-tête. Par exemple, une politique peut spécifier que si une ressource enfreint la politique, le navigateur doit publier un avertissement ou empêcher le chargement de la ressource.

Le serveur doit être configuré pour renvoyer l'en-tête Content-Security-Policy pour que les stratégies fonctionnent. Vous pouvez utiliser l'en-tête HTTP CSP pour spécifier votre stratégie comme ceci :

 Content-Security-Policy : politique

Cette politique est une chaîne contenant les directives de politique décrivant votre politique de sécurité du contenu. Par exemple, vous pouvez ajouter les lignes suivantes à votre fichier .htaccess pour implémenter CSP.

 <IfModule mod_headers.c>
Jeu d'en-têtes Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com themes.googleusercontent.com ; connect-src https : wss : 'self' ; img-src https : données : 'self' http : *.gravatar.com ; worker-src blob : https : 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
</IfModule>

Si vous appliquez CSP sur un site Web WordPress, vous devez noter que « unsafe-inline » et « unsafe-eval » sont nécessaires à WordPress pour fonctionner correctement. La configuration ci-dessus est un bon point de départ pour la plupart des sites Web WordPress. Cependant, il existe des risques associés à l'utilisation de la configuration ci-dessus sans une compréhension claire de la signification de chaque section. Voici une ventilation de chaque directive :

  • default-src – Cette directive définit la stratégie par défaut pour tous les types de ressources, sauf si elles sont remplacées par d'autres directives.Dans ce cas, il permet de charger des ressources à partir de la même origine ("self"), ainsi qu'à partir de sources HTTPS et de scripts utilisant "unsafe-eval" ou "unsafe-inline".
  • object-src – Cette directive limite les types d'objets pouvant être intégrés dans une page, tels que les applets Flash ou Java.Ici, il permet aux objets d'être chargés uniquement à partir de la même origine ("self").
  • font-src – Cette directive limite les sources à partir desquelles les polices peuvent être chargées.Ici, il permet de charger des polices à partir de sources HTTPS, du schéma d'URI de données et de la même origine ("self") ou à partir de sources HTTP de Google Fonts et de Google User Content.
  • connect-src – Cette directive limite les sources pouvant être utilisées pour les requêtes réseau, telles que les requêtes AJAX ou WebSockets.Ici, il permet d'établir des connexions uniquement via HTTPS ou WebSockets et à partir de la même origine ("self").
  • img-src – Cette directive limite les sources à partir desquelles les images peuvent être chargées.Ici, il permet de charger des images à partir de sources HTTPS, du schéma d'URI de données et de la même origine ("self") ou de sources HTTP de Gravatar.
  • worker-src – Cette directive limite les sources à partir desquelles les web workers peuvent être chargés.Ici, il permet aux travailleurs d'être chargés uniquement à partir du schéma d'URI blob, des sources HTTPS et des scripts qui utilisent 'unsafe-eval' ou 'unsafe-inline'.
  • media-src – Cette directive limite les sources à partir desquelles les ressources multimédias peuvent être chargées, telles que l'audio ou la vidéo.Ici, il permet aux médias d'être chargés uniquement à partir de sources HTTPS, du schéma d'URI blob et de la même origine ("self").
  • style-src – Cette directive limite les sources à partir desquelles les feuilles de style peuvent être chargées.Ici, il permet de charger des styles à partir de sources HTTPS et de scripts utilisant 'unsafe-eval' ou 'unsafe-inline', ainsi qu'à partir de la même origine ("self") et à partir de sources HTTP de Google Fonts.

Lorsque vous utilisez l'en-tête CSP avec votre instance WordPress, il est important de noter qu'unemauvaise application des en-têtes CSP cassera le tableau de bord d'administration WordPress car certains plugins et services peuvent s'appuyer sur du JavaScript tiers.

Pour résoudre ce problème, vous devrez ajouter manuellement chaque règle de sécurité à votre fichier d'en-têtes. Une autre méthode, mais moins sécurisée, consiste à désactiver l'en-tête CSP dans votre tableau de bord d'administration. Par exemple, voici ce que nous faisons sur servebolt.com :

 Jeu d'en-tête X-Frame-Options SAMEORIGIN
Ensemble d'en-tête Referrer-Policy strict-origin-when-cross-origin
Jeu d'en-tête X-XSS-Protection "1 ; mode=block"
<Si "%{REQUEST_URI} !~ /wp-admin/">
# n'ajoute que l'en-tête si ce n'est pas l'écran d'administration
L'en-tête est toujours défini Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.com servebolt.containers .piwik.pro *.intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.net servebolt.piwik.pro ; media-src 'self' *.intercomcdn.com données : ; img -src 'self' 'unsafe-inline' *.intercom.io *.intercomcdn.com *.intercomassets.com data: raskesider.raskesider.no *.servebolt.com secure.gravatar.com servebolt.piwik.pro ; connect- src 'self' ws : nexus-websocket-a.intercom.io *.piwik.pro servebolt.piwik.pro *.intercom.io ; font-src 'self' *.intercomcdn.com data : ; frame-src 'self ' app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; frame-ancestors 'self' *.servebolt. com;manifest-src 'soi' ;"
</Si>

Lors de l'application de CSP sur votre site, vous devez noter que cela peut endommager votre environnement de développement si vous n'utilisez pas HTTPS. Si vous ne savez pas comment générer une politique pour votre site, vous devez utiliser un outil graphique tel que ValidBot – CSP Wizard ou Report URI : CSP generator .

7. En-tête de politique d'autorisations

La politique d'autorisations fournit des mécanismes permettant aux développeurs de déclarer explicitement quelles fonctionnalités peuvent et ne peuvent pas être implémentées sur un site Web .Il gère l'ensemble des autorisations requises par le site Web. Cet en-tête est utilisé pour restreindre les capacités d'un site Web afin d'éviter certains risques de sécurité et de confidentialité, tels que l'abus des API Javascript, le suivi des utilisateurs et l'exécution de code infecté.

La politique d'autorisations permet à un serveur de définir si une fonctionnalité peut être utilisée dans un document particulier. Il utilisedes listes d'autorisation - une liste d'origines qui prend des valeurs prédéfinies spécifiques.La valeur de l'en-tête Permission-Policy se compose d'une liste de noms de directives séparés par des virgules et de leurs valeurs décrivant les différentes autorisations requises par un site Web.

La syntaxe générale de l'en-tête Permissions-Policy est :

 Permissions-Policy : <directive>=<allowlist>

Par exemple, si nous devons bloquer tout accès à la géolocalisation, nous procéderions comme suit :

 Permissions-Policy : geolocation=()

Ici, le symbole () signifie une liste blanche vide. Pour autoriser l'accès à un sous-ensemble d'origines, nous procéderions comme suit :

 <IfModule mod_headers.c>
L'en-tête définit toujours Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), gyroscope=(), magnétomètre=(), camera=(), microphone=(), fullscreen=(self)"
</IfModule>

Prenons un autre exemple. La valeur d'en-tête suivante limite un site Web à exécuter des scripts uniquement s'ils sont diffusés à partir de la même origine que le document principal :

 Permissions-Policy : script-src 'self'

L'en-tête Permissions-Policy peut être utilisé pour remplacer ou compléter l'en-tête Content-Security-Policy traditionnel, qui fournit des fonctionnalités similaires mais avec une syntaxe différente et moins de couverture en termes d'autorisations.Cet en-tête est actuellement une technologie expérimentale qui n'est prise en charge que par Google Chrome et d'autres navigateurs basés sur Chromium.Il fournit un mécanisme plus puissant et flexible pour contrôler les autorisations, et son adoption devrait se développer à l'avenir. Si vous voulez l'essayer par vous-même, vous pouvez utiliser le générateur d'en-tête de politique d'autorisation pour générer facilement des politiques d'autorisation.

Ajout d'en-têtes de sécurité HTTP à l'aide du fichier .htaccess

Nous vous recommandons d'ajouter des en-têtes de sécurité HTTP en modifiant directement le fichier .htaccess. Il s'agit d'un fichier de configuration de serveur le plus couramment utilisé par les serveurs Web Apache. En modifiant ce fichier, vous vous assurez que les en-têtes de sécurité HTTP dans WordPress sont configurés au niveau du serveur.

Vous aurez besoin d'accéder au fichier.htaccessde votre site Web pour utiliser cette méthode. Il est accessible sur les serveurs Apache à l'aide d'un client FTP.Avant d'apporter des modifications, il est fortement recommandé de faire une sauvegarde de votre fichier .htaccessactuel.

Tout d'abord, connectez-vous simplement à votre site à l'aide d'un client FTP ou de l'outil de gestion de fichiers de votre panneau de contrôle d'hébergement. Dans le dossier racine de votre site Web, localisez le fichier.htaccesset cliquez avec le bouton droit sur l'option "Modifier". Cela ouvrira le fichier avec un éditeur de texte. Pour ajouter des en-têtes de sécurité HTTPS à votre site, vous pouvez ajouter le code correspondant au bas du fichier .htaccess.

L'exemple de code suivant peut être utilisé comme point de départ.Il définit les en-têtes de sécurité HTTP les plus couramment utilisés avec les paramètres recommandés.

 <IfModule mod_headers.c>
Jeu d'en-têtes Strict-Transport-Security "max-age=31536000 ; includeSubDomains ; preload" env=HTTPS
Jeu d'en-tête X-XSS-Protection "1 ; mode=block"
Jeu d'en-tête X-Content-Type-Options "nosniff"
Jeu d'en-tête X-Frame-Options DENY
Ensemble d'en-tête Referrer-Policy "no-referrer-when-downgrade"
Jeu d'en-têtes Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com themes.googleusercontent.com ; connect-src https : wss : 'self' ; img-src https : données : 'self' http : *.gravatar.com ; worker-src blob : https : 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
L'en-tête définit toujours Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), gyroscope=(), magnétomètre=(), camera=(), microphone=(), fullscreen=(self)"
</IfModule>

Une fois que vous avez ajouté la configuration ci-dessus à votre fichier .htaccess, les en-têtes pertinents seront appliqués à toutes les requêtes Web.

Vous pouvez vérifier si les en-têtes sont utilisés en ouvrant l'onglet "Réseau" dans Chrome DevTools et en inspectant les en-têtes de réponse de votre demande.

Onglet Réseau Chrome DevTools

Après avoir ajouté le code, enregistrez vos modifications et revisitez votre site Web pour vous assurer qu'ils fonctionnent comme prévu. Vous devez également être prudent lors de la modification de votre fichier .htaccess car des en-têtes de code incorrects ou des fautes de frappe peuvent déclencher des erreurs telles que l' erreur 500 Internal Server .

Ajout d'en-têtes de sécurité HTTP dans WordPress à l'aide d'un réseau de distribution de contenu (CDN)

Un réseau de diffusion de contenu (CDN) est un groupe de serveurs répartis géographiquement qui fournissent du contenu Internet mis en cache à partir d'un emplacement réseau le plus proche d'un utilisateur afin d'améliorer les performances Web. Les CDN populaires tels que Cloudflarevous permettent également d'ajouter des en-têtes HTTP à votre site Web.

Prenons Cloudflare comme exemple et voyons comment nous pouvons ajouter des en-têtes HTTP à l'aide d'un CDN. Cloudflare propose un pare-feu de site Web gratuit rudimentaire avec le service CDN, mais les fonctionnalités de sécurité les plus avancées sont verrouillées derrière un mur payant.

La configuration de Cloudflare sur votre site Web WordPress est assez simple. Vous pouvez vous inscrire manuellement sur le site Web de Cloudflare et suivre les étapes à l'écran pour l'activer. Une fois que Cloudflare a été activé sur votre site Web, rendez-vous sur la page SSL/TLS dans le tableau de bord de votre compte Cloudflare.

Vous devrez ensuite passer à l'onglet "Certificats Edge" et localiser la section HTTP Strict Transport Security (HSTS), puis cliquer sur l'option "Activer HSTS". Après avoir activé le bouton "Activer HSTS", une fenêtre apparaîtra avec des instructions pour vous aider à activer cette fonctionnalité sur votre site. Cliquez sur le bouton "Suivant" pour continuer le processus, et vous verrez l'option d'ajouter des en-têtes de sécurité HTTP.

À partir de là, vous pouvez activer HSTS sur votre site et également choisir d'appliquer HSTS aux sous-domaines qui utilisent HTTPS. L'utilisation de cette méthode fournira à votre site une protection de base à l'aide d'en-têtes de sécurité HTTP, mais l'inconvénient est que Cloudflare ne vous permet pas d'ajouter X-Frame-Options actuellement.

Il convient de noter que pour servebolt.com et tous les autres domaines de Cloudflare, HSTS est activé par défaut.

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

Une troisième méthode d'ajout et de configuration des en-têtes HTTP consiste à utiliser un plug-in. Bien que ce soit l'un des moyens les plus simples d'ajouter des en-têtes de sécurité HTTP à votre site Web WordPress, c'est généralement un peu moins efficace que de configurer manuellement les en-têtes.

Vous avez peut-être déjà lu ailleurs que de nombreux plugins de sécurité incluent la possibilité d'ajouter des en-têtes de sécurité. Cependant, nous vous déconseillons d'utiliser un plugin de sécurité. Lisez notre article sur les plugins de sécurité WordPress pour comprendre pourquoi et quels sont les problèmes liés à leur utilisation.

Cette section vous permettra d'activer ou de désactiver divers en-têtes et de définir différents paramètres pour eux. Les en-têtes exacts que vous pouvez activer varient en fonction du plugin de votre choix, mais les plus courants comme X-XSS-Protection, X-Content-Type-Options, X-Frame-Options et Strict-Transport-Security sont couverts par la plupart des plugins.

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

Après avoir ajouté les 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. Vous pouvez utiliser l'un des nombreux outils gratuits disponibles sur Internet pour effectuer un test. Nous vous recommandons d'utiliser les en-têtes de sécurité ou SSL Labs , qui vous permettent tous deux de tester facilement votre configuration et de vérifier que tous les en-têtes de sécurité fonctionnent correctement.

Ces outils évalueront les en-têtes de sécurité de votre site Web et vous fourniront un rapport détaillé. Ils vous indiquent également quels en-têtes de sécurité HTTP votre site Web envoie et lesquels ne sont pas envoyés. Votre site recevra alors une note de A+ à F, ainsi qu'une explication de la façon dont cette note a été déterminée.

Par exemple, lors du test du site Web de Vogue , nous avons constaté qu'il manquait de nombreux en-têtes HTTP importants, il n'a donc obtenu qu'une note C.

Test SSL Vogue

Et, comme vous pouvez vous y attendre lorsque vous testez notre propre site Web, il obtient une note A+.

Test SSL de Servebolt

Conclusion

Il ne fait aucun doute que la mise en œuvre des en-têtes HTTP est une étape essentielle pour sécuriser votre site Web. Après avoir ajouté avec succès des en-têtes HTTP à votre site Web, voici quelques étapes supplémentaires à prendre en compte :

  1. Tester les vulnérabilités : Il est important de tester votre site pour les vulnérabilités de sécurité courantes telles que Cross-Site-scripting (CSS) et Cross-site-request-Forgery (CSRF).Pour cela, vous pouvez utiliser des outils tels que OWASP ZAP et Burp Suite .
  2. Surveiller les changements : vous devez surveiller régulièrement les en-têtes pour tout changement inattendu, car cela indique généralement qu'il y a eu des tentatives d'exploitation d'une vulnérabilité.
  3. Mettez à jour les en-têtes : à mesure que de nouvelles menaces apparaissent, il est important de rester à jour avec les dernières pratiques de sécurité et de mettre à jour vos en-têtes en conséquence.

Intéressé par un hébergement géré qui est empiriquement plus rapide ?

Essayez notre approche de l'hébergement WordPress - le démarrage est gratuit et les avantages incluent :

  • Évolutivité : dans les tests de charge de travail des utilisateurs réels, Servebolt a fourni des temps de réponse moyens de 65 ms, soit des temps de réponse 4,9 fois plus rapides que le deuxième meilleur.
  • Les temps de chargement mondiaux les plus rapides : les temps de chargement moyens des pages de 1,26 seconde nous placent en tête de la liste des résultats mondiaux de WebPageTest.
  • La vitesse de calcul la plus rapide : les serveurs Servebolt offrent des vitesses de base de données sans précédent, traitant 2,44 fois plus de requêtes par seconde que la moyenne et exécutant PHP 2,6 fois plus vite que le deuxième meilleur !
  • Sécurité et disponibilité parfaites : avec une disponibilité de 100 % sur tous les moniteurs et une note A+ sur notre implémentation SSL, vous pouvez être assuré que votre site est en ligne et sécurisé.

En bref, en nous laissant vous décharger de l'hébergement, vous faciliterez l'amélioration de la sécurité, de la vitesse et des performances de votre site. Inscrivez-vous à Servebolt pour nous mettre à l'épreuve.