Comment protéger /wp-admin/install.php dans WordPress

Chaque installation WordPress livre un fichier nommé wp-admin/install.php. Sur un site sain, il est généralement inoffensif. WordPress remarque que le site est déjà configuré et renvoie une courte page « Déjà installé ». Mais il existe un cas particulier que de nombreux propriétaires de sites sous-estiment. Au moment où quelque chose ne va pas avec la base de données, ce même fichier se transforme en un assistant d'installation entièrement fonctionnel. Un attaquant qui tombe dessus au bon moment peut réinstaller WordPress par-dessus votre domaine, le pointer vers une base de données qu'il contrôle et s'en aller avec une prise de contrôle complète.

Ce guide explique quand install.php est réellement dangereux, quelles extensions de sécurité couvrent véritablement ce cas (toutes ne le font pas, malgré ce que leur marketing laisse entendre) et comment bloquer le fichier correctement. Cela inclut la situation moins confortable où vous êtes sur un hébergement mutualisé sans accès à la configuration du serveur.

Quand install.php pose-t-il réellement problème ?

Si vous visitez https://votredomaine.com/wp-admin/install.php sur un site sain, WordPress vérifie si la table wp_options contient déjà une siteurl. Si oui, il affiche l'écran « Déjà installé » et l'histoire s'arrête là. Pas de formulaire, pas d'action, pas de prise de contrôle.

Le problème commence dès que WordPress ne peut pas lire cette valeur. Scénarios typiques :

