Audit de sécurité WordPress : ce qu'un attaquant voit de votre site, et comment le fermer

Ce qu'une analyse de sécurité externe regarde vraiment

Le mot « sécurité » mélange deux choses : l'exposition, ce que votre site laisse lire à n'importe qui, et la compromission, un intrus déjà entré. Un scan externe mesure la première, qui est aussi le travail préparatoire des attaques automatisées : un robot trie les sites avant de s'acharner. Voici les portes que le moteur de wordpress-audit.com teste sur votre URL, avec l'identifiant du rapport et leur coût au score.

La version affichée et l'API REST comptent dans la dimension WordPress. Et un simple code 200 ne suffit jamais : le moteur lit le début de la réponse et exige la signature du vrai fichier, parce que beaucoup de sites répondent 200 à n'importe quelle adresse.

1. La version de WordPress affichée

Le risque concret. Quand une faille touche une version donnée de WordPress, les robots cherchent les sites qui tournent encore dessus, et la meta generator leur évite de deviner. Masquer la version ne corrige rien pour autant : un site à jour qui l'affiche risque peu, un site en retard qui la cache reste vulnérable.

Le vérifier vous-même. Le moteur regarde la page, puis le flux RSS :

curl -s https://votre-site.fr/ | grep -i 'name="generator"'
curl -s https://votre-site.fr/feed/ | grep -i '<generator>'

Un numéro après WordPress dans la première réponse, ou wordpress.org/?v= dans la seconde : la version est publique.

La correction. Dans une extension maison, ou dans le functions.php du thème enfant :

// Retire la version de la meta generator ET des flux RSS/Atom.
add_filter( 'the_generator', '__return_empty_string' );

Ce filtre couvre la meta de l'en-tête et les flux, là où le remove_action( 'wp_head', 'wp_generator' ) qu'on lit partout laisse la version dans /feed/. Reste une limite que le scan ne mesure pas : WordPress ajoute aussi sa version en ?ver= aux fichiers CSS et JS du cœur. La vraie réponse reste la mise à jour, et cette ligne ne coûte que 5 points.

2. XML-RPC ouvert

Le risque concret. xmlrpc.php est l'ancienne interface de publication à distance. Sa méthode system.multicall permet d'enchaîner de nombreuses tentatives de mot de passe dans une seule requête HTTP, ce qui échappe aux limiteurs qui comptent les requêtes. Les pingbacks, eux, peuvent faire envoyer par votre serveur des requêtes vers un tiers.

Le vérifier vous-même.

curl -i https://votre-site.fr/xmlrpc.php

Un 405 Method Not Allowed ou le texte XML-RPC server accepts POST requests only. : le point d'accès est ouvert, c'est ce que le moteur compte comme accessible. Un 403 ou un 404 : il est fermé.

Avant de fermer : Jetpack. Selon sa documentation, bloquer xmlrpc.php coupe la connexion entre votre site et WordPress.com (jetpack.com). Avec Jetpack, gardez-le ouvert, limitez les tentatives de connexion (section 7) et acceptez l'avertissement du rapport.

La correction. Sur Apache 2.4, dans le .htaccess à la racine, au-dessus du bloc # BEGIN WordPress :

<Files xmlrpc.php>
    Require all denied
</Files>

Sur nginx, dans le bloc server ; une correspondance exacte passe avant location ~ \.php$, quel que soit l'ordre :

location = /xmlrpc.php {
    deny all;
}

Sans toucher au serveur, l'extension Disable XML-RPC-API bloque le fichier par le .htaccess. Méfiez-vous en revanche du seul add_filter( 'xmlrpc_enabled', '__return_false' ) : d'après la documentation de WordPress, il ne désactive que les méthodes qui demandent une authentification, pas les pingbacks (developer.wordpress.org). Les tentatives de mot de passe échouent, mais le fichier répond toujours, et le rapport continuera de le signaler, à juste titre.

3. Les identifiants des auteurs : ?author=1 et /wp-json/wp/v2/users

Le risque concret. Sur une installation par défaut, le slug d'un auteur, celui de /author/…/, est dérivé de son identifiant de connexion : le publier, c'est donner la moitié de la paire. Le projet WordPress ne considère pas cela comme une faille, un identifiant servant à désigner quelqu'un et non à l'authentifier (make.wordpress.org). Les deux positions se tiennent : avec des mots de passe solides et la double authentification, l'enjeu est faible ; avec un compte admin au mot de passe de 2015, il ne l'est pas.

