Hoe beschermt u /wp-admin/install.php in WordPress

Elke WordPress-installatie wordt geleverd met een bestand genaamd wp-admin/install.php. Op een gezonde site is het meestal onschadelijk. WordPress merkt dat de site al is opgezet en retourneert een korte "Already Installed"-pagina. Maar er is een randgeval dat veel site-eigenaren onderschatten. Op het moment dat er iets misgaat met de database, verandert datzelfde bestand in een volledig werkende installatiewizard. Een aanvaller die er op het juiste moment op stuit, kan WordPress opnieuw installeren bovenop uw domein, het laten verwijzen naar een database die hij beheert, en weglopen met een complete overname.

Deze gids legt uit wanneer install.php daadwerkelijk gevaarlijk is, welke beveiligings-plug-ins dit geval echt dekken (niet alle, ondanks wat hun marketing suggereert), en hoe u het bestand correct blokkeert. Dat omvat ook de minder comfortabele situatie waarin u op een shared host bent zonder toegang tot de serverconfiguratie.

Wanneer is install.php daadwerkelijk een probleem?

Als u https://uwdomein.com/wp-admin/install.php bezoekt op een gezonde site, controleert WordPress of de tabel wp_options al een siteurl bevat. Zo ja, dan toont het het scherm "Already Installed" en daar eindigt het verhaal. Geen formulier, geen actie, geen overname.

Het probleem begint op het moment dat WordPress die waarde niet kan lezen. Typische scenario's:

• Database-inloggegevens in wp-config.php zijn kapot gegaan (verkeerd wachtwoord na een hostmigratie, verkeerd getypte DB-naam).
• Iemand heeft de tabel wp_options verwijderd of geleegd, ofwel per ongeluk tijdens een migratie ofwel opzettelijk via een SQL-injectie in een kwetsbare plug-in.
• Een mislukte staging-kloon liet het bestandssysteem op zijn plaats, maar de database leeg.
• De databasegebruiker verloor rechten op specifieke tabellen.

In al deze gevallen wordt de installatiewizard beschikbaar voor iedereen op het internet. Wie het eerst bereikt, kan de admin-gebruikersnaam, wachtwoord en e-mail kiezen en bezit feitelijk het domein. Daarom bestaat deze controle in InspectWP, ook al is het bestand "normaal" op elke WordPress-installatie.

Welke beveiligings-plug-ins kunnen install.php daadwerkelijk beschermen?

Dit is het deel waarover mensen struikelen, dus het is de moeite waard om precies te zijn. De meeste mensen gaan ervan uit dat elke WordPress-beveiligings-plug-in automatisch install.php dekt. Dat is half waar. Het antwoord hangt volledig af van hoe de plug-in laadt.

Een normale WordPress-plug-in start binnen WordPress. Het heeft de database nodig om te starten. Als uw DB kapot of leeg is (wat het enige realistische scenario is waarin install.php gevaarlijk wordt), start WordPress nooit ver genoeg om de plug-in te laden. Het verzoek komt rechtstreeks bij install.php terecht en PHP rendert vrolijk de installatiewizard. Beveiligings-plug-ins die als normale plug-ins draaien, kunnen in die situatie per definitie niet helpen.

Echter, verschillende plug-ins gebruiken een PHP-mechanisme genaamd auto_prepend_file. Die instelling vertelt PHP om een specifiek bestand uit te voeren vóór elk ander PHP-script op de server. Wanneer een beveiligings-plug-in zich op deze manier registreert, draait het vóór wp-config.php, voordat de databaseverbinding zelfs maar wordt geprobeerd, en vóór install.php. Het heeft zijn eigen configuratiebestanden en, waar nodig, zijn eigen databaseverbinding. Een kapotte WordPress-installatie heeft er geen invloed op.

Plug-ins die deze modus ondersteunen (en daarom install.php kunnen beschermen, zelfs wanneer de WordPress-database niet werkt):