• Les identifiants de la base de données dans wp-config.php sont cassés (mauvais mot de passe après une migration d'hébergeur, nom de base de données mal saisi).
• Quelqu'un a supprimé ou tronqué la table wp_options, soit par accident lors d'une migration, soit délibérément via une injection SQL dans une extension vulnérable.
• Un clone de préproduction raté a laissé le système de fichiers en place mais la base de données vide.
• L'utilisateur de la base de données a perdu ses permissions sur des tables spécifiques.

Dans tous ces cas, l'assistant d'installation devient accessible à n'importe qui sur internet. Celui qui l'atteint en premier peut choisir le nom d'utilisateur, le mot de passe et l'e-mail de l'administrateur, et possède effectivement le domaine. C'est pourquoi cette vérification existe dans InspectWP même si le fichier est « normal » sur toute installation WordPress.

Quelles extensions de sécurité peuvent réellement protéger install.php ?

C'est la partie qui prête à confusion, il vaut donc la peine d'être précis. La plupart des gens supposent que toute extension de sécurité WordPress couvrira automatiquement install.php. C'est à moitié vrai. La réponse dépend entièrement de la manière dont l'extension se charge.

Une extension WordPress classique démarre à l'intérieur de WordPress. Elle a besoin de la base de données pour démarrer. Si votre base est cassée ou vide (ce qui est le seul scénario réaliste où install.php devient dangereux), WordPress ne démarre jamais assez loin pour charger l'extension. La requête arrive directement sur install.php et PHP affiche joyeusement l'assistant d'installation. Les extensions de sécurité qui s'exécutent comme des extensions normales ne peuvent pas aider dans cette situation, par définition.

Cependant, plusieurs extensions utilisent un mécanisme PHP appelé auto_prepend_file. Ce paramètre indique à PHP d'exécuter un fichier spécifique avant tout autre script PHP sur le serveur. Lorsqu'une extension de sécurité s'enregistre de cette manière, elle s'exécute avant wp-config.php, avant même que la connexion à la base de données ne soit tentée, et avant install.php. Elle dispose de ses propres fichiers de configuration et, si nécessaire, de sa propre connexion à la base de données. Une installation WordPress cassée ne l'affecte pas.

Extensions qui prennent en charge ce mode (et peuvent donc protéger install.php même lorsque la base de données WordPress est en panne) :

• Wordfence en mode Extended Protection (parfois appelé Optimized Mode). Ce n'est pas le mode par défaut après l'installation. Vous devez l'activer explicitement dans les paramètres du pare-feu Wordfence. Une fois actif, un fichier nommé wordfence-waf.php est placé à la racine de WordPress et enregistré via .htaccess, .user.ini ou php.ini.
• NinjaFirewall (WP Edition). Utilise auto_prepend_file comme mode par défaut. Configuré ainsi à l'installation, aucune bascule supplémentaire n'est nécessaire.
• NinjaFirewall (Pro / Full WAF). Même mécanisme, mais enregistré au niveau du serveur. S'exécute complètement en dehors de WordPress.
• BitFire Security. Prend en charge un mode « Always On Protection », également basé sur auto_prepend_file. Comportement comparable à Wordfence Extended Protection.
• Shield Security (ShieldPRO). Se charge également via auto_prepend_file, bien qu'elle adopte une approche plus conservatrice et ne modifie pas directement .htaccess.
• MalCare. Utilise auto_prepend_file dans le cadre de sa configuration WAF.

Extensions qui ne peuvent pas bloquer install.php lorsque WordPress est cassé, car elles s'exécutent comme des extensions WordPress normales :

• Wordfence dans le Basic Mode par défaut (avant que vous n'activiez Extended Protection).
• Solid Security (anciennement iThemes Security). N'embarque pas de WAF qui s'exécute avant WordPress.
• All-In-One WP Security & Firewall. Bonne pour le durcissement des fichiers et de la connexion, mais s'exécute à l'intérieur de WordPress.
• La plupart des pare-feu basés sur des extensions qui ne reposent pas sur auto_prepend_file.

Conséquence pratique : si vous utilisez Wordfence, allez dans Wordfence, Firewall, Manage WAF et vérifiez si le message indique « Optimized » ou « Extended Protection Enabled ». S'il indique encore Basic Mode, l'assistant d'optimisation vous guide pour configurer auto_prepend_file pour votre serveur. Ce simple changement transforme Wordfence d'une extension réactive en un véritable pare-feu pré-WordPress.

Une mise en garde pour les deux voies. Le mécanisme nécessite que votre hébergeur autorise réellement auto_prepend_file via .htaccess, .user.ini ou php.ini. Sur la plupart des hébergements mutualisés, cela fonctionne d'emblée. Sur certains hébergeurs gérés verrouillés, le paramètre est restreint, et l'assistant d'optimisation échouera silencieusement ou affichera un avertissement. Dans ce cas, vous revenez à l'approche par règle de serveur web décrite ci-dessous.

Option 1 : bloquer install.php via .htaccess (Apache)

Si votre hébergeur utilise Apache (ce qui est le cas de la majorité des fournisseurs d'hébergement mutualisé comme IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost), vous pouvez ajouter le bloc suivant au fichier .htaccess dans le répertoire racine de votre WordPress :

<Files "install.php">
  Require all denied
</Files>

Cela fonctionne sur Apache 2.4 et supérieur, ce qui correspond à pratiquement tous les hébergeurs depuis des années. Si vous êtes sur quelque chose de plus ancien (Apache 2.2), utilisez plutôt la syntaxe héritée :

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Placez l'extrait au-dessus du marqueur # BEGIN WordPress afin que la gestion automatique des réécritures de WordPress ne le touche pas lors des mises à jour.

Après avoir enregistré le fichier, visitez https://votredomaine.com/wp-admin/install.php dans une fenêtre de navigation privée. Vous devriez voir une réponse 403 Forbidden. Si vous voyez encore la page « Déjà installé », les surcharges .htaccess sont désactivées chez votre hébergeur. Passez à l'Option 3.

Option 2 : bloquer install.php via nginx

Sur nginx, il n'y a pas de .htaccess. Si vous gérez votre propre serveur (VPS, dédié ou un hébergeur flexible comme Hetzner Cloud), ajoutez ceci à l'intérieur du bloc server de votre site :

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Rechargez nginx avec sudo nginx -t && sudo systemctl reload nginx et testez avec curl -I https://votredomaine.com/wp-admin/install.php. Vous devriez obtenir un 403.

Certains hébergeurs gérés qui utilisent nginx en arrière-plan (comme Raidboxes, Kinsta, WP Engine) livrent déjà ce type de règle. Il vaut la peine de consulter la documentation de votre hébergeur ou d'ouvrir un ticket d'assistance. La réponse est généralement soit « déjà couvert », soit ils ajoutent la règle pour vous.

Option 3 : hébergement mutualisé sans surcharges Apache

Si vous êtes sur un hébergement mutualisé nginx et que .htaccess est ignoré, vous avez moins d'options mais vous n'êtes pas coincé. Par ordre de préférence :

1. Installez l'un des pare-feu pré-WordPress listés ci-dessus. Sur les hébergements mutualisés où auto_prepend_file est autorisé, une extension comme NinjaFirewall ou Wordfence en mode Extended Protection vous donne la même protection qu'une règle de serveur, sans toucher à aucune configuration serveur. C'est souvent la voie la plus pragmatique.
2. Demandez à votre hébergeur. La plupart des hébergeurs WordPress gérés ajouteront une règle au niveau du serveur pour vous si vous le demandez. Cela leur prend cinq minutes et ils le font régulièrement.
3. Remplacez le contenu du fichier. Vous pouvez ouvrir wp-admin/install.php via SFTP et remplacer l'intégralité du fichier par une seule ligne :

   <?php // intentionnellement désactivé, voir install.php.bak

   Conservez une sauvegarde de l'original (install.php.bak) en dehors de la racine web publique au cas où vous auriez légitimement besoin de réinstaller un jour. Inconvénient : les mises à jour du noyau WordPress remettront le fichier original en place, vous devrez donc réappliquer le changement après chaque mise à jour majeure. Une petite extension must-use peut automatiser cela (voir l'extrait de code associé).
4. Refus par permissions de fichier. Changer le mode du fichier en 000 via SFTP bloque également l'accès sur la plupart des hébergeurs. Même mise en garde : les mises à jour du noyau le réinitialiseront.

Et le renommage ou la suppression de install.php ?

Techniquement, vous pouvez supprimer entièrement install.php. WordPress n'en a pas besoin pour le fonctionnement normal. Il n'est utilisé que lors de la configuration initiale et pour certaines routines de mise à niveau internes. Le hic, c'est que le fichier est restauré à chaque mise à jour du noyau WordPress, donc la suppression n'est pas une solution permanente. Il est aussi parfois référencé par le processus de mise à niveau automatique, vous pouvez donc voir des avertissements dans votre journal d'erreurs s'il manque.

Le renommer est encore pire. WordPress ne trouvera pas le fichier sous son nouveau nom mais recréera joyeusement l'original lors de la prochaine mise à jour. Vous vous retrouvez avec deux copies.

Bloquer l'accès au niveau du serveur web, ou via un pare-feu pré-WordPress, est presque toujours la meilleure réponse.

Comment vérifier votre configuration

Après avoir appliqué l'une des options ci-dessus :

1. Ouvrez https://votredomaine.com/wp-admin/install.php dans une fenêtre privée ou de navigation incognito.
2. Vous devriez voir une page 403 Forbidden (ou 404 si vous avez supprimé le fichier, ou la page de blocage personnalisée du pare-feu si vous avez choisi la voie de l'extension).
3. Si vous voyez la page « Déjà installé » ou, bien pire, un véritable formulaire d'installation, la règle n'est pas active. Vérifiez le chemin du fichier, videz les caches éventuels (Cloudflare, Varnish, cache de page au niveau du serveur) et réessayez.
4. Lancez une nouvelle analyse InspectWP. La vérification « install.php exposé » dans la section WordPress devrait passer au vert.

Vérifications connexes valant la peine d'être effectuées

Pendant que vous verrouillez les choses, le même type de blocage au niveau du serveur web (ou règle de pare-feu pré-WordPress) vaut la peine d'être appliqué à quelques autres points sensibles : xmlrpc.php (sauf si vous l'utilisez activement), wp-config.php.bak, .git/, .env et tout fichier phpinfo.php qu'un développeur aurait pu laisser derrière lui. InspectWP signale automatiquement tous ceux-ci dans sa section sécurité.

Le cas install.php est un bon exemple de défense en profondeur. WordPress se protège lui-même, une extension de sécurité correctement configurée ajoute une autre couche, et une règle de serveur web couvre le seul scénario où ces deux peuvent échouer. Choisissez la combinaison qui correspond à votre hébergeur. Cinq lignes de configuration, ou une bascule dans une extension de pare-feu, suffisent pour combler la faille pour de bon.