readme.html en license.txt blokkeren in WordPress

Open een willekeurige WordPress-site ter wereld en voeg /readme.html aan de URL toe. In de overgrote meerderheid van de gevallen krijgt u een schone HTML-pagina te zien die in de kop trots de exacte WordPress-versie aankondigt. Hetzelfde geldt voor /license.txt, dat iets minder specifiek is maar nog steeds bevestigt dat de site op WordPress draait en een ruw idee geeft van hoe recent de installatie is.

Beide bestanden worden meegeleverd met WordPress core. Ze worden bij elke update opnieuw aangemaakt. Geen van beide is nodig om de site te laten functioneren. Het enige publiek dat ze realistisch gezien bedienen, zijn geautomatiseerde scanners die sites identificeren op basis van de coreversie, zodat ze het resultaat kunnen matchen met een lijst bekende kwetsbaarheden. Deze gids legt uit waarom dat in de praktijk uitmaakt en hoe u de bestanden netjes blokkeert op Apache, op nginx en op gedeelde hosting waar u minder directe controle hebt.

Waarom is het belangrijk dat readme.html bereikbaar is?

Het eerlijke antwoord is: op zichzelf niet erg veel. Het kennen van de WordPress-versie van een site is geen kwetsbaarheid. De versie van WordPress core is geen geheim, en een vastberaden aanvaller kan dit meestal toch wel achterhalen, bijvoorbeeld via generator-metatags, de versieparameter op ingeladen scripts en stijlen, of via de structuur van het REST API-antwoord.

Wat de situatie verandert, is de manier waarop exploitatie tegenwoordig op grote schaal werkt. Massale scanners kiezen geen doelwit en gaan dan op zoek naar bugs. Ze kiezen een CVE, bouwen een lijst op van elk domein op het internet dat een getroffen versie draait, en vuren de exploit op de hele lijst af. De goedkoopste manier om die lijst op te bouwen, is door readme.html op miljoenen domeinen parallel op te halen en de versie uit de kop te parsen. Alles wat de site onzichtbaar maakt voor die filterstap, haalt u uit de kandidatenlijst voordat de eigenlijke exploit ooit wordt uitgevoerd.

Het verwijderen van readme.html maakt de site dus niet veilig. Het verwijdert een van de goedkoopste vingerafdrukken, wat in de praktijk betekent dat u niet langer voorkomt op geautomatiseerde lijsten van "WordPress-sites die versie X.Y.Z draaien". Dat is een paar minuten werk waard, ook al is het niet de meest kritieke beveiligingshardening die u kunt uitvoeren.

Hoe zit het met license.txt en de andere corebestanden?

Hetzelfde type bestand, iets minder interessant:

• license.txt bevat de tekst van de GPL-licentie. Het bevat geen versienummer, maar het bestaan ervan in de WordPress-root is een sterk signaal dat de site op WordPress draait.
• wp-config-sample.php wordt met elke installatie meegeleverd. Het bevat geen inloggegevens, maar onthult dat niemand na de setup heeft opgeruimd.
• readme.html is degene met het probleem van versieonthulling.

De blokkeringsregel hieronder dekt alle drie in één keer. Er is geen goede reden om er een van publiekelijk bereikbaar te laten.

Optie 1: Blokkeren via .htaccess (Apache en LiteSpeed)

Als uw host op Apache of LiteSpeed draait (wat de meeste gedeelde hosters in de Duitstalige markt dekt: All Inkl, IONOS, Strato, DomainFactory, Hostinger en de meeste resellers), kunt u het volgende blok toevoegen aan het bestand .htaccess in uw WordPress-rootmap:

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Require all denied
</FilesMatch>

Het fragment gebruikt de syntaxis van Apache 2.4, wat elke host al jaren draait. Als u nog vastzit op Apache 2.2 (in 2026 uiterst zeldzaam, maar mogelijk op verouderde hosting), gebruikt u de oudere syntaxis:

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Order allow,deny
  Deny from all
</FilesMatch>

Plaats het blok boven de markering # BEGIN WordPress. Alles tussen # BEGIN WordPress en # END WordPress wordt door WordPress zelf beheerd en wordt herschreven wanneer permalinks veranderen of core-updates worden uitgevoerd. Alles buiten die markeringen wordt met rust gelaten.

Open na het opslaan van het bestand https://uwdomein.nl/readme.html in een privévenster van uw browser. U zou een 403 Forbidden moeten krijgen. Hetzelfde geldt voor /license.txt. Als u de bestandsinhoud nog steeds ziet, negeert uw host ofwel .htaccess volledig (zeldzaam op Apache, normaal op nginx) ofwel heeft AllowOverride ingesteld op een waarde die FilesMatch-richtlijnen verwijdert. Ga naar Optie 3.

Optie 2: Blokkeren via nginx