• Wordfence in Extended Protection-modus (soms Optimized Mode genoemd). Dit is niet de standaard na installatie. U moet het expliciet inschakelen in de Wordfence-firewallinstellingen. Eenmaal actief, wordt een bestand genaamd wordfence-waf.php in de WordPress-root geplaatst en geregistreerd via .htaccess, .user.ini of php.ini.
• NinjaFirewall (WP Edition). Gebruikt auto_prepend_file als standaardmodus. Het is zo geconfigureerd bij installatie, geen extra schakelaar nodig.
• NinjaFirewall (Pro / Full WAF). Hetzelfde mechanisme, maar geregistreerd op serverniveau. Draait volledig buiten WordPress.
• BitFire Security. Ondersteunt een "Always On Protection"-modus, ook gebaseerd op auto_prepend_file. Vergelijkbaar in gedrag met Wordfence Extended Protection.
• Shield Security (ShieldPRO). Laadt ook via auto_prepend_file, hoewel het een conservatievere aanpak heeft en .htaccess niet rechtstreeks wijzigt.
• MalCare. Gebruikt auto_prepend_file als onderdeel van zijn WAF-installatie.

Plug-ins die install.php niet kunnen blokkeren wanneer WordPress kapot is, omdat ze als normale WordPress-plug-ins draaien:

• Wordfence in de standaard Basic Mode (voordat u Extended Protection inschakelt).
• Solid Security (voorheen iThemes Security). Het levert geen WAF die vóór WordPress draait.
• All-In-One WP Security & Firewall. Goed in bestand- en login-hardening, maar draait binnen WordPress.
• De meeste op plug-ins gebaseerde firewalls die niet afhankelijk zijn van auto_prepend_file.

Een praktisch gevolg: als u Wordfence gebruikt, ga naar Wordfence, Firewall, Manage WAF en controleer of het bericht "Optimized" of "Extended Protection Enabled" leest. Als het nog steeds Basic Mode zegt, leidt de optimalisatiewizard u door het opzetten van auto_prepend_file voor uw server. Deze enkele wijziging is wat Wordfence van een reactieve plug-in verandert in een echte pre-WordPress-firewall.

Eén kanttekening voor beide paden. Het mechanisme vereist dat uw host auto_prepend_file daadwerkelijk toestaat via .htaccess, .user.ini of php.ini. Op de meeste shared hosts werkt dit out of the box. Op sommige vergrendelde managed hosts is de instelling beperkt, en de optimalisatiewizard zal stilletjes mislukken of een waarschuwing tonen. In dat geval bent u terug bij de webserver-regelbenadering die hieronder wordt beschreven.

Optie 1: Blokkeer install.php via .htaccess (Apache)

Als uw host Apache draait (wat het geval is bij de meerderheid van de shared-hostingproviders zoals IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost), kunt u het volgende blok toevoegen aan het .htaccess-bestand in uw WordPress-rootdirectory:

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

Dit werkt op Apache 2.4 en hoger, wat al jaren door vrijwel elke host wordt gebruikt. Als u op iets ouders zit (Apache 2.2), gebruik dan in plaats daarvan de oude syntaxis:

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

Plaats het fragment boven de marker # BEGIN WordPress, zodat het automatische rewrite-beheer van WordPress het tijdens updates niet aanraakt.

Bezoek na het opslaan van het bestand https://uwdomein.com/wp-admin/install.php in een privé-browservenster. U zou een 403 Forbidden-respons moeten zien. Als u nog steeds de "Already Installed"-pagina ziet, zijn .htaccess-overrides uitgeschakeld op uw host. Ga naar Optie 3.

Optie 2: Blokkeer install.php via nginx

Op nginx is er geen .htaccess. Als u uw eigen server beheert (VPS, dedicated of een flexibele host zoals Hetzner Cloud), voeg dit toe binnen het server-blok van uw site:

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

Herlaad nginx met sudo nginx -t && sudo systemctl reload nginx en test met curl -I https://uwdomein.com/wp-admin/install.php. U zou een 403 moeten krijgen.

Sommige managed hosts die nginx onder de motorkap gebruiken (zoals Raidboxes, Kinsta, WP Engine) leveren al dit soort regels mee. Het is de moeite waard om de documentatie van uw host te controleren of een supportticket te openen. Het antwoord is meestal ofwel "al gedekt" ofwel ze voegen de regel voor u toe.

Optie 3: Shared hosting zonder Apache-overrides