Le vérifier vous-même.

curl -sI "https://votre-site.fr/?author=1" | grep -i '^location'
curl -s https://votre-site.fr/wp-json/wp/v2/users | head -c 400

Une ligne Location: https://votre-site.fr/author/jean-dupont/, ou un tableau JSON avec des champs "slug" : vos identifiants sont lisibles. Le moteur teste ces deux adresses : −5 en sécurité pour la première, −10 dans la dimension WordPress pour la seconde, qui livre tous les auteurs d'un coup.

Par extension. Stop User Enumeration bloque les requêtes ?author= et, en option, la liste de l'API REST pour les visiteurs non connectés, l'auteur des réponses oEmbed et le plan de site des auteurs.

Dans le code, via une extension maison ou le functions.php du thème enfant :

// 1. L'API REST ne liste plus les comptes aux visiteurs non connectés.
add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
} );

// 2. ?author=N renvoie vers l'accueil au lieu de révéler /author/identifiant/.
//    Priorité 1 : avant redirect_canonical(), accrochée en priorité 10.
add_action( 'template_redirect', function () {
    if ( isset( $_GET['author'] ) && ! is_user_logged_in() ) {
        wp_safe_redirect( home_url( '/' ), 301 );
        exit;
    }
}, 1 );

// 3. Le plan de site natif ne publie plus la liste des auteurs.
add_filter( 'wp_sitemaps_add_provider', function ( $provider, $name ) {
    return 'users' === $name ? false : $provider;
}, 10, 2 );

Le premier filtre agit sur les routes elles-mêmes : il couvre aussi la forme /?rest_route=/wp/v2/users, qu'une règle sur /wp-json/ laisserait passer, et l'éditeur de blocs, utilisé connecté, continue de fonctionner. Si Yoast ou Rank Math génère votre plan de site, c'est dans leurs réglages qu'on exclut les auteurs. Ne coupez pas l'API REST entière : l'éditeur, WooCommerce et bien des extensions en dépendent.

La limite. Si votre thème affiche « Par Jean Dupont » avec un lien, le slug est dans votre HTML et aucun filtre n'y changera rien. La correction de fond consiste à dissocier slug et identifiant : wp user update 1 --user_nicename=redaction. L'adresse de la page d'auteur change ; redirigez l'ancienne si elle était indexée.

4. Les fichiers oubliés à la racine

C'est la catégorie qui trouve de vraies fuites. Une copie wp-config.php.bak faite avant une migration, un .env déposé par un outil de déploiement, un debug.log activé pour un dépannage il y a deux ans : PHP ne les exécute pas, le serveur les sert donc en texte brut, identifiants de base de données compris. Le moteur teste 14 chemins parmi les plus fréquents, sans suivre les redirections, et ne compte un fichier que si son contenu correspond : une ligne define( 'DB_NAME'…, des erreurs PHP datées, un dossier réellement listé.

Le vérifier vous-même, en regardant ce qui revient et pas seulement le code HTTP :

curl -s https://votre-site.fr/wp-config.php.bak | head -n 5
curl -s -r 0-600 https://votre-site.fr/wp-content/debug.log
curl -s https://votre-site.fr/.git/config | head -n 3

Du PHP avec DB_PASSWORD, des lignes PHP Warning datées, une section [core] : le fichier est public. Votre page d'accueil ou votre page 404 : il ne l'est pas.

Si une copie de wp-config.php ou un .env était lisible, c'est un incident, pas un durcissement : supprimez le fichier, changez le mot de passe de la base dans le panneau de l'hébergeur puis dans wp-config.php, remplacez les clés et sels par un jeu neuf généré sur https://api.wordpress.org/secret-key/1.1/salt/ (toutes les sessions seront fermées), et renouvelez les clés d'API présentes dans le fichier.

Le journal de débogage. En production, WP_DEBUG reste à false. Si vous avez besoin du journal, WP_DEBUG_LOG accepte un chemin de fichier hors de la racine web (developer.wordpress.org) ; supprimez ensuite l'ancien wp-content/debug.log.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/votre-compte/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