Op nginx is er geen .htaccess. Als u uw eigen server beheert (een VPS bij Hetzner, Netcup, DigitalOcean, of een beheerde nginx-host waar u de configuratie controleert), voegt u het volgende toe binnen het server-blok van uw site:

location ~* ^/(readme\.html|license\.txt|wp-config-sample\.php)$ {
  deny all;
  return 403;
}

Herlaad nginx met sudo nginx -t && sudo systemctl reload nginx, test daarna met curl -I https://uwdomein.nl/readme.html. De eerste regel van het antwoord zou HTTP/2 403 moeten zijn.

Verschillende beheerde WordPress-hosts die intern nginx gebruiken (Raidboxes, Kinsta, WP Engine, Cloudways) leveren standaard regels van dit type. De moeite waard om de hostdocumentatie te raadplegen. Als ze dat niet doen, voegt de support meestal de regel op verzoek voor u toe.

Optie 3: Gedeelde hosting waar .htaccess-overrides niet werken

Sommige strikt afgeschermde gedeelde hosts draaien op nginx en negeren .htaccess volledig. Andere draaien op Apache maar met restrictieve AllowOverride-regels. Als noch Optie 1 noch Optie 2 beschikbaar is, hebt u drie redelijke alternatieven, gesorteerd op duurzaamheid:

1. Gebruik een beveiligingsplug-in die corebestand-hardening voor u afhandelt. Solid Security en All In One WP Security & Firewall hebben beide een schakelaar "corebestanden verwijderen" of "WordPress-versie verbergen" die readme.html afhandelt. Wordfence in de Extended Protection-modus kan de bestanden ook blokkeren op WAF-niveau. Het voordeel is dat deze instellingen WordPress-updates automatisch overleven.
2. Maak het bestand leeg via een Must Use-plug-in. Als een regel op serverniveau onmogelijk is, is de meest betrouwbare aanpak een kleine mu-plug-in die readme.html en license.txt na elke WordPress-update overschrijft met lege inhoud. Zie het bijbehorende artikel met codefragmenten in onze kennisbank.
3. Verwijder de bestanden handmatig. De snelste oplossing kost tien seconden via SFTP: verwijder gewoon readme.html, license.txt en wp-config-sample.php uit de WordPress-root. Het probleem is dat WordPress core-updates de bestanden herstellen. U moet eraan denken om ze na elke grote update opnieuw te verwijderen, en daarom is een plug-in of webserverregel het betere langetermijnantwoord.

Wat u niet moet doen

Een paar benaderingen die op oudere blogposts opduiken, maar slechter zijn dan ze lijken:

• De bestanden hernoemen. readme.html hernoemen naar readme.html.old ziet er netjes uit, maar helpt niet. WordPress maakt bij de volgende update gewoon het origineel opnieuw aan, en nu hebt u twee bestanden in plaats van één.
• Bestandsrechten op 000 zetten. Dit blokkeert het lezen op de meeste hosts, maar de volgende core-update reset de rechten, en op sommige hosts breekt het zelfs de upgrade zelf als WordPress het bestand tijdens het updateproces niet kan lezen.
• De bestanden bewerken om het versienummer te verwijderen. Verleidelijk maar zinloos. WordPress herstelt het origineel bij een update, en zelfs een bewerkte readme.html bevestigt nog steeds dat de site op WordPress draait.

Het patroon is elke keer hetzelfde: alles dat zich binnen de WordPress-installatiemap bevindt en niet wordt beschermd door een webserverregel, wordt bij een update gereset. Blokkeer op het webserverniveau, of gebruik een plug-in die zichzelf actief weet te houden over updates heen.

Hoe u uw configuratie verifieert

1. Open https://uwdomein.nl/readme.html in een privévenster. Verwacht resultaat: een 403 Forbidden-pagina (of 404 als u voor verwijdering hebt gekozen).
2. Dezelfde controle voor https://uwdomein.nl/license.txt en https://uwdomein.nl/wp-config-sample.php.
3. Als u de bestandsinhoud nog steeds ziet, leeg dan eventuele caches die voor de site staan (Cloudflare, Varnish, paginacaches op serverniveau zoals LiteSpeed Cache of WP Rocket) en probeer opnieuw. Gecachete antwoorden kunnen de wijziging urenlang verbergen.
4. Voer een nieuwe InspectWP-scan uit. De controle op een blootgestelde readme.html in het beveiligingsgedeelte zou groen moeten worden.

Nu u toch bezig bent

Hetzelfde soort FilesMatch- of location-regel is de moeite waard om toe te passen op een paar andere endpoints die regelmatig opduiken in InspectWP-scans: wp-config.php.bak, wp-config.php.swp, .git/, .env, phpinfo.php en elke info.php die een ontwikkelaar tijdens het debuggen heeft achtergelaten. Hetzelfde mechanisme, dezelfde vijf regels configuratie, en u verwijdert in één keer een hele klasse van toevallige fingerprinting en het lekken van inloggegevens.