Quelles entêtes de sécurité indispensables pour WordPress ?

On n’est jamais trop porté sur la sécurité avec WordPress. Non pas que notre CMS préféré soit vulnérable. Non. C’est juste qu’il propulse plus du tiers de la totalité des sites internet. En ce qui concerne les sites web spécifiquement réalisé par un CMS, on le retrouve même dans deux tiers des cas. Ainsi, c’est mécanique. Quand on est populaire, on est plus souvent pris pour cible. C’est comme ça…

 

T’inquiète, mon plugin de sécurité s’occupe de tout !

Cependant, vous avez certainement déjà pris vos dispositions, n’est-ce pas ? Vous avez forcément installé une extension de sécurité. Quelque chose comme le très bon Itheme Security ? À moins que vous ne vous soyez tournés vers les plus connus Secupress ou Wordfence ? Peut-être même êtes-vous allé chez le top du top Sucuri ? Toutefois, même si ces plugins ont ajouté moult lignes dans votre .htaccess, vous pouvez encore optimiser ce fichier en la matière et ce,  avec quelques en-têtes HTTP à y inclure.

Avant toute chose, si vous ne savez pas ce qu’est le fichier .htaccess, je vous renvoie vers ce très bon article du chef ! En effet, une erreur dans ce fichier ne pardonne pas ! D’ailleurs, vous y trouverez quelques lignes utiles pour optimiser votre .htaccess spécifiquement pour WordPress.

C’est quoi une en-tête HTTP ?

Votre site WordPress est affiché via un serveur. Ainsi, quand l’un de vos utilisateurs y accède, il demande en fait au serveur de le lui afficher. Pour cela, il faut que l’utilisateur puisse communiquer avec le serveur et que le serveur communique lui-même avec votre site internet. Dans un environnement WordPress, c’est le fichier .htaccess que ça se passe. Celui-ci est situé à la racine de votre gestionnaire FTP. Dans l’exemple ci-dessous, j’utilise Filezilla.

Une en-tête HTTP est en fait une information supplémentaire envoyée au serveur que celui-ci devra retourner au moment de l’affichage. Pour que tout soit ok, il faut que la configuration du site web et sa structure soient conformes aux informations envoyées. D’ailleurs, vous en avez peut-être déjà entendu parler. Du moins, si vous vous êtes intéressé à la mise en cache de votre WordPress. En effet, les outils de performance vous ordonnent d’inclure des expire headers ou en-têtes d’expiration en français. Je vous en ai ainsi partagées quelques unes lors d’un récent article sur l’optimisation des images sous WordPress.

La Strict Transport Security Header

Pour communiquer avec les serveurs et afficher des sites web, votre navigateur utilise un protocole. Jusqu’en 2016-2017, ce protocole était http (Hyper Text Transport Protocol). Depuis, on est passé au https. “S” comme secure ou “sécurisé” en français. Celui-ci permet de chiffrer les données échangées entre le navigateur et le serveur via votre site internet. Ceci afin d’en garantir la confidentialité.

Cependant, le protocole http n’a pas disparu. D’ailleurs, il est fort probable que votre site ait toujours une adresse email débutant par http://. Et ce même s’il en a bien une débutant par https://. La Strict Transport Security header ou en-tête HSTS permet de forcer l’utilisation du protocole https. Même si l’utilisateur entre http://votresite.com ou tout simplement votresite.com. Pour mettre en œuvre cette en-tête, entrez ces quelques lignes dans votre .htaccess :

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Le cas des redirections http vers https

Peut-être me direz-vous que vous avez déjà mis en place une redirection automatique. En effet, la plupart des plugins de sécurité comme Itheme Security ou Wordfence la proposent. Toutefois, il ne s’agit pas du seul moyen de l’implémenter. En effet, vous pouvez aussi l’inclure directement via le .htaccess grâce à ces lignes.

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.votresite.com/$1 [R,L]

Pourtant, cela ne vous dispense pas d’ajouter Strict Transport Security Header. Pourquoi ? Parce que la redirection seule laisse une fenêtre de tir pour “l’homme du milieu”. C’est le nom d’une attaque qui consiste à détourner cette redirection vers un site malveillant. Pour cela le hackeur se place entre http://votresite.com qui va s’afficher brièvement et https://votresite.com vers lequel le premier est redirigé. L’en-tête de sécurité n’est pas une redirection mais un ordre indiquant d’afficher votre site internet directement en https.

L’en-tête referrer : kezaco ?

Certes, la toile ne s’est pas construite en un jour. Cependant, quelques fondamentaux étaient là au commencement. C’est le cas des référents ou referrer. Leur principe est très simple. Il s’agit d’informer un serveur des liens utilisés pour pointer vers un site web. Pour vous donner un exemple, si je fais un lien vers https://maximemalfoy.com (;-D) et que vous cliquez dessus, mon serveur sera informé que la requête d’origine vient de wpformation.com. C’est le B-A BA des analyses de trafic. Toutefois, la W3C recommande de mettre un peu d’ordre dans tout ça via une referrer policy.

Pour cela, je vous invite à entrer les lignes suivantes :

<IfModule mod_headers.c>
Header set Referrer-Policy "no-referrer"
</IfModule>

Comment choisir la directive de ma referrer policy ?

Ici, la directive indiquée au serveur est no-referrer. Avec elle, aucune information sur le référent ne sera transmise. Mais il existe sept autres directives possibles à votre discrétion.

Entre les guillemets, vous pouvez aussi entrer origin. Dans ce cas, on ne transmet que l’URL absolue du site même si le lien suivi se trouve sur une page. Ainsi, si j’arrive sur wpformation.com via un lien sur http://votresite.com/mentions-legales, seule http://votresite.com sera transmise à wpformation.com.

La valeur no-referrer-when-downgrade est la directive par défaut de la referrer policy. C’est à dire qu’en l’absence d’indication ou si celle-ci est invalide, c’est elle qui s’appliquera. Elle garantit la transmission de l’URL référente si le protocole est équivalent (http vers http ou https vers https) ou supérieur (http vers https) mais pas l’inverse (https vers http). Avec la directive strict-origin, seule l’URL absolue est transmise et seulement si le protocole est plus élevé (http vers https) ou équivalent (https vers https). Dans les autres cas, rien n’est transmis.

Dans le cas de same-origin, le serveur de votre site sera le seul à recevoir des informations. En effet, les données ne sont transmises que dans le cas où l’URL référente a la même URL absolue. Ceci exclue donc toutes les URL externes. En revanche, origin-when-cross-origin permet d’envoyer au serveur l’intégralité de l’URL si l’adresse absolue référente est la même. Dans les autres cas, seule l’URL absolue sera transmise. Enfin, strict-origin-when-cross-origin a la même fonction que origin-when-cross-origin. À ceci près que l’on transmet aussi l’URL absolue du référent si le niveau de sécurité du protocole est aussi élevé (https vers https). Si non, rien ne passe. Il est à noter que cette dernière directive deviendra probablement la valeur par défaut de beaucoup de navigateurs à l’avenir.

La sécurité passe aussi par les fonctionnalités avec les Permissions Policy

Peut-être avez-vous déjà entendu parler de cette en-tête. En effet, elle a eu pour nom feature policy. Aujourd’hui, on l’appelle permissions policy. Son but est d’autoriser ou non certaines fonctionnalités du navigateur. Car celles-ci peuvent affecter l’expérience utilisateur ou tout simplement capter des données que vous ne souhaitez pas échanger. D’autre part, ces outils peuvent aussi être utilisés à des fins malveillantes. Donc, si vous ne vous en servez pas sur votre site WordPress, autant les désactiver !

Ainsi, une trentaine d’options sont gérables via cette permissions policy header. Cependant, sachez que toutes ne sont pas prises en charge par ces navigateurs. Voici une liste a priori exhaustive des fonctionnalités en question dont certaines vous paraîtront sûrement plus utiles que d’autres :

• accelerometer
• ambient-light-sensor
• autoplay
• battery
• camera
• display-capture
• document-domain
• encrypted-media
• fullscreen
• geolocation
• gyroscope
• layout-animations
• legacy-image-formats
• magnetometer
• microphone
• midi
• navigation-override
• oversized-images
• payment
• picture-in-picture
• publickey-credentials-get
• sync-xhr
• usb
• wake-lock
• screen-wake-lock
• web-share
• xr-spatial-tracking

Sans pour autant reprendre toutes ces directives, on peut donc s’orienter vers ces types de lignes à insérer :

<IfModule mod_headers.c>
Header set Permissions-Policy "autoplay '*'; camera 'none'; payment 'self'; geolocation 'none'; microphone 'none' "
</IfModule>

Bien sûr, vous ajoutez autant de fonctionnalités que vous le souhaitez. Mais pour indiquer s’il faut les désactiver ou non et comment, une valeur doit s’y associer. C’est ce qui prend place entre les ‘ ‘. Vous avez donc le choix entre trois possibilités :

• * qui permet d’activer la fonctionnalité quelle que soit son origine.
• self qui autorise la fonctionnalité si elle provient du même domaine que le site en question.
• none pour désactiver totalement la fonctionnalité.

Sécuriser les Content-type headers avec X-Content-Type-Options

Quand le navigateur échange des données avec votre serveur, il demande la nature de ces données. Ainsi, le serveur dit au navigateur qu’il doit charger des scripts, des images, des pages HTML etc…). Pour cela, le serveur envoie ce qu’on appelle des types MIME au navigateur qui va les interpréter. Le problème, c’est que, en l’état, ces types MIME ne sont pas du tout sécurisés. Et ce à tel point qu’un petit malin peut tout à fait les modifier. D’ailleurs, certaines options des navigateurs le permettent. C’est l’une des failles via lesquelles des attaques Drive-By-Download se produisent. On modifie le type de données sur un site internet sérieux pour que ses contenus renvoient vers d’autres sites malveillants ou téléchargent du contenu dangereux.

Heureusement pour nous, il existe un moyen pour que le serveur dise au navigateur que ces types MIME ne sont pas modifiables. Les fonctions en question se trouvent donc désactivées. Ce moyen, il réside dans une en-tête de sécurité X-Content-Type-Options. Elle est plutôt simple à mettre en place et sans risque. En effet, une seule directive est possible : nosniff. Vous pouvez donc entrer ces lignes dans votre .htaccess :

<IfModule mod_headers.c>
    Header set X-Content-Type-Options "nosniff"
</IfModule>

Content-Security-Policy headers : le gros morceau

Nous arrivons à THE en-tête de sécurité. C’est aussi la plus compliquée à mettre en place car elle diffère selon chaque site web. Et votre WordPress ne fera pas exception à la règle. En effet, la content-security-policy (ou CSP) permet de gérer et contrôler les sources des éléments s’affichant (ou pas) sur votre site internet.

Avant d’aller plus loin, je vous conseille de mettre en place cette en-tête en dernier, une fois que votre site est prêt à être mis en production. En effet, elle a tendance à créer quelques soucis à régler progressivement. C’est pourquoi je vous conseille aussi de vérifier via la console du navigateur ce qu’il en est après chaque ajout de directive.

D’ailleurs, ne vous limitez pas au frontend. Regardez bien les effets de cette CSP sur votre panneau d’administration WordPress et réglez les bugs s’il y en a.

Une CSP pour quoi faire ?

L’en-tête de sécurité Content-Security-Policy propose une petite trentaine de directives. Cependant, ne soupirez pas devant la tâche. Grâce à elles, vous pourrez contrôler toutes les sources en relation avec votre site WordPress. Car nous avons besoin de créer des relations avec des services tiers. Ça peut être Google Analytics ou n’importe quel autre service de Google, ça peut être le pixel Facebook etc… Pourtant, ouvrir tous les accès sans contrôle n’est pas une solution pour autant. Et ce même si c’est celle retenue par beaucoup de sites internet actuellement.

Seulement, laisser la possibilité à n’importe quelle source de se mettre en relation avec votre site vous rend vulnérables à certaines attaques. On pense notamment à l’injection de code qui peut aboutir à du vol de données ou l’inclusion de programmes malveillants. Des programmes malveillants qui peuvent renfermer des solutions de clickjacking, par exemple, et piéger vos utilisateurs. Vous l’aurez compris, non seulement ces attaques sont un risque pour l’intégrité de votre WordPress mais aussi pour sa réputation auprès du public.

Comment mettre en place cette en-tête de sécurité ?

Comme pour les précédentes, rendez-vous dans le .htaccess. Je le répète mais allez-y très progressivement et vérifiez bien chaque effet dans la console de votre navigateur. D’ailleurs, celle-ci peut aussi vous guider vis-à-vis des directives manquantes ou pertinentes à inclure. Mais pour débuter, vous pouvez entrer les lignes suivantes contenant les directives les plus importantes :

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'none'; frame-src 'self'; object-src 'none' ; img-src 'self'; connect-src 'self'; script-src * ; script-src-elem * ; style-src * ; style-src-elem * ;  "
</IfModule>

La directive default-src est, comme son nom l’indique, la valeur par défaut. Elle s’applique à toutes les directives non-spécifiée dans l’en-tête. Mais vous pouvez spécifier un très grand nombre d’éléments avec une valeur particulière. img-src s’applique aux images, script-src aux scripts, frame-src aux iframes, object-src aux objets mais aussi aux contenus embarqués (embed). Ensuite, style-src autorise le chargement des éléments graphiques, particulièrement CSS. D’autre part, connect-src autorise le chargement d’URL à l’intérieur des éléments. Ce contrôle des sources chargées à l’intérieur même des éléments se retrouve aussi pour les scripts avec script-src-elem et le style (style-src-elem).

Toutefois, voici la liste des directives que vous pouvez ajouter au sein de cette en-tête. N’hésitez pas à les tester avec la valeur ‘none’ et vérifier le retour que vous fait la console du navigateur. Plus la CSP est spécifiée plus elle est fiable et prête pour tout ajout de nouvel élément de votre part.

• font-src
• manifest-src
• media-src
• prefetch-src
• script-src-attr
• style-src-attr
• worker-src
• base-uri
• plugin-types
• sandbox
• form-action
• frame-ancestors
• block-all-mixed-content
• require-sri-for
• trusted-types
• upgrade-insecure-requests

Quelles valeurs spécifier pour WordPress ?

Il y a deux aspects au sein des autorisations que vous donnez dans votre politique de sécurité. D’une part, il y a la valeur que vous indiquez à la directive. D’autre part, la liste blanche, c’est à dire les sources auxquelles vous donnez un accès “exclusif” à votre site.

Du côté des valeurs, nous en avons principalement 3:  *, qui donne un accès à toutes les sources sans restriction, none qui ferme l’accès à toutes les sources et self qui n’autorise l’accès qu’aux contenus provenant de votre propre site web. Je vous parlerais bien des valeurs unsafe-inline, unsafe-eval et unsafe-hashes. Mais comme leur nom l’indique, ces valeurs ne sont pas sécurisées. Elles vous font même perdre le bénéfice de votre Content Security Policy pour la directive en question. Cependant, vous pouvez être contraint d’utiliser unsafe-inline dans certains cas avec certaines sources de scripts et de styles. Assurez-vous donc que ces éléments soient issus de sources sûres pour limiter la casse.

Enfin, dans la liste blanche, vous pouvez ajouter les éléments bloqués par votre CSP. Référez-vous à votre console de navigateur. Elle vous indique les URL bloquée. Si vous savez ce que vous faîtes (ce dont je ne doute pas), vous repérerez facilement les URL à inclure. Tout cela vous demandera un peu de temps. Mais ça vaut le coup de s’y intéresser.

Une en-tête de sécurité pour gérer l’affichage de votre site sur les autres sites ?

Les iframes sont bien pratiques. Pas toujours très maniables mais pratiques. Seulement, elles ne sont pas du tout sécurisées. À tel point qu’elles sont utilisées pour réaliser des opérations de clickjacking dont je vous parlais plus haut. Il est donc intéressant de contrôler si votre site peut être embarqué ou non. Ou, du moins, s’il peut être embarqué ailleurs que sur votre propre WordPress. C’est justement ce à quoi sert l’en-tête X-Frame Options ! Via deux directives, elle vous permet d’empêcher d’embarquer les contenus de votre site (deny) ou de ne les servir que sur votre propre site (sameorigin).

Voici comment l’inclure dans votre .htaccess :

<IfModule mod_headers.c>
Header always append X-Frame-Options sameorigin
</IfModule>

Une en-tête bientôt obsolète ?

Cette en-tête est toujours utile. Toutefois, elle risque de vite devenir un doublon. En effet, une directive de la Content-Security-Policy permet cette fonction avec plus de possibilités. Il s’agit de frame-ancestors. Avec les valeurs none ou self, elle a les mêmes vertus que cette X-Frame-Options header. Mais, comme montré plus haut, vous pouvez aussi agrémenter cette valeur d’une liste blanche si vous permettez à certains partenaires d’embarquer votre contenu.

Peut-on gérer ces en-têtes de sécurité avec un plugin ?

Bien sûr que oui ! Je comprends parfaitement que certains d’entre vous soient réticents à l’idée de tripatouiller le fichier .htaccess. En effet, il est assez sensible et peut vite vous mener à l’infernale page blanche de la mort qui tue… Heureusement pour vous, on peut facilement le laisser tranquille. Ainsi, je vais vous présenter trois extensions qui ont chacune leurs spécificités pour intégrer les en-têtes de sécurité.

HTTP headers to improve web site security : la sécurité, rien que la sécurité

Vous êtes novices ? Vous ne souhaitez pas un tableau compliqué avec trop d’options ? HTTP headers to improve web site security est l’extension qu’il vous faut ! Pas de fioriture et une efficacité prouvée. Certaines options sont en passe d’être obsolètes, d’autres ont un nom désuet mais il est bien mis à jour et compatible avec la version en cours de WordPress. Du moins, pour l’instant.

Un plugin simple et rapide au premier abord

Une fois que vous avez téléchargé l’extension depuis le répertoire officiel, vous l’activez depuis le menu extension dans l’administration de votre WordPress. Ensuite, c’est dans Réglages → HTTP Security qu’il vous faut vous rendre. HTTP headers to improve web site security, ce sont quatre onglets. Ni plus ni moins.

Certes, mais pour quoi faire ? Le premier onglet regroupe la majorité des en-têtes disponibles. D’ailleurs, la première vous est peut-être inconnue. En effet, je ne vous ai pas parlé de l’en-tête Expect-CT. Intégrée à la Strict-Transport-Security header, elle commande au navigateur de vérifier le certificat SSL utilisé et donc sa validité. D’une part, elle ne fonctionne que si votre site est en https (ce que je vous recommande grandement). D’autre part, elle sera obsolète en juin 2021. Ceci parce que les navigateurs incluent cette fonctionnalité nativement. C’est le cas, notamment, de Google Chrome.

La plupart des en-têtes de sécurité vite expédiées

En revanche, les autres options disponibles sont bien à jour. Ainsi, la section X-Frame Options permet de configurer l’en-tête éponyme. Sous la forme de boutons radios, vous pouvez décider d’assigner l’une des trois directives possibles à cette header. Cependant, vous pouvez ne pas trop vous y attarder. Comme dit plus haut, cette en-tête est obsolète. Elle est remplacée par la directive frame-ancestors de la Content Security Policy. Bien sûr, celle-ci est prise en charge par l’extension.

Ensuite, on passe à la referrer policy. Cette fois, c’est sous la forme d’un menu déroulant que le plugin propose d’assigner l’une des sept directives valides.

Quant aux quatre cases à cocher en bas de page, elles font référence à diverses options de sécurité. La première concerne la protection X-XSS. La deuxième case “Bloquer le reniflement du contenu” est en fait l’activation de l’en-tête X-Content-Type-Options. Une seule directive y est associable : nosniff. Enfin, les deux dernières cases consistent à masquer les versions de WordPress et de PHP utilisées. La seconde est sûrement gérée par votre hébergeur. Pour la première, vous pouvez aussi le faire via le fichier functions.php de votre thème. C’est l’un des quinze conseils de sécurité exposés ici.

Tout pour gérer CSP et Permissions Policy

La Content Security Policy (CSP) et la Permissions Policy ont chacune leur onglet dédié.

Dans la première, vous retrouvez l’intégralité des directives disponibles. Y compris celles moins utiles permettant seulement de récupérer des rapports sur les interactions avec les sources extérieures. Celles-ci sont ici dénommées “directives de documents”. D’ailleurs, l’extension propose de n’activer la CSP qu’à titre d’information. Ceci grâce à la case “Compte rendu seul”.

Quant aux valeurs à assigner aux directives, n’oubliez pas de les entrer entre ‘ ‘ comme si vous le faisiez directement dans votre .htaccess. De la même manière, vous devrez entrer à la suite les URL de votre liste blanche.

La permissions policy est aussi présente mais sous son ancien nom : feature policy. Elle fonctionne exactement de la même manière. Et ce bien que seules les neuf directives les plus importantes soient disponibles.

Enfin, le quatrième onglet vous permet de visualiser les lignes insérées dans votre fichier .htaccess. Même si certaines options sont obsolètes, une mise à jour du service est attendue avant juin 2021 et la disparition de l’en-tête Expect-CT. Ceci afin de laisser place à une Strict-Transport-Security header plus proche de celle que l’on connaît aujourd’hui. À moins que celle-ci ne soit définitivement remplacée à terme par la directive block-all-mixed-content de la Content Security Policy.

GD Security Headers : une sécurité renommée et efficace

Mais permettez-moi de vous parler de la Rolls Royce du secteur : GD Security Headers. Vous avez sûrement déjà croisé d’autres extensions de la gamme. En effet, le développeur Dev4press est très connu pour son plugin de notation par étoiles GD Rating system. Mais il l’est encore plus des utilisateurs de BBpress grâce à ses plugins GD BBpress Tools et GD BBpress Attachments entre autres !

Le pedigree de l’équipe de développement est un atout indéniable. Le fait que l’extension coche toutes les cases du test WP Hive aussi. Croyez-moi, cela n’arrive pas souvent. Donc vous pouvez y aller sans risque. Cependant, cette solution est beaucoup moins légère que la précédente. En effet, elle est légèrement plus impactante sur la performance que HTTP headers to improve web site. Mais GD Security Headers alourdit aussi votre base de données. Ceci avec l’ajout de deux tables et sept lignes dans la table options. Un luxe dont se passe très bien son prédécesseur.

 5 onglets, 5 panneaux beaucoup (beaucoup) d’options

GD Security Headers a cet avantage qui est aussi son inconvénient : son exhaustivité. En effet, au premier abord, l’extension pourrait vous paraître pléthorique. Pourtant, le plugin ne comporte pas plus d’options que son prédécesseur. C’est juste qu’il prend le parti de tout ranger et de vous présenter chaque directive une à une. Le tout avec une place bien précise pour chaque en-tête. Ainsi, il s’agit plutôt de vous prendre par la main et vous guider plutôt que vous perdre dans une multitude d’options. Même s’il vous faudra tout de même maîtriser l’anglais pour vous y retrouver…

De l’option mineure à la sécurité avancée

Ainsi, l’onglet global ne comporte qu’une seule case à cocher. Celle-ci propose de reporter vos configurations en en-têtes dans le .htaccess à la racine de votre WordPress. Notons que cette option n’est utilisable que si votre serveur tourne sous Apache. Pour savoir si c’est le cas, vous devrez vous adresser à votre hébergeur. Cependant, GD Security Headers a aussi pensé à ceux dont le serveur tourne sous Ngnix ou Ils. En effet, dans le menu headers, le plugin retranscrit votre configuration en code pour Apache, Ngnix ou Ils.

En ce qui concerne l’onglet X-XSS Protection dans le menu Settings, il vous propose, comme son nom l’indique, d’activer l’en-tête éponyme. Pour cela, trois cases à cocher s’offrent à vous. Une pour activer l’en-tête, une autre pour activer les logs et la dernière pour forcer le recours au HTTPS.

Quant à l’onglet more headers, il regroupe les en-têtes X-Content-Type Options, Strict-Transport-Security et X-Frame Options sans oublier la Referrer policy. Là encore, vous êtes guidé à chaque étape avec une simple case à cocher pour activer ces en-têtes. En ce qui concerne les directives, un menu déroulant vous permet de faire votre choix. Le tout avec un petit bandeau d’aide à chaque étape.

Une Content Security Policy guidée à défaut d’être simple

Ensuite, il ne nous reste plus que deux onglets dans cette partie settings. Il s’agit de ceux dédiés à la Content Security Policy et la Permissions Policy. D’ailleurs, je fais une petite parenthèse sur le fait que cette dernière se nomme encore Feature Policy. Si on ajoute à cela la présence tenace de l’en-tête X-Frame Options, on voit bien que la mise à jour des intitulés n’est pas gage de mauvaise qualité. Et ce bien que, sûrement pour éviter de vous perdre (encore), l’extension propose d’activer la Permissions Policy ou la Feature Policy ou les deux. ¯\_(ツ)_/¯

Mais pour l’une comme pour l’autre, vous aurez l’impression de tomber sur des pages au défilement (presque) infini. Non, GD Security Headers ne propose pas plus d’options que HTTP headers to improve web site security. Toutefois, il vous prend par la main et s’arrête sur chaque directive. Un panneau déroulant les accompagne pour que vous puissiez choisir la bonne valeur à assigner. Enfin, une dernière case se présente pour indiquer les URL à autoriser. De plus, le plugin va même jusqu’à ranger les directives de la Content Security Policy par ordre de priorité. Ceux-ci sont au nombre de trois.

Se concentrer sur la Content Security Policy ?

Si vous suivez mes écrits, vous savez que je suis partisan du “peu de plugins”. Pourtant, la Content Security Policy, bien que très utile, peut vite devenir délicate à gérer. Surtout si vous travaillez en équipe à travers un site ou que celui-ci regroupe une communauté. En effet, une CSP peut entrer en conflit avec certaines fonctionnalités. Heureusement, une extension propose des réglages très fins pour faire tenir tout ça debout : Content Security Policy Manager.

Content Security Policy Manager : 3 CSP en un plugin WordPress

Content Security Policy Manager peut paraître confidentiel avec sa petite trentaine d’installations actives. Après, il n’a que quatre mois… Toutefois, même si WP Hive fait la moue sur sa fréquence de mises à jour (!), il a ses atouts. Comme celui de très peu influer sur les performances de votre WordPress après activation. D’autre part, il se limite à l’implantation de trois lignes dans la table options en base de données. En terme de légèreté, CSP Manager se pose donc là.

Un écran, trois onglets, une sécurité fine

Comme d’habitude, vous téléchargez Content Security Policy Manager depuis le répertoire officiel. Ceci fait, rendez-vous dans Réglages –> CSP Manager. L’extension se présente sous la forme d’un simple écran composé de trois onglets.

C’est la particularité de CSP Manager. En fait, vous allez retrouver les mêmes options au sein de ces trois onglets. La différence ? Elles vont s’appliquer à trois domaines distincts de votre WordPress. Admin Policy ne va appliquer les réglages qu’à l’administration tandis que Frontend Policy ne les appliquera qu’à l’affichage public de votre site. Enfin, comme son nom l’indique, Logged-in Policy permet d’appliquer une Content Security Policy à l’affichage public de votre site uniquement pour les utilisateurs connectés. Ce parti pris n’est pas anodin. En effet, la mise en place d’une CSP peut vite entrer en conflit avec ces différents domaines. Pour faire fonctionner tout votre environnement, vous devrez peut-être rogner sur la sécurité. Ce plugin permet de passer outre ce problème.

Cependant, contrairement à GD Security Headers, n’attendez pas que CSP Manager vous prenne par la main. En effet, le plugin vous décline l’ensemble des directives les unes à la suite des autres. Ensuite, charge à vous de les activer ou non et d’entrer, dans chaque zone de texte, les valeurs. Et ce de la même manière que vous le feriez dans le .htaccess. Ainsi, la valeur se trouve entre ‘ ‘ puis vous pouvez ajouter une ou plusieurs URL autorisées.

Prêts ? À vos en-têtes de sécurité !

Voilà ! Maintenant, votre WordPress est (presque) paré pour affronter les eaux dangereuses d’internet. Pour vérifier la validité de vos en-têtes HTTP de sécurité, quelques outils existent ! En effet, vous pouvez tester votre site internet sur securityheaders.com ! Celui-ci se fera un plaisir de vous faire part des en-têtes valides et des points à améliorer.

 

Vous pouvez aussi parfaire cette analyse en vous référant à l’observatoire Mozilla qui analyse quelques points supplémentaires. Cependant, on n’est jamais trop prudent. Ainsi, vous pouvez agrémenter ces réglages des 15 réglages de sécurité régulièrement mis à jour sur WPFormation. Cela dit, sachez bien que, malgré tout, on n’est jamais à l’abri.

Et vous, êtes-vous déjà aussi avancés en terme de sécurité ?
Peut-être plus encore ? Quoiqu’il en soit, n’hésitez pas à les partager en commentaire.