readme.html, install.php, phpinfo.php. Inutile de supprimer readme.html et license.txt : chaque mise à jour du cœur les réinstalle, bloquez-les plutôt. install.php ne pose problème que s'il affiche le formulaire d'installation, sur une installation jamais terminée que n'importe qui pourrait finir avec sa propre base. phpinfo.php et info.php, eux, s'effacent.

La règle serveur. Sur Apache 2.4, dans le .htaccess, au-dessus de # BEGIN WordPress ; FilesMatch vaut aussi pour les sous-dossiers :

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php|debug\.log|error_log|\.env)$">
    Require all denied
</FilesMatch>
<FilesMatch "(\.(bak|old|save|orig|sql)|~)$">
    Require all denied
</FilesMatch>
RedirectMatch 404 /\.(git|svn)(/|$)

Sur nginx, dans le bloc server, avant location ~ \.php$, car nginx retient la première expression régulière qui correspond :

location ~* ^/(readme\.html|license\.txt|wp-config-sample\.php|debug\.log|error_log|\.env)$ { deny all; }
location ~* ^/wp-content/debug\.log$ { deny all; }
location ~* (\.(bak|old|save|orig|sql)|~)$ { deny all; }
location ~ /\.(git|svn) { deny all; }

Relancez les curl : vous devez obtenir 403 ou 404. Et gardez la limite en tête : le moteur teste des noms courants, pas site-complet-mars.zip. Une sauvegarde n'a rien à faire dans le dossier servi par le web.

5. Les répertoires dont le contenu s'affiche

Le risque concret. Un dossier sans fichier index, sur un serveur qui autorise le listage, affiche une page « Index of ». Sur /wp-content/plugins/, c'est l'inventaire de vos extensions. Sur /wp-content/uploads/, ce sont tous vos fichiers, y compris les PDF que vous pensiez privés parce qu'aucune page n'y renvoie.

Le vérifier vous-même. Ouvrez https://votre-site.fr/wp-content/uploads/, puis /wp-content/plugins/ et /wp-includes/. Une liste de dossiers : le listage est ouvert. Le moteur teste ces trois adresses et retire 10 points dès qu'une seule est listée.

La correction. Sur Apache, Options -Indexes en tête du .htaccess. Une erreur 500 juste après signifie que l'hébergeur n'autorise pas cette directive : retirez-la et demandez-lui de couper le listage. Sur nginx, cherchez un autoindex on; et remplacez-le par autoindex off;, qui est la valeur par défaut.

6. Les en-têtes HTTP : ce qui manque et ce qui est en trop

Les en-têtes sont les lignes que votre serveur envoie avant la page. Certains durcissent le comportement du navigateur, d'autres racontent votre infrastructure. Une commande les affiche tous : curl -sI https://votre-site.fr/.

HTTPS et HSTS

Un site servi en HTTP perd 30 points d'un coup, et c'est mérité : identifiants et cookies circulent en clair. Presque tous les hébergeurs installent un certificat Let's Encrypt en un clic. Ensuite, Strict-Transport-Security interdit au navigateur de revenir en HTTP ; son absence coûte 8 points. N'ajoutez includeSubDomains que si tous vos sous-domaines sont en HTTPS, et ne demandez pas l'inscription à la liste preload des navigateurs à la légère : en sortir prend des mois.

Les en-têtes de durcissement

Pour Cross-Origin-Opener-Policy, préférez same-origin-allow-popups : la valeur same-origin casse les fenêtres de paiement ou de connexion ouvertes en popup. Sur Apache (module mod_headers), dans le .htaccess :

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always unset X-Powered-By
    Header unset X-Powered-By
</IfModule>

Si mod_headers n'est pas chargé, le bloc <IfModule> est ignoré sans message : le site marche, rien n'est envoyé. On relance donc curl -sI après chaque modification. Sur nginx, dans le bloc server :

add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
server_tokens off;
fastcgi_hide_header X-Powered-By;

Attention : un bloc location qui contient sa propre directive add_header n'hérite plus d'aucun en-tête du bloc server. Encore une fois, curl tranche.

La Content-Security-Policy

