La sécurité WordPress sans extension

Le problème avec la sécurité basée sur des extensions

Une extension de sécurité WordPress s'exécute à l'intérieur de WordPress — utilisant le propre processus PHP du site, sa propre connexion à la base de données, son propre accès aux fichiers. Ce n'est pas exactement un défaut, c'est juste ainsi que fonctionnent les extensions. Mais cela signifie que l'outil qui surveille votre site partage exactement la même surface d'attaque que le site lui-même. Si WordPress est un jour compromis à un niveau suffisamment profond pour compter, l'extension qui le protège est compromise avec lui.

Il y a un second coût, plus discret : chaque extension est plus de code qui doit être maintenu à jour, plus de surface pour une future vulnérabilité, et souvent un autre identifiant de niveau admin stocké quelque part dans la pile. Les outils de sécurité sont censés réduire votre risque, pas s'ajouter à la pile de choses qui peuvent mal tourner.

Ce que signifie réellement la sécurité « de l'extérieur vers l'intérieur »

Tout ce qu'une extension peut lire — fichiers core WordPress, fichiers de thème et d'extension, répertoire de téléversements, base de données — est également accessible d'une manière complètement différente : via SSH, en utilisant une clé dédiée limitée à cet usage. L'outil ne touche jamais votre connexion administrateur WordPress, ne s'exécute jamais en tant qu'utilisateur WordPress, et ne fait jamais partie de l'application qu'il vérifie.

Concrètement, cela signifie :

• Les vérifications d'intégrité des fichiers core s'exécutent en comparant les fichiers réels de WordPress à des sommes de contrôle connues comme fiables — effectuées depuis une session shell, pas un hook PHP à l'intérieur de WordPress.
• L'analyse de malware et de portes dérobées lit directement les répertoires de thème, d'extension et de téléversement depuis le disque, de la même manière qu'un enquêteur humain le ferait via SSH.
• Les vérifications de base de données se connectent en utilisant des identifiants lus depuis wp-config.php, sans impliquer la propre couche de requêtes de WordPress ni aucun de ses hooks d'extension.
• Les corrections — lorsqu'elles sont sûres et réversibles — sont appliquées de la même manière : directement au système de fichiers ou à la base de données, jamais en déclenchant du code à l'intérieur d'un processus WordPress en cours d'exécution.

Pourquoi SSH plutôt qu'une connexion WordPress

Une clé SSH peut être générée spécifiquement pour un seul usage, importée dans le gestionnaire de clés d'un compte d'hébergement, et révoquée à tout moment sans toucher à quoi que ce soit d'autre concernant le compte — voyez exactement comment dans notre guide d'installation. C'est une empreinte fondamentalement plus petite qu'une extension détenant une session admin permanente à l'intérieur de WordPress lui-même. Cela signifie aussi que l'outil de sécurité continue de fonctionner même si le propre système de connexion de WordPress est ce qui est compromis.

Ce que cette approche ne peut pas faire

En toute honnêteté sur le compromis : les outils de l'extérieur vers l'intérieur ont besoin d'un accès SSH, que la plupart des hébergeurs fournissent mais que certains restreignent ou désactivent par défaut. Et ils ne peuvent pas s'accrocher au propre runtime de WordPress comme le ferait une extension — donc ce n'est pas le bon choix pour des choses comme le filtrage de requêtes en temps réel, ce à quoi sert réellement un pare-feu au niveau DNS. L'analyse de l'extérieur vers l'intérieur et un pare-feu périphérique résolvent des problèmes différents, et de nombreux sites sont bien servis en utilisant les deux.