Als u op een shared nginx-host bent en .htaccess wordt genegeerd, heeft u minder opties, maar u zit niet vast. In volgorde van voorkeur:

1. Installeer een van de bovengenoemde pre-WordPress-firewalls. Op shared hosts waar auto_prepend_file is toegestaan, geeft een plug-in zoals NinjaFirewall of Wordfence in Extended Protection-modus u dezelfde bescherming als een serverregel, zonder enige serverconfiguratie aan te raken. Dit is vaak het meest pragmatische pad.
2. Vraag het uw host. De meeste managed WordPress-hosts voegen op verzoek een regel op serverniveau voor u toe. Het kost ze vijf minuten en ze doen het routinematig.
3. Vervang de inhoud van het bestand. U kunt wp-admin/install.php openen via SFTP en het hele bestand vervangen door een enkele regel:

   <?php // intentionally disabled, see install.php.bak

   Bewaar een back-up van het origineel (install.php.bak) buiten de openbare webroot voor het geval u ooit legitiem opnieuw moet installeren. Het nadeel: WordPress core-updates plaatsen het originele bestand terug, dus u moet de wijziging opnieuw toepassen na elke grote update. Een kleine must-use-plug-in kan dit automatiseren (zie het gerelateerde codefragment).
4. Weiger toegang via bestandsrechten. Het wijzigen van de bestandsmodus naar 000 via SFTP blokkeert ook toegang op de meeste hosts. Zelfde voorbehoud: core-updates zullen het resetten.

Wat met het hernoemen of verwijderen van install.php?

Technisch gezien kunt u install.php volledig verwijderen. WordPress heeft het niet nodig voor normale werking. Het wordt alleen gebruikt tijdens de initiële installatie en voor sommige interne upgrade-routines. Het probleem is dat het bestand wordt hersteld bij elke WordPress core-update, dus verwijderen is geen permanente oplossing. Het wordt ook af en toe gerefereerd door het automatische upgrade-proces, dus u kunt waarschuwingen in uw foutlog zien als het ontbreekt.

Hernoemen is nog erger. WordPress vindt het bestand niet onder zijn nieuwe naam, maar zal vrolijk het origineel opnieuw aanmaken tijdens de volgende update. U eindigt met twee kopieën.

Toegang blokkeren op webserverniveau, of via een pre-WordPress-firewall, is bijna altijd het betere antwoord.

Hoe verifieert u uw installatie

Nadat u een van de bovenstaande opties heeft toegepast:

1. Open https://uwdomein.com/wp-admin/install.php in een privé- of incognitovenster.
2. U zou een 403 Forbidden-pagina moeten zien (of 404 als u het bestand heeft verwijderd, of de aangepaste blokkeringspagina van de firewall als u de plug-in-route bent gegaan).
3. Als u de "Already Installed"-pagina ziet of, veel erger, een echt installatieformulier, is de regel niet actief. Dubbelcheck het bestandspad, wis eventuele caches (Cloudflare, Varnish, paginacache op serverniveau) en probeer opnieuw.
4. Voer een nieuwe InspectWP-scan uit. De controle "install.php blootgesteld" in het WordPress-gedeelte zou groen moeten worden.

Gerelateerde controles die de moeite waard zijn om uit te voeren

Terwijl u zaken vergrendelt, is het de moeite waard om hetzelfde soort blokkering op webserverniveau (of pre-WordPress-firewall-regel) toe te passen op een paar andere gevoelige eindpunten: xmlrpc.php (tenzij u het actief gebruikt), wp-config.php.bak, .git/, .env en eventuele phpinfo.php-bestanden die een ontwikkelaar mogelijk heeft achtergelaten. InspectWP signaleert deze allemaal automatisch in het beveiligingsgedeelte.

Het install.php-geval is een goed voorbeeld van defense in depth. WordPress beschermt zichzelf, een correct geconfigureerde beveiligings-plug-in voegt een extra laag toe, en een webserverregel dekt het ene scenario waarin beide kunnen falen. Kies welke combinatie ook bij uw host past. Vijf regels configuratie, of één schakelaar in een firewall-plug-in, is genoeg om het gat voorgoed te dichten.