C'est l'en-tête le plus utile contre l'injection de scripts et le plus délicat sur WordPress, où chaque extension charge des ressources depuis ses propres domaines. Publiez d'abord Content-Security-Policy-Report-Only, qui signale les violations dans la console sans rien bloquer, complétez pendant quelques jours, puis basculez. Une politique réduite à frame-ancestors 'self'; upgrade-insecure-requests fait passer la ligne du rapport et protège du clickjacking, mais ne bloque aucun script injecté : mieux que rien, pas une CSP.

Les en-têtes en trop

X-Powered-By: PHP/8.1.2 et Server: Apache/2.4.52 coûtent 4 points chacun. Aucune faille, juste un tri facilité pour qui cherche une version précise. Les lignes Header unset et fastcgi_hide_header ci-dessus retirent le premier ; la directive PHP expose_php = Off, elle, se règle dans le php.ini du serveur, pas dans un .user.ini. Le second se masque avec server_tokens off; sur nginx et ServerTokens Prod dans la configuration principale d'Apache, que seul l'hébergeur peut modifier sur un mutualisé.

7. La page de connexion

Le risque concret. /wp-login.php reçoit des tentatives de connexion automatiques en permanence. La page n'est pas une faille ; un mot de passe devinable, si.

Le vérifier vous-même. curl -s -o /dev/null -w "%{http_code}\n" https://votre-site.fr/wp-login.php renvoie 200 sur une installation standard. Le moteur le signale à titre d'information, sans retirer de point : pénaliser l'adresse par défaut reviendrait à récompenser le camouflage plutôt que la protection.

La correction, par ordre d'efficacité :

1. Des mots de passe longs et uniques, générés par un gestionnaire de mots de passe.
2. La double authentification, recommandée par le guide de durcissement officiel (developer.wordpress.org) : l'extension Two Factor, développée par des contributeurs de WordPress, ou Wordfence Login Security.
3. La limitation des tentatives : Limit Login Attempts Security protège wp-login.php et xmlrpc.php, utile si Jetpack vous impose de garder XML-RPC.
4. Renommer l'adresse avec WPS Hide Login, en dernier : des journaux plus calmes, pas une protection.

Ce qu'aucun scan externe ne voit

C'est pourtant là que se jouent la plupart des piratages que j'ai eu à nettoyer : une extension pas mise à jour, un mot de passe réutilisé, l'ancien compte d'un prestataire resté administrateur. Rien de cela ne se lit de l'extérieur, ni par notre moteur ni par un autre. Un score sécurité de 100 veut dire que votre site ne donne rien de facile à un robot, pas qu'il est sain.

Un mot sur les extensions de sécurité, puisque le rapport en parle : le moteur signale Wordfence, Sucuri, Solid Security, All-In-One WP Security ou Defender quand l'une d'elles charge un fichier sur la page, et ne retire aucun point sinon, car la plupart ne laissent aucune trace côté visiteur. Elles apportent pare-feu, limitation des connexions et analyse des fichiers ; elles ne remplacent ni les mises à jour ni les sauvegardes.

Si le site est déjà compromis (titres étrangers dans Google, redirections qui ne se déclenchent que sur mobile, alerte Problèmes de sécurité dans la Search Console), ne commencez pas par durcir : copie complète pour l'analyse, changement de tous les mots de passe, réinstallation du cœur et des extensions depuis les sources officielles, puis recherche de la porte d'entrée, sans quoi l'intrus reviendra par le même chemin.

Dans quel ordre corriger

Si tout est rouge, suivez le risque réel plutôt que les points du score :

1. HTTPS, s'il manque.
2. Les fichiers critiques exposés, puis mot de passe de la base et sels changés.
3. Mises à jour et comptes administrateurs, absents de tout rapport externe mais présents dans la plupart des piratages.
4. Double authentification et limitation des tentatives.
5. Le listage des répertoires, une ligne de configuration.
6. Les identifiants listables, puis XML-RPC si rien n'en dépend.
7. HSTS, X-Content-Type-Options, X-Frame-Options.
8. L'empreinte : version de WordPress, X-Powered-By, version du serveur.
9. La Content-Security-Policy, en mode rapport d'abord.

Après chaque étape, relancez l'analyse sur la même URL : c'est la seule preuve que la règle s'applique, et le moyen de voir tout de suite un en-tête qui disparaît derrière le cache.

Questions fréquentes