Audit et sécurisation WordPress : la checklist complète avant de déployer

Déployer WordPress en production, ce n’est pas juste “installer un thème et publier”. Entre les plugins, les droits, la configuration du serveur, les sauvegardes et la discipline d’accès, une faille ne vient presque jamais de nulle part. Elle vient d’un détail qui a été négligé: mot de passe réutilisé, plugin abandonné, règles firewall trop permissives, version PHP trop ancienne, permissions fichiers bancales, ou encore un site qui reste accessible en écriture alors que personne ne le surveille.

J’ai vu des scénarios très différents, du site vitrine qui devait rester “simple” à la plateforme e-commerce qui changeait de plugin tous les mois. Dans les deux cas, les dégâts suivent la même logique: l’attaque cherche la surface la plus facile, puis elle pivote. Et quand on arrive à “sécuriser”, on s’aperçoit qu’on n’a pas documenté ce qu’on avait au moment du déploiement. Sans base saine, même une bonne intention tourne vite au bricolage.

L’objectif de cette checklist est double: cadrer un audit et sécurisation WordPress sérieux, et préparer une mise en ligne qui résiste aux incidents courants, sans créer une usine à gaz ingérable. Vous trouverez des points concrets, des pièges fréquents, et des arbitrages réalistes.

Poser le cadre avant de toucher au code

Avant l’audit technique, je recommande de définir une “zone de vérité”. Sinon, on corrige des symptômes, pas des causes.

Commencez par établir ce qui doit être stable: URL principale, domaine, environnement de staging, contraintes de performance, exigences SEO, et surtout le niveau d’automatisation attendu. Un site qui doit publier du contenu chaque semaine n’a pas la même réalité qu’un site événementiel mis à jour une fois par an.

Ensuite, clarifiez les responsabilités. Qui valide la liste des plugins? Qui applique les correctifs? Qui gère les accès base de données? Qui répond en cas d’alerte? Même si vous êtes seul, écrivez-le noir sur blanc. La sécurité n’est pas seulement un réglage, c’est une routine.

Enfin, documentez le point de départ: version exacte de WordPress, thème actif, plugins, versions PHP et base de données, stack serveur (Nginx ou Apache), et présence éventuelle d’un reverse proxy ou d’un WAF. Cette photo vous servira après coup, surtout quand un correctif “détruit” quelque chose: vous saurez ce qui a changé.

Inventaire technique: ce que l’attaque regarde en premier

Dans beaucoup d’audits, la première découverte est presque toujours la même: l’inventaire des dépendances est incomplet. On croit savoir quels plugins servent, mais on oublie ceux installés puis désactivés, ceux qui ont été “gardés au cas où”, ou ceux qui ne sont pas sur la même branche d’environnement.

Visez la précision, pas le volume. Il faut savoir pour chaque plugin: fonction, état (actif, désactivé, non utilisé), version, et dernière mise à jour. Un plugin “inutile” peut devenir critique s’il expose une route ou ajoute un endpoint mal protégé.

Pareil côté serveur. Vérifiez l’existant: droits sur les dossiers, existence de fichiers temporaires qui traînent, configuration .htaccess, et gestion des erreurs. La sécurité passe souvent par une simple réduction de surface, supprimer ce qui n’est pas nécessaire.

Audit WordPress côté application: versions, droits, sécurité interne

La base de WordPress doit être à jour autant que possible. Une version trop ancienne augmente le risque de vulnérabilités connues, mais attention à l’excès: mettre à jour en aveugle un site hérité peut provoquer une régression. La bonne approche, c’est de tester avant, et de suivre la cohérence: WordPress, thème, plugins, PHP.

Ensuite, examinez l’accès et les rôles. WordPress a une notion claire de capacités, mais dans les projets réels, on finit par “sur-donner”. Un auteur qui gère le contenu n’a aucune raison d’avoir les droits d’installation de plugins. Un rôle trop permissif élargit le rayon d’action si un compte est compromis.

Je fais aussi une vérification sur la page de connexion et la gestion de sessions. Le but n’est pas d’empiler dix sécurités différentes, mais de s’assurer que:

les tentatives échouées sont freinées, le mot de passe est forcé “correctement”, les sessions sont cohérentes entre environnements, et la remontée de logs est utilisable.

Checklist d’audit avant déploiement (version courte)

Voici la première passe que je fais avant de valider un déploiement. Elle ne remplace pas les tests, elle les prépare en évitant les oublis typiques.

Vérifier versions: WordPress, plugins, thème, PHP et base de données, puis tester la mise à jour en staging Contrôler les comptes: rôles, suppression des comptes inutilisés, mots de passe uniques, revue des sessions Nettoyer l’empreinte: désactiver et supprimer les plugins non utilisés, nettoyer les thèmes obsolètes Mettre en place des sauvegardes vérifiées: test de restauration, politique de rétention, accès aux instantanés Vérifier la surface serveur: permissions fichiers, règles web (accès fichiers sensibles), et logs exploitables

Si une seule de ces lignes tombe à zéro, je bloque le déploiement ou je l’encadre avec un plan de correction daté.

Durcir la configuration serveur: le vrai nerf de la guerre

La plupart des attaques ne “cassent” pas WordPress lui-même au départ. Elles utilisent ce que le serveur laisse accessible. C’est pour ça qu’un bon audit inclut l’infrastructure, même légère.

Permissions et fichiers sensibles

Assurez-vous que le dossier d’upload n’est pas en écriture excessive côté mauvais répertoires. En pratique, on observe souvent:

des permissions trop ouvertes, des répertoires dont les droits ne suivent pas la logique d’exécution, ou des traces de déploiements précédents (fichiers de cache, exports, backup dans un répertoire accessible).

Le point clé est l’accès. Tout ce qui est “données” doit être séparé de ce qui est “code”. En cas d’hébergement mutualisé, la marge de manœuvre dépend de votre fournisseur, mais vous pouvez presque toujours vérifier au minimum l’existence de fichiers exposés.

Règles web et protection des endpoints

Que vous soyez en Apache ou Nginx, vérifiez que les fichiers sensibles ne sont pas servis. Par exemple, certains fichiers de configuration ou de métadonnées ne doivent pas être accessibles publiquement. En plus, si vous utilisez un fichier .htaccess, examinez-le comme un produit: une règle obsolète peut ouvrir un accès inattendu, surtout après une migration.

Headers HTTP utiles

Les en-têtes de sécurité ne remplacent pas le durcissement applicatif, mais ils comblent des angles. Pensez à l’anti-clickjacking, au contrôle de type de contenu, et à la gestion de la politique de script si vous l’adoptez. Attention toutefois, une Content Security Policy mal configurée peut casser des fonctionnalités (widgets, scripts tiers). Je préfère une politique progressive, testée page par page.

Gestion des mots de passe et des comptes: là où tout se joue

Un site “parfait techniquement” peut s’écrouler sur un compte admin qui utilise un mot de passe réutilisé. L’approche la plus efficace reste la combinaison de bonnes pratiques et de contrôles concrets.

Forcer des mots de passe uniques, activer une authentification à second facteur quand c’est possible, et limiter le nombre de comptes ayant des droits élevés. J’insiste aussi sur la suppression des comptes inactifs et sur la revue des rôles après chaque nouvelle phase projet, notamment quand des prestataires interviennent.

Un autre point souvent oublié: la répartition des accès entre staging et production. Les tentatives de connexion et les erreurs ne se valent pas, et vous ne voulez pas que des identifiants de staging soient réutilisés sur prod “pour aller plus vite”.

Plugins et dépendances: réduire sans casser

Les plugins sont la variable la plus risquée. Ils touchent aux formulaires, aux endpoints, à l’upload, parfois aux thèmes et aux pages d’admin. Le problème n’est pas “les plugins en soi”, c’est le manque de contrôle sur leur qualité et leur cycle de vie.

Dans un audit, je commence par une question simple: qu’est-ce qui est vraiment utilisé au quotidien? Un plugin “utile une fois” peut être remplacé par une procédure manuelle. Un plugin “multi-usage” peut être surdimensionné et introduire un comportement non maîtrisé.

Le piège, c’est la suppression brutale. Si vous retirez un plugin, vérifiez:

les shortcodes utilisés dans le contenu, les pages liées à la logique plugin, les hooks et options en base, et les tâches programmées (WP-Cron) liées.

Je recommande un plan de remplacement. Si un plugin remplace un service externe, assurez-vous que le service a une sortie propre avant de supprimer la brique WordPress.

Sauvegardes: qualité de restauration, pas seulement présence d’un fichier

La sauvegarde est utile seulement si on sait la restaurer. J’ai déjà vu des sauvegardes “fonctionner” dans le sens où elles s’exécutent, mais échouer lors de la restauration. Typiquement, la base n’est pas cohérente avec les fichiers, ou bien le restore produit un site qui démarre en boucle d’erreurs.

Votre audit doit inclure un test de restauration sur un environnement isolé. Idéalement, testez:

un restore complet, un restore base uniquement, et une vérification de cohérence des médias (uploads).

La politique de rétention dépend de vos contraintes, mais je conseille au minimum une logique claire, et des logs qui prouvent que les sauvegardes ont eu lieu. Si votre hébergeur fournit un système d’instantanés, vérifiez quand et comment l’instantané capture les fichiers et la base.

Sécurité du trafic: HTTPS, reverse proxy, WAF et limites

Le HTTPS est non négociable. Au-delà de “chiffrer”, il évite une partie des interceptions et renforce la discipline de session. Si vous avez un reverse proxy ou un load balancer, vérifiez les paramètres liés au schéma (X-Forwarded-Proto) et aux cookies. Une config mal réglée peut entraîner des redirections instables, et parfois des soucis de session.

Un WAF ou une protection front peut être un excellent complément, surtout contre les attaques opportunistes. Mais attention au faux sentiment de sécurité. Un WAF mal paramétré peut bloquer des endpoints légitimes, ou laisser passer des patterns. Le bon usage, c’est de combiner une protection front et une hygiène interne.

Si vous ne déployez pas de WAF, au minimum, surveillez les logs et limitez les abus côté application, comme les tentatives de login et les patterns d’upload.

Logs et monitoring: savoir quand agir, pas seulement “avoir des fichiers”

Sans logs exploitables, la sécurité devient une loterie. Vous voulez pouvoir répondre à des questions simples:

Quel compte a échoué, et combien de fois? Quel endpoint a été visé? Quand un changement a été déployé? Quels fichiers ont été modifiés récemment?

Sur WordPress, activez une journalisation adaptée. Dans les projets sérieux, je préfère une configuration où les logs sont consultables sans exposer des informations sensibles à l’extérieur. Si vous avez un SIEM ou au minimum des outils de collecte, c’est encore mieux.

En pratique, prévoyez un cycle: vérification hebdomadaire en temps normal, procédure d’alerte en cas d’anomalie, et canal de remontée clair. La sécurité n’est pas un bouton, c’est un comportement.

Contrôle d’intégrité: repérer les changements inattendus

Les attaques par modification de fichiers tentent souvent de rester discrètes. Un audit utile consiste à détecter les modifications anormales entre deux états connus.

Vous pouvez mettre en place une vérification d’intégrité via des outils qui comparent les hashes des fichiers, ou via des mécanismes fournis par votre hébergeur ou votre CI/CD. Le point important n’est pas l’outil exact, mais la discipline:

avoir un état “référence” identifié, comparer après chaque déploiement, et déclencher une alerte quand des fichiers hors périmètre changent.

Si vous déployez avec un pipeline, vous pouvez aussi enregistrer la liste des fichiers attendus. Ce contrôle transforme un doute en signal actionnable.

Durcissement progressif: gagner en sécurité sans casser l’existant

Il existe une tentation fréquente: activer tout ce qui ressemble à “security” dans un plugin, ou empiler des règles sur le serveur. Le résultat peut être une instabilité difficile à diagnostiquer.

Une stratégie plus saine consiste à avancer par paliers. D’abord, https://gardewp.fr/securite-wordpress/ correction des bases: mises à jour, rôles, surface réduite, sauvegardes testées. Ensuite, protections plus spécifiques: limitations de login, durcissement headers, politiques front. Enfin, règles avancées, uniquement après avoir compris l’impact sur vos fonctionnalités.

Un exemple concret: activer une politique de blocage d’uploads selon le type de fichier peut empêcher certains workflows légitimes si votre équipe utilise des formats non prévus. J’ai vu des sites qui reposaient sur des fichiers PDF et des images, puis qui avaient des besoins ponctuels d’autres formats, sans que personne ne l’ait documenté. Mieux vaut définir une politique claire, et prévoir une procédure exceptionnelle encadrée.

Exemple de scénario d’audit réel, et comment on tranche

Sur un site WordPress multi-langue, le plugin de traduction ajoutait des règles de redirection et des endpoints d’admin. Lors de la mise à jour, la sécurité “globale” augmentait avec plusieurs modules complémentaires, mais l’une des options cassait un flux de synchronisation.

Le diagnostic a été simple après une bonne préparation: l’équipe avait documenté les versions, et les changements étaient identifiés dans le pipeline. On n’a pas cherché “le plugin parfait”. On a choisi le plugin le plus fiable pour le besoin, puis on a durci autour, en gardant une configuration stable. C’est un bon rappel: la sécurité n’est pas un score, c’est une combinaison qui tient dans la durée.

Procédure de déploiement sécurisé: réduire le risque pendant le changement

La mise en production est un moment à risque. Beaucoup d’incidents arrivent “autour du déploiement”, pas des jours après. Quand on déploie, on change des fichiers, des dépendances, des permissions, parfois des règles de proxy.

Je conseille un déroulé clair:

déployer en staging avec la même configuration de variables que prod, exécuter des tests de base (connexion admin, création d’un brouillon, upload de média, affichage des pages critiques), vérifier l’intégrité des fichiers après le déploiement, puis basculer.

Et surtout, gardez un plan de rollback. Pas un rollback “imaginaire”. Un plan concret, avec un instantané restaurable ou une procédure documentée.

Checklist finale avant “ouvrir au public”

Une fois l’audit terminé, il reste une étape de validation opérationnelle. C’est souvent la différence entre “site sécurisé” et “site sécurisé et stable”.

Voici les derniers points que je valide, sans discuter.

Tester des fonctionnalités critiques avec un compte non privilégié, puis avec un compte admin (connexion, édition, publication, médias) Vérifier les sauvegardes en pratique, avec un restore testé, pas une simple exécution planifiée Contrôler l’accès aux zones sensibles, et vérifier que les rôles ne sur-donnent pas des capacités Confirmer la traçabilité: logs actifs, canal d’alerte, et capacité à répondre en cas d’anomalie

Si une ligne n’est pas validée, on garde le déploiement derrière un mode maintenace ou on limite l’accès, le temps de corriger.

Pièges fréquents à éviter (ceux qui reviennent tout le temps)

Dans les audits, certains schémas reviennent. Ce ne sont pas des “théories”, ce sont des retours terrain.

Le premier piège est le mélange staging et production. Identifiants différents, logs différents, et parfois des plugins activés différemment. Le risque, c’est d’avoir des comportements qui changent sans qu’on comprenne pourquoi.

Le deuxième piège est la dépendance à un plugin “central” sans plan de sortie. Si ce plugin tombe en panne, si l’éditeur arrête le développement, ou si une mise à jour introduit une régression, vous serez coincés. Toujours prévoir la possibilité de remplacer ou de retirer.

Le troisième piège est de considérer la sécurité comme un projet ponctuel. En réalité, la sécurité WordPress est un cycle: mises à jour, revue des droits, nettoyage de plugins, contrôle des logs, et vérification de restauration. Sans cadence, la sécurité dérive.

Une question de méthode: qui fait l’audit, et avec quel objectif

Enfin, une remarque qui évite beaucoup de confusion. Un audit interne par un développeur, un audit par un prestataire, ou un auto-audit ne visent pas exactement les mêmes livrables.

Si vous faites l’audit en interne, l’objectif doit être une action planifiée, avec tests et validation fonctionnelle. Si vous faites appel à un tiers, demandez un rapport exploitable: périmètre, preuves, risques classés, recommandations avec impact. Pas seulement des slogans.

Et dans tous les cas, gardez en tête que l’objectif n’est pas de rendre WordPress invulnérable. Il est de réduire fortement les chances d’incident, puis de vous donner une capacité de réaction rapide.

Si vous préparez un déploiement prochain et que vous voulez rendre cette checklist vraiment utile, la prochaine étape consiste à choisir votre “base de départ” (staging conforme, versions cohérentes, sauvegardes testées) et à traiter chaque point comme un ticket avec statut. L’audit et sécurisation WordPress devient alors une méthode, pas une opération ponctuelle.