U typt uw eigen adres in en er verschijnt geen website, maar een kale opsomming: Index of /, daaronder een rijtje mapnamen als wp-admin, wp-content en wp-includes, met datums en bestandsgroottes erachter. Geen logo, geen menu, geen opmaak. Dat is een directory listing, en als uw website die toont in plaats van de homepage is er iets weggevallen dat er normaal wel is.
Het is zelden een teken dat uw bestanden weg zijn. Meestal staat alles er nog gewoon en weet de server alleen niet meer welk bestand hij moet openen. Vervelend genoeg laat hij dan de hele inhoud van de map zien, en dat wilt u niet.
Wat u eigenlijk ziet
Een webserver krijgt een adres binnen dat naar een map wijst, niet naar een bestand. Hij zoekt dan naar een startbestand: index.php, index.html, soms index.htm. Vindt hij er één, dan opent hij die. Vindt hij niets én staat het tonen van mapinhoud aan, dan drukt hij de inhoudsopgave af.
Vandaar de twee ingrediënten van dit probleem. Er ontbreekt een startbestand, én er staat een instelling open die dat mag opvangen met een lijst. Beide moeten kloppen voordat een bezoeker deze lijst te zien krijgt.
Het verschil met een foutmelding is belangrijk. Bij een crash krijgt u tekst over PHP of een 500-code. Hier krijgt u iets dat technisch gezien prima werkt: de server doet precies wat hem is opgedragen. Alleen was dat niet de bedoeling.
De vijf gebruikelijke oorzaken
- Het .htaccess-bestand is verdwenen of leeggelopen. Op Apache-servers staat daar de regel die het startbestand aanwijst en het tonen van mappen verbiedt. Een mislukte plugin-instelling of een verkeerde overdracht wist het bestand soms.
- Er is index.php uit de hoofdmap gehaald. Meestal per ongeluk, tijdens het opruimen van oude bestanden of het terugzetten van een gedeeltelijke kopie.
- De site staat in een onderliggende map. Bij een verhuizing komt WordPress in bijvoorbeeld /public_html/site/ terecht terwijl het adres naar /public_html/ wijst. Die bovenliggende map heeft dan geen startbestand.
- Er is net van hostingpakket gewisseld. Nieuwe server, standaardconfiguratie, en de regel die het uitzet is nog niet meegenomen.
- Een submap is nooit afgeschermd. De homepage werkt prima, maar /wp-content/uploads/2024/ toont keurig al uw pdf-bestanden aan wie het adres intikt.
Die laatste komt het vaakst voor en valt het minst op, want u merkt hem alleen als iemand er expliciet naar zoekt. En daar wordt naar gezocht: geautomatiseerde scanners proberen dit standaard.
Waarom dit meer is dan lelijk
Een openliggende maplijst geeft informatie weg die u liever voor uzelf houdt. Wie de inhoud van uw uploadsmap kan doorbladeren, ziet offertes, facturen of ontwerpbestanden die u ooit als bijlage heeft geüpload en waarvan u dacht dat alleen de ontvanger het adres kende. Er staat geen slot op zo’n bestand: het adres kennen is genoeg.
Daarnaast leest een aanvaller uit de lijst af welke plugins en thema’s u draait, inclusief mapnamen en soms versienummers. Dat scheelt hem werk. Het maakt uw site niet meteen kwetsbaar, maar het maakt hem wel een aantrekkelijker doelwit dan de buurman die niets prijsgeeft.
Tot slot pikt Google zulke lijsten op. Een bestandslijst die in de zoekresultaten belandt, ziet er voor een bezoeker uit als een verwaarloosde site.
Zo zet u het weer dicht
Werk in deze volgorde en maak eerst een kopie van de bestanden die u aanraakt.
- Kijk of index.php in de hoofdmap staat. Log in via FTP of de bestandsbeheerder van uw hosting. Ontbreekt hij, plaats dan de originele index.php uit een schone WordPress-download terug; dat bestand bevat maar een paar regels en is voor iedere site gelijk.
- Herstel het .htaccess-bestand. WordPress genereert het opnieuw als u in het beheerscherm naar Instellingen en dan Permalinks gaat en daar op opslaan klikt, zonder iets te wijzigen. Lukt dat niet, dan kunt u het handmatig terugzetten; dat staat in het artikel over een beschadigd htaccess-bestand.
- Zet het tonen van mapinhoud uit. Voeg boven in .htaccess de regel Options -Indexes toe. Draait u op Nginx, dan hoort in het serverblok autoindex off; te staan; dat moet uw hostingpartij doen.
- Plaats een leeg index.php in gevoelige mappen. WordPress doet dit zelf al voor wp-content en de pluginmap, maar mappen die u zelf heeft aangemaakt hebben die bescherming niet.
- Controleer het resultaat. Roep uw hoofdadres op, daarna /wp-content/uploads/ en /wp-includes/. U hoort nu een 403- of 404-melding te krijgen in plaats van een lijst.
Controleer ook de rechten op mappen. Staan die op 777, dan is er ooit iemand ruw te werk gegaan om een uploadprobleem op te lossen. Wat wél juist is, leest u in de uitleg over rechten op bestanden en mappen.
Bijzonder geval: het gebeurde na een aanval
Verscheen de lijst plotseling terwijl u niets heeft aangepast, kijk dan verder dan de instelling. Een leeggemaakt of vervangen .htaccess-bestand is een bekend bijverschijnsel van een inbraak, en dan is het herstellen van dat ene bestand niet genoeg.
Bekijk in dat geval de wijzigingsdatums in de lijst die u nu toch al ziet. Staan er bestanden tussen met een datum van vannacht terwijl u al maanden niets heeft gepubliceerd, dan is dat een sterk signaal. Ook onbekende mappen met kryptische namen zijn verdacht. Ga dan niet alleen de listing dichtzetten, maar de hele site nalopen.
Voorkomen is een kwestie van één controle
Dit hoort tot de fouten die u één keer goed zet en daarna nooit meer terugziet, mits u na elke verhuizing en elke herstelactie even nakijkt of de regel er nog staat. Zet het op uw lijstje bij het opleveren van een site, samen met het controleren van het certificaat en de zoekmachine-instellingen.
Blijft de lijst terugkomen na elke keer dat u hem uitzet, dan schrijft iets uw configuratie steeds opnieuw en is hulp bij een site die zich vreemd blijft gedragen sneller dan zelf blijven zoeken. Bij WebMaintor staat deze controle standaard in de maandelijkse ronde, juist omdat hij zo makkelijk ongemerkt wegvalt.
Doe dit vandaag nog: typ uw domein gevolgd door /wp-content/uploads/ in de adresbalk en kijk wat er terugkomt. Ziet u een lijst met jaartallen, dan weet u meteen waar u vanmiddag mee begint.
