Vérifier son site WordPress après la livraison : deux contrôles simples

— Robin Gagliardi

Un site WordPress peut fonctionner parfaitement et malgré tout être mal préparé au jour où quelque chose se passe mal.

Deux vérifications simples permettent déjà d’éviter beaucoup de surprises :

  • savoir où sont réellement stockées les sauvegardes ;
  • vérifier ce que le site expose publiquement sur ses comptes utilisateurs.

Ce sont des contrôles rapides, sans compétence technique particulière, et ils méritent d’être faits juste après la livraison.

Pourquoi un site qui fonctionne peut quand même être fragile

Après une mise en ligne, on vérifie généralement ce qui se voit :

  • les pages ;
  • le formulaire ;
  • l’affichage mobile ;
  • les liens ;
  • éventuellement les performances.

Les défauts les plus gênants sont pourtant parfois invisibles.

Une sauvegarde peut exister mais être stockée au mauvais endroit.

Une extension de sécurité peut être installée mais mal configurée.

Un compte peut être correctement protégé tout en exposant publiquement certaines informations inutiles.

C’est ce qui rend ces contrôles intéressants : ils vérifient le réglage, pas seulement la présence de l’outil.

Premier contrôle : où sont stockées les sauvegardes ?

Une sauvegarde conservée uniquement sur le même hébergement que le site protège mal contre certaines situations.

Si l’hébergement devient inaccessible, si des fichiers sont supprimés ou si le compte d’hébergement est compromis, la sauvegarde peut être touchée en même temps que le site.

Sauvegarde stockée sur le même hébergement

L’idéal est donc de disposer d’au moins une copie hors de l’hébergement principal.

Par exemple :

  • stockage cloud ;
  • serveur distinct ;
  • espace de sauvegarde dédié ;
  • copie locale sécurisée.

Le point important n’est pas le service utilisé.

C’est la séparation.

Une sauvegarde visible n’est pas encore une sauvegarde fiable

Une liste d’archives datées donne une impression rassurante.

Mais tant qu’aucune restauration n’a été testée, on ne sait pas vraiment si elles sont exploitables.

Il peut manquer :

  • la base de données ;
  • certains médias ;
  • un fichier de configuration ;
  • une archive complète ;
  • un accès nécessaire à la restauration.

Une sauvegarde jamais restaurée reste une hypothèse.

Le test des sauvegardes

Dans WordPress, ouvrez les réglages de l’outil de sauvegarde et cherchez où les archives sont envoyées.

Situation Lecture
Sauvegarde uniquement sur le serveur du site Protection limitée
Copie envoyée vers un stockage extérieur Mieux
Copie extérieure + restauration déjà testée Situation la plus rassurante

Dans les cas que Bleupixel a vérifiés, les sauvegardes existaient bien mais restaient sur le même hébergement. Elles ont ensuite été déplacées vers un stockage externe, avec test de restauration sur au moins un site.

Et les sauvegardes de l’hébergeur ?

Elles sont utiles.

Mais il faut connaître leur durée de rétention et leur fonctionnement.

Une sauvegarde automatique sur quelques jours protège bien contre une erreur récente.

Elle protège moins contre un problème découvert tardivement.

Si une intrusion ou une mauvaise modification est présente depuis plusieurs semaines, toutes les copies récentes peuvent déjà contenir le problème.

C’est pour cela qu’une stratégie de sauvegarde ne se résume pas à « mon hébergeur fait des backups ».

Il faut savoir :

  • combien de temps ils sont conservés ;
  • ce qu’ils contiennent ;
  • comment les restaurer ;
  • et s’il existe une copie indépendante.

Second contrôle : ce que WordPress expose sur les comptes

WordPress peut rendre publiques certaines informations liées aux auteurs et aux comptes.

Ce n’est pas forcément une faille.

Mais cela peut donner à un attaquant une information qu’il n’avait pas besoin d’avoir.

Deux endroits sont faciles à vérifier :

  • les archives d’auteur ;
  • l’API REST WordPress.

Tester les archives d’auteur

Ajoutez /?author=1 à l’adresse du site.

Selon la configuration, WordPress peut rediriger vers une URL du type /author/nom/.

Ce nom peut correspondre au slug public du compte auteur.

Ce n’est pas nécessairement l’identifiant utilisé pour se connecter.

Mais cela montre bien que certaines informations de compte sont publiées par défaut.

Tester l’API WordPress

Vous pouvez également regarder /wp-json/wp/v2/users.

Selon les réglages du site, cette adresse peut exposer des informations sur les utilisateurs publiés.

Si c’est inutile pour le fonctionnement du site, il est raisonnable de limiter cette exposition.

L’objectif n’est pas de prétendre qu’un compte devient « sécurisé » parce que son slug est caché.

