Kunnen vreemden door uw mappen bladeren?

Bezoek op uw website een map zonder indexbestand — zeg /uploads/ of /backups/ — en staat automatische indexering aan, dan kan de server een lijst teruggeven van wat erin zit. En dat doet hij net zo goed voor ieder ander, aanvallers en scrapers inbegrepen. Bladeren door mappen (autoindex) geeft nergens toegang toe — maar het maakt bestanden die al via HTTP bereikbaar zijn veel makkelijker te vinden. Zet het uit, en zie het als niet meer dan één laag.

Waarom dit een echt risico is

• Informatie prijsgeven. Een lijst kan bestandsnamen, submappen, groottes en datums onthullen — nuttige verkenning voor dat deel van de website.
• Onbedoelde datalekken. Een db-backup.sql, clients.xlsx of .env.example die in een openbare map belandt, is via een lijst zo gevonden — en blijft ook zonder lijst downloadbaar via een directe URL.
• Geautomatiseerd oogsten. Scanners ontdekken open lijsten en halen alles op waar die naartoe linken.

Kern: zet mappenlijsten uit, weiger wat privé moet blijven op elke laag die verzoeken beantwoordt, en houd vooral geheimen uit de webroot — een verborgen lijst is geen deur op slot.

Wat u moet doen

1. Schakel autoindex uit. Op Apache — in .htaccess waar de host de Options-override toestaat, anders in de serverconfiguratie:

   Options -Indexes

   Op Nginx is autoindex off; de standaard — controleer het in de location die het pad echt bedient, want scopes erven van elkaar en overschrijven elkaar.

2. Een indexbestand is alleen een vangnet. Een index.html die de server herkent, onderdrukt de lijst voor dat mapverzoek — het beschermt niets wat op naam wordt opgevraagd.
3. Houd gevoelige bestanden helemaal uit de webroot. Back-ups, inloggegevens en gegevensexports horen boven de documentroot of in opslag die niet via HTTP wordt aangeboden. Dit is de sterkste maatregel op deze pagina — de rest is schadebeperking.
4. Weiger dotfiles en back-upachtervoegsels — wetende dat de lijst moet kloppen met de echte achtervoegsels van uw website (deze is hoofdlettergevoelig en dekt alleen wat hij noemt), en dat verwijderen beter is dan een weigerlijst bijhouden:

   <FilesMatch "(^\.|\.(bak|sql|log|env)$)">
     Require all denied
   </FilesMatch>

   FilesMatch matcht alleen bestandsnamen, geen mappen — de bestanden in een .git-map (zoals .git/config) hebben gewone namen en glippen er zo doorheen. Blokkeer de map zelf, met een patroon dat niet ook .github of .gitignore tegenhoudt:

   RedirectMatch 404 "(?i)(?:^|/)\.git(?:/|$)"

5. Bescherm privégedeelten met echte authenticatie — op Apache: Basic-authenticatie via .htaccess, met het wachtwoordbestand buiten de documentroot, alleen over HTTPS en nooit met inloggegevens in een URL. (Hiervoor moet de host AuthConfig-overrides toestaan.)
6. Controleer op de openbare URL, in beide richtingen. Vraag een testmap zonder indexbestand op en kijk of er geen gegenereerde lijst verschijnt — een 403, een 404 en een eigen pagina zijn allemaal aanvaardbaar. Vraag daarna rechtstreeks een onschuldig, bekend bestand op om te bevestigen dat uw weigerregels echt gelden. Test via de voordeur: een Apache-regel beschermt alleen verzoeken die Apache bereiken — kan een proxy, CDN of aparte laag voor statische bestanden eerst antwoorden, configureer en test die laag dan ook — en wis eerder gecachete lijsten.
7. Verwijder achtergebleven back-ups — verstop ze niet alleen. Op een goed geconfigureerde PHP-website wordt config.php uitgevoerd en niet getoond; een kopie met de naam config.php.bak of config.old kan, afhankelijk van de configuratie, als gewone tekst worden geserveerd — en faalt de PHP-handler ooit, dan kan zelfs het livebestand lekken. Haal verouderde back-ups uit de documentroot, verplaats niet-openbare include-bestanden erbuiten waar de applicatie dat toelaat, en weiger anders directe toegang — en test die weigering voordat u erop vertrouwt.