Sécurité WordPress : maîtriser les accès et contenir un incident

9 min de lecture

La sécurité WordPress commence par une question concrète : qui peut modifier votre site et récupérer ses accès ? Un rédacteur peut avoir des droits adaptés aux contenus tandis qu’un ancien prestataire conserve un accès puissant à l’hébergement. Organisez les comptes, vérifiez leurs permissions réelles et préparez le confinement d’un incident avant tout nettoyage.

Priorité : des accès nominatifs et limités, une récupération maîtrisée et une double authentification lorsque le service la supporte. En cas d’alerte, préservez les traces et bloquez les accès suspects avant de réparer. Le registre et la fiche ci-dessous structurent ces décisions.

Identifier tous les chemins d’accès et de récupération

La documentation WordPress inclut la sécurité de l’environnement d’hébergement, pas seulement celle de l’application.^[4] Commencez donc par cartographier les accès directs et les chemins de récupération.

Recueillez les titulaires des comptes WordPress, de l’hébergement, des accès aux fichiers, de la base de données, du gestionnaire de domaine et de la messagerie de réinitialisation. Ajoutez les comptes techniques, intégrations et mots de passe d’application lorsqu’ils existent. Pour chacun, notez le décideur, le détenteur réel et le moyen de récupération.

Une adresse de contact ne suffit pas : vérifiez qui contrôle effectivement la boîte et peut solliciter le fournisseur. Changer un mot de passe WordPress ne constitue pas un contrôle des accès au domaine ou à l’hébergement.

Désignez une personne habilitée à demander un blocage à l’hébergeur, avec un relais en cas d’absence. Conservez ces coordonnées hors du site, dans un espace protégé.

Régler les droits WordPress selon les tâches réelles

Un rôle est un ensemble de capacités, ou capabilities, c’est-à-dire de permissions. Votre règle de travail doit rester l’octroi des seules capacités nécessaires aux tâches confiées, conformément à la documentation WordPress.^[5]

Distinguez rédaction, publication, modification des contenus d’autrui et administration technique. Le rôle Éditeur peut publier et gérer les articles d’autres utilisateurs : il ne convient donc pas automatiquement à un rédacteur chargé de préparer ses propres contenus.^[5] Si un rôle personnalisé est nécessaire, faites vérifier ses capacités plutôt que copier un script trouvé en ligne.

Testez avec le compte concerné : création d’un brouillon autorisée, publication refusée si elle n’est pas prévue, accès à la gestion des extensions refusé. Un menu masqué ne remplace pas ce contrôle des actions.

Pour la validation, notez le compte testé, la tâche, le refus ou l’autorisation observés et le contrôleur. Refaites le test après une modification de rôle ou une extension qui change les permissions.

L’accès à l’éditeur de site dépend notamment de edit_theme_options, dont la portée dépasse cette seule interface.^[5] Ne l’ajoutez pas pour résoudre rapidement un blocage de rédaction.

Sécurité WordPress : fermer les accès oubliés et tester la 2FA

Privilégiez les comptes nominatifs : chaque accès doit avoir un titulaire identifiable, sans partage d’un compte administrateur. Lors d’un départ, vérifiez séparément WordPress, l’hébergement, les accès aux fichiers et les intégrations.

Pour les accès sensibles, recherchez une double authentification effectivement supportée par le service, une extension compatible ou votre fournisseur d’identité. Ne présumez pas qu’elle soit native ou active. Vérifiez son fonctionnement sur le parcours de connexion réellement utilisé, puis contrôlez les autres voies d’accès.

Préparez la récupération avant de l’imposer : personne autorisée, codes de secours conservés séparément des identifiants, méthode alternative documentée et test avec un compte autorisé. Ces secrets ne vont pas dans le registre.

Pour chaque accès automatisé, relevez la méthode d’authentification et le secret associé, sans recopier ce secret. Faites confirmer sa procédure de suspension et ses dépendances. Le test d’un parcours de connexion ne doit pas être utilisé comme preuve pour tous les autres.

À la fin d’un contrat, retirez les accès inutiles et révoquez les sessions ou jetons concernés lorsque l’outil le permet. Changez les secrets partagés ; le changement du seul mot de passe principal ne prouve pas une révocation complète.

Inventorier les composants et rendre les journaux exploitables

WordPress recommande de tenir à jour le cœur du logiciel ainsi que tous les thèmes et extensions installés, et de choisir des composants qui reçoivent encore des mises à jour.^[4]

Inventoriez chaque composant avec sa version, son origine, son usage, son responsable et son état actif ou inactif. Vérifiez les dépendances avant un retrait. La désactivation n’est pas une validation de sécurité. Préparez sauvegarde restaurable et tests fonctionnels selon la démarche de maintenance du site et de contrôle des sauvegardes.

Repérez ensuite les journaux réellement disponibles : connexions, administration, hébergement et messagerie selon les outils. L’absence d’entrée ne prouve rien si la journalisation n’était pas activée ou si les traces ont expiré.

Conservez les exports dans un espace séparé à accès limité, avec leur origine, horodatage et fuseau. Gardez les originaux ; travaillez sur des copies. Définissez une conservation adaptée à l’enquête et aux données présentes, sans publier de journaux contenant des secrets ou des informations personnelles.

Un registre d’accès minimal renseigné pour décider

Exemple fictif, sans référence à un client de 4SYSTEM : Camille prépare des articles ; Julien, ancien prestataire, conserve un accès à l’hébergement. Léa est responsable du site. Le registre distingue décisions et preuves attendues : il ne décrit pas des contrôles déjà réussis.

Ajoutez date de revue, échéance des accès temporaires et référence des preuves. Utilisez des statuts explicites : demandé, révoqué, vérifié. Une demande n’équivaut pas à une révocation confirmée. Gardez mots de passe, clés privées et codes de secours hors de ce tableau.

Confinement : intervenir dans le bon ordre

Traitez comme des alertes un compte administrateur inconnu, une redirection non prévue, une modification inexpliquée de fichiers ou un envoi inhabituel depuis la messagerie. Ces signes appellent une vérification ; ils ne prouvent pas, seuls, l’origine de l’incident.

1. Reprendre un canal fiable. Contactez l’hébergeur par ses coordonnées connues et utilisez un poste de confiance. Ne vous fiez pas uniquement aux messages affichés par le site suspect.
2. Préserver ce qui est disponible. Exportez les traces et relevez comptes, fichiers et chronologie avant les modifications. Si l’abus continue, ne retardez pas le blocage : demandez une préservation parallèle à l’hébergeur.
3. Contenir l’accès. Faites isoler le site ou restreindre son exposition au niveau approprié. Une page de maintenance affichée par WordPress ne démontre pas que les accès techniques sont bloqués.
4. Sécuriser la récupération. Contrôlez hébergement, messagerie et domaine ; révoquez les accès suspects et renouvelez les secrets exposés depuis un environnement fiable.
5. Diagnostiquer puis réparer. Travaillez sur une copie lorsque possible. Ne supprimez pas des fichiers au hasard et n’exécutez pas de script non examiné : vous pourriez détruire des preuves ou aggraver l’arrêt.

Une fiche de confinement et des preuves de reprise

Dans le même exemple fictif, un administrateur non reconnu apparaît. La présence de Julien dans le registre n’établit pas sa responsabilité. La fiche suivante sert à piloter les actions, pas à déclarer l’incident résolu.

• Signal : compte inconnu repéré dans l’administration ; origine non déterminée.
• Pilote : Léa décide ; l’hébergeur prend en charge l’isolement technique.
• Périmètre à vérifier : WordPress, accès hébergement de Julien, récupération par messagerie et domaine.
• Preuves à conserver : liste des comptes, exports disponibles, captures et chronologie horodatée ; stockage protégé hors du site.
• Confinement décidé : demander l’isolement, retirer l’accès résiduel de Julien, contrôler les autres comptes privilégiés.
• Réparation autorisée après diagnostic : traiter l’entrée identifiée, choisir une restauration vérifiée ou une reconstruction, puis renouveler les secrets concernés.
• Validation attendue : tests des fonctions essentielles, permissions autorisées et refusées, récupération et contrôle des traces disponibles.

Une sauvegarde doit être examinée avant restauration : son existence ne prouve pas qu’elle précède la compromission. Consignez les changements, les tests et l’autorisation de remise en service. Un affichage normal ne démontre pas l’éradication.

Si le point d’entrée demeure inconnu, ne présentez pas la restauration comme une correction suffisante. Maintenez les restrictions nécessaires et faites examiner les voies d’accès encore possibles. La personne qui autorise la reprise doit connaître les incertitudes restantes.

Si des données personnelles semblent exposées, transmettez au responsable du traitement les catégories concernées, la période suspecte et les accès possibles pour qualifier les obligations de notification applicables. Le retour du site ne tranche pas cette question.

Questions fréquentes

Que faire si le domaine est au nom du prestataire ?

Ne tentez pas de contourner le compte du titulaire. Réunissez le contrat, les justificatifs disponibles et les informations du bureau d’enregistrement. Demandez la procédure applicable pour rétablir une gestion autorisée ou organiser le transfert. Distinguez le litige de titularité de l’urgence technique : l’hébergeur peut examiner des mesures de protection du site indépendamment du transfert du domaine.

Comment intervenir si la 2FA vous bloque ?

Utilisez le moyen de récupération prévu par le service ou sollicitez son assistance depuis un canal vérifié. Si une extension fournit le second facteur, faites identifier sa procédure de secours avant toute modification technique. Évitez de désactiver globalement la protection pour tous les utilisateurs. Après récupération, contrôlez les sessions et régénérez les moyens de secours concernés.

Un administrateur multisite peut-il tout corriger ?

Pas nécessairement : les capacités d’administration diffèrent entre une installation simple et un réseau multisite.^[5] Faites identifier les tâches bloquées et le compte habilité au niveau du réseau. Si l’extension ou la configuration concernée relève de ce niveau, l’administrateur local ne doit pas recevoir des droits supplémentaires par défaut. Adressez l’intervention au responsable compétent et documentez son périmètre.

Passer aux contrôles utiles

Commencez par identifier qui contrôle l’hébergement, le domaine et la messagerie, puis retirez un accès devenu inutile avec une preuve de révocation. Faites ensuite tester le compte de rédaction et la récupération administrateur. Si vous devez clarifier les responsabilités ou préparer une intervention encadrée, consultez les services de 4SYSTEM pour définir le périmètre nécessaire.

Sources

• Security : Advanced Administration Handbook | Developer.WordPress.org (consulté le 2026-10-08)
• Roles and Capabilities : Documentation : WordPress.org (consulté le 2026-10-08)