L’objectif est simplement de ne pas publier davantage d’informations que nécessaire.

Ce qu’il faut vraiment protéger sur les comptes

La priorité reste ailleurs :

  • mot de passe unique et long ;
  • double authentification ;
  • nombre limité de comptes administrateurs ;
  • comptes inutilisés supprimés ;
  • accès techniques fermés lorsqu’ils ne servent pas ;
  • mises à jour régulières.

La visibilité d’un nom d’auteur est un détail de durcissement.

La double authentification et la gestion des comptes sont des protections bien plus importantes.

Le cas observé par Bleupixel

Lors d’un contrôle de plusieurs sites clients, Bleupixel a constaté que certains exposaient des informations de compte alors que d’autres non, malgré l’utilisation de la même extension de sécurité.

La différence venait du réglage.

Identifiants WordPress publiés par trois sites

C’est un bon exemple de quelque chose qu’on retrouve souvent en maintenance : installer une extension ne signifie pas qu’elle est configurée correctement.

Pourquoi ce n’était pas une urgence

Dans les cas relevés, la double authentification était déjà active.

Cela change beaucoup la lecture du risque.

Même si une information de compte est visible, un attaquant doit encore franchir les autres protections.

C’est justement l’intérêt d’une sécurité en plusieurs couches :

  • identifiant ;
  • mot de passe ;
  • double authentification ;
  • limitations d’accès ;
  • surveillance.

Aucune couche ne suffit seule.

Les cinq questions à poser après livraison

  1. Où sont les sauvegardes ? Sur le même serveur ou ailleurs ?
  2. Une restauration a-t-elle déjà été testée ? Pas seulement une sauvegarde. Une vraie restauration.
  3. Quels comptes sont visibles publiquement ? Et est-ce nécessaire ?
  4. La double authentification est-elle activée ? Au minimum pour les comptes administrateurs.
  5. Qui reçoit les alertes ? Si le site tombe, qui le sait ?

Ces cinq questions donnent déjà une bonne idée de la qualité de la livraison.

Ce que ces deux tests ne couvrent pas

Ils ne remplacent pas un audit de sécurité.

Ils ne vérifient pas :

  • les mises à jour ;
  • la qualité du code ;
  • les extensions vulnérables ;
  • la configuration du serveur ;
  • les permissions ;
  • les journaux ;
  • les formulaires ;
  • la surveillance.

Ils donnent simplement deux points de contrôle faciles à comprendre et à vérifier.

Ces deux tests ne prétendent pas résoudre toute la sécurité WordPress en cinq minutes.

Et si le site n’avait plus WordPress ?

Pour un site vitrine simple, une autre approche consiste effectivement à réduire fortement la pile technique.

Un site statique peut fonctionner sans base de données de contenu, sans administration publique et sans extensions WordPress.

Cela supprime certains problèmes.

Mais pas tous : hébergement, formulaire, DNS, certificats, sauvegarde des sources et surveillance restent à suivre.

C’est donc une autre architecture, pas une absence totale de maintenance.

Questions fréquentes

Comment savoir si mon site est bien sauvegardé ?

Vérifiez deux choses :

  1. qu’une copie existe hors du serveur principal ;
  2. qu’une restauration a déjà été testée.

Si vous ne connaissez pas la réponse, il faut la demander.

Est-ce grave si mon nom d’auteur ou mon slug est visible ?

Pas nécessairement.

Ce n’est pas une vulnérabilité critique en soi.

Mais si cette information n’a aucune utilité, il peut être pertinent de la limiter.

La priorité reste un mot de passe solide et la double authentification.

Mon prestataire doit-il faire ces vérifications ?

Elles devraient idéalement faire partie de la livraison ou de la maintenance.

Au minimum, le client devrait savoir :

  • où sont les sauvegardes ;
  • comment elles sont restaurées ;
  • quels comptes existent ;
  • quelles protections sont actives.

Une extension de sécurité suffit-elle ?

Non.

Une extension peut aider, mais elle dépend de ses réglages et ne remplace ni les mises à jour, ni les sauvegardes, ni la double authentification.

Deux contrôles simples, pas une sécurité magique

Le principal enseignement est très simple : ne vérifiez pas seulement que les outils sont installés. Vérifiez ce qu’ils font réellement.

Une sauvegarde peut exister au mauvais endroit.

Une extension de sécurité peut être présente sans que les options utiles soient activées.

Un site peut fonctionner parfaitement tout en restant mal préparé au jour où quelque chose casse.

Bleupixel assure la création et la maintenance de sites internet depuis Buis-les-Baronnies, en Drôme et dans le Vaucluse.

Si vous avez un WordPress existant et que vous ne savez pas exactement où partent les sauvegardes, quels comptes sont exposés ou quelles protections sont actives, ce sont de bons premiers points à vérifier.