Mises à jour de sécurité du cœur de WordPress : ce qu’elles font vraiment

Lorsque vous vous connectez à votre tableau de bord WordPress et qu’un message vous signale qu’une nouvelle version est disponible, la tentation est de cliquer sur plus tard et de passer à autre chose. Le numéro de version n’a augmenté que de 0,0,1. Il ne doit sûrement rien y avoir d’important là-dedans. En pratique, c’est souvent le contraire. Les versions de sécurité du cœur de WordPress paraissent petites en surface et comptent beaucoup en profondeur. Cet article explique ce que contiennent réellement ces mises à jour, pourquoi elles existent et comment les appliquer sans casser votre site.

Comment les versions de WordPress sont numérotées

WordPress utilise un numéro de version en trois parties. Les versions majeures augmentent le premier ou le deuxième chiffre et introduisent de nouvelles fonctionnalités, des changements de design et des améliorations internes importantes. Par exemple 6.4, 6.5, 6.6, etc. Les versions mineures n’augmentent que le troisième chiffre et sont presque toujours axées sur la sécurité et la maintenance. Un passage de 6.7.1 à 6.7.2, c’est l’équipe de sécurité qui vous dit qu’elle a trouvé et corrigé quelque chose.

Les versions mineures sont généralement déployées automatiquement par défaut sur la plupart des sites, mais pas toujours. Si le réglage de mise à jour automatique a été désactivé, ou si le site repose sur une configuration d’hébergement inhabituelle, vous devrez peut-être les appliquer manuellement. Le risque est qu’une version mineure non appliquée vous expose à une vulnérabilité déjà documentée publiquement.

Ce que contient une version de sécurité typique

Les versions de sécurité de WordPress regroupent généralement plusieurs corrections distinctes. Une version représentative peut contenir la correction d’une faille de cross site scripting stocké, une élévation de privilèges dans un rôle utilisateur précis, un problème dans la REST API où des utilisateurs non authentifiés pouvaient lire plus d’informations qu’ils ne le devraient, et une correction de la manière dont WordPress traite une catégorie spécifique de téléversement de fichiers.

Chacune prise isolément n’est pas catastrophique, mais combinées, elles peuvent fournir à un attaquant un ensemble utile de briques. Les correctifs de sécurité ne visent pas toujours à empêcher une prise de contrôle complète du site. Parfois, ils empêchent qu’un petit trou serve d’étape dans une chaîne plus vaste.

Pourquoi l’équipe du cœur de WordPress publie les détails

Lorsque WordPress publie une mise à jour de sécurité, il publie aussi des informations sur ce qui a été corrigé. C’est un compromis délibéré. En étant transparent, le projet permet aux propriétaires de sites et aux outils de sécurité de connaître précisément leur risque. L’inconvénient est que les attaquants le savent aussi. Dans les heures qui suivent une version, des scanners automatisés commencent à sonder le web public à la recherche de sites exécutant encore la version précédente.

C’est pourquoi le délai entre la sortie et la mise à jour de votre site importe. Plus vous attendez, plus la fenêtre pendant laquelle une vulnérabilité documentée reste non corrigée sur votre serveur s’élargit.

Les mises à jour automatiques et quand elles ne suffisent pas

Depuis WordPress 3.7, les mises à jour de sécurité mineures peuvent être appliquées automatiquement. Pour la plupart des sites simples, c’est activé par défaut et cela fonctionne bien. Le site récupère le correctif dans les heures suivant la sortie et vous ne le savez que grâce à une notification par e-mail.

Il existe toutefois des raisons pour lesquelles cela peut ne pas se produire. Les mises à jour automatiques peuvent être désactivées dans wp-config.php ou par une extension. Certains hébergeurs appliquent leur propre calendrier de correctifs et désactivent le mécanisme intégré. Certains sites ont des permissions de système de fichiers qui empêchent WordPress d’écrire dans ses propres fichiers du cœur. Si vous n’êtes pas certain que les mises à jour automatiques fonctionnent sur votre site, vérifiez. Comparez le numéro de version affiché en bas de l’administration à la dernière version sur wordpress.org.

Les mises à jour majeures et la discipline de la préproduction

Les versions majeures sont différentes. Elles contiennent de nouvelles fonctionnalités et des changements de design, et peuvent modifier le comportement de manières auxquelles certaines extensions ou thèmes ne sont pas prêts. Le schéma le plus sûr consiste à appliquer les mises à jour majeures d’abord sur une copie de préproduction, à parcourir les pages clés, l’administration et toute fonctionnalité personnalisée, puis seulement à pousser le changement en production.

Pour un site d’entreprise, la cadence recommandée est d’appliquer les versions majeures dans un délai d’un à deux mois après leur disponibilité publique, une fois que les correctifs mineurs post-sortie se sont stabilisés. Cela vous laisse le temps de détecter toute rupture dans votre stack spécifique sans prendre un retard tel que vous sortiez du support.

Ce qui se passe si vous restez sur une ancienne version majeure

L’équipe de sécurité de WordPress rétroporte les correctifs de sécurité vers une poignée d’anciennes versions majeures, mais pas indéfiniment. Une fois qu’une version sort de la fenêtre de support, les vulnérabilités découvertes ne seront pas corrigées. Les sites sur ces versions deviennent exposés en permanence, et toute nouvelle faille publiée à leur encontre est une porte d’entrée gratuite pour les attaquants.

La politique de sécurité de WordPress prend généralement en charge la version majeure actuelle plus la précédente. Tout ce qui est plus ancien vit en sursis. Si vous exécutez aujourd’hui WordPress 5.quelque chose, vous êtes dans cette zone de danger.

La vue d’ensemble : cœur, thèmes, extensions, PHP

Maintenir le cœur de WordPress à jour n’est qu’une partie de l’histoire. La même logique s’applique à votre thème actif, à chaque extension installée et à la version de PHP que votre hébergeur exécute. Chacune de ces couches reçoit ses propres mises à jour de sécurité, et chacune doit rester à jour.

Un site exécutant le dernier cœur de WordPress mais une version de PHP vieille de cinq ans reste à risque, car PHP lui-même a reçu des correctifs de sécurité critiques durant ces années. Un site avec le dernier cœur et le dernier PHP mais un thème abandonné reste à risque. Toute la pile doit avancer ensemble.

Une routine de mise à jour pratique

La routine que nous appliquons sur les sites WordPress que nous gérons est la suivante. Confirmez une sauvegarde externe récente. Appliquez les mises à jour mineures du cœur dès leur parution, généralement automatiquement. Appliquez les mises à jour d’extensions et de thèmes au moins une fois par semaine, par lots, en préproduction pour les plus risquées. Appliquez les versions majeures du cœur mensuellement, après les tests en préproduction. Vérifiez la version de PHP chaque année, ou plus tôt si votre hébergeur annonce une dépréciation. Surveillez les flux de sécurité au cas où un zero day exigerait une intervention hors cycle.

Rien de tout cela n’est mystérieux. C’est simplement de la discipline. Les sites qui finissent en difficulté sont presque toujours ceux où la discipline a faibli, souvent pendant des mois ou des années.

Besoin d’un coup de main ?

Si vous ne savez pas si le cœur de votre WordPress est à jour, si les mises à jour automatiques se déclenchent correctement ou si votre site peut passer en toute sécurité à la dernière version majeure, Defyn peut auditer et tout remettre à niveau. Contactez-nous et nous remettrons votre pile dans un état stable et maîtrisé.