Wat staat er per ongeluk openbaar op je website?

Een webserver vraagt niet of er een link naar een bestand is. Hij kijkt alleen of het bestaat. Staat er in de map van je site een vergeten back-up of een lijst met klanten, dan krijgt iedereen die de naam weet of raadt dat bestand gewoon mee. En raden is precies wat bots de hele dag doen.

Wie er aanklopt

Programma’s gaan voortdurend alle adressen op internet langs en vragen bij elke site dezelfde lijst namen op. /.env, omdat daar vaak sleutels in staan. /.git/config, omdat je daarmee soms de hele code van een site kunt terughalen. De inlogpagina van WordPress, ook bij sites zonder WordPress. En namen als backup.zip en database.sql. In het logboek van mijn eigen server staan elke dag honderden van zulke verzoeken.

Op je eigen server zie je hetzelfde. Het logboek van de webserver houdt elk verzoek bij, en met dit commando tel je hoeveel er vandaag naar zulke adressen gingen:

grep -cE "\.env|\.git/|wp-login" /var/log/nginx/access.log

Krijg je Permission denied, zet er dan sudo voor. Zie je nul, dan is je server nog nieuw of was het rustig; kijk over een week nog eens. Het zegt niets over jou persoonlijk, want ze proberen het bij iedereen. Wel laat het zien hoe snel een bestand dat er per ongeluk wel staat, gevonden wordt. Wat dat logboek verder over je bezoekers vertelt, lees je in Bezoekers tellen zonder cookies.

Wat er vaak per ongeluk online staat

Het gaat meestal om dezelfde soorten bestanden. Notities en plannen, zoals specificatie.md of todo.txt. Een export uit je boekhouding of je mailprogramma als .csv, die je even neerzette om Claude er iets mee te laten doen. Een zip met een oude versie van je site. De map .git, met de hele geschiedenis van je code. En .env, met je sleutels.

Het testhandboek van OWASP, een internationale stichting voor veilige software, heeft er een apart hoofdstuk over: oude, reservekopie- en vergeten bestanden. Volgens OWASP geven zulke bestanden een aanvaller vaak precies wat hij zoekt, tot en met de gegevens om in te loggen op je database.

Een bestand dat nergens gelinkt is, is dus niet geheim. Ook robots.txt is geen slot. Dat bestand vraagt zoekmachines netjes om bepaalde adressen over te slaan, maar de norm die het beschrijft zegt er uitdrukkelijk bij dat het geen vorm van toegangsbeveiliging is, en dat paden die je erin zet daardoor juist vindbaar worden. Zet je een geheime map in robots.txt, dan wijs je hem aan.

Bij sites die met AI gebouwd zijn, gebeurt dit makkelijk. Claude maakt onderweg werkbestanden aan, en jij zet er een export naast om mee te werken. Niemand ruimt het op, omdat de site gewoon werkt. Meer over waarom dat bij AI zo vaak misgaat, lees je in Waarom apps die met AI gebouwd zijn zo vaak lekken.

Wat je server al tegenhoudt

Op een server van retrAIt zet je een site live met publish, dat je werkmap naar de webmap kopieert. Een paar dingen laat het bewust achter: de werkbestanden van Claude, zoals CLAUDE.md en plannen.md, alles waarvan de naam met een punt begint, zoals .env en .git, de map node_modules, en databasebestanden en sleutelbestanden. De webserver weigert bovendien elk bestand en elke map waarvan de naam met een punt begint, behalve de map die nodig is voor je certificaat. Een lijst van wat er in een map staat, laat hij niet zien.

Al het andere gaat wel online. Een klanten.csv of een oud.zip in je werkmap staat na publish voor iedereen klaar. Op servers die vóór oktober 2026 zijn ingericht, laat publish bovendien minder achter: alleen CLAUDE.md, plannen.md, de bestanden met een punt en node_modules. Reden genoeg om het zelf na te kijken.

Bouw je een platform met een eigen programma, dan gebruik je publish niet, en bepaalt je programma wat openbaar is. Een bekende fout is een programma dat de hele projectmap vrijgeeft, inclusief .env en de database. Laat Claude één aparte map gebruiken voor wat openbaar mag, zoals afbeeldingen en stijlbestanden, en controleer het daarna met dezelfde commando’s als hieronder.

Zelf nakijken in een kwartier

Een voorbeeld. Jeroen is installateur en zette een export van zijn offertes, offertes-2025.csv, in de map van zijn site, zodat Claude er een pagina met referenties van kon maken. De pagina werd mooi, en het bestand bleef staan. Na de volgende publish stond een lijst met namen, adressen en bedragen online, zonder dat er ergens een link naar was. Hij vond het pas toen hij de lijst van online bestanden naliep.

Zo loop je dat na, op je server, met je eigen domein in plaats van mijndomein.nl:

1. Bekijk alle bestanden die online staan met find /var/www/mijndomein.nl -type f | sort. Is de lijst lang, zet er dan | less achter.
2. Loop de lijst langs. Let op notities, exports, zips, databases en testpagina’s.
3. Vraag bestanden op die er niet horen te zijn, zoals curl -sI https://mijndomein.nl/.env | head -n 1, en doe hetzelfde voor /.git/config en /CLAUDE.md. Je hoort steeds 404 te zien.
4. Moet er iets weg, verplaats het dan uit je werkmap, bijvoorbeeld naar ~/werk, en zet je site opnieuw live met sudo publish mijndomein.nl ~/sites/mijndomein.nl.
5. Vraag het bestand nog eens op met curl -sI en kijk of er nu 404 staat.

Bij stap 4 ruimt publish ook online op: wat niet meer in je werkmap staat, haalt hij uit de webmap. Haal je een bestand alleen uit de webmap en niet uit je werkmap, dan zet de volgende publish het gewoon terug.

Als er iets heeft opgestaan

Weghalen stopt het lek, maar maakt het niet ongedaan. Wat online stond, kan al gekopieerd zijn. In het logboek zie je of iemand het bestand heeft opgevraagd. zgrep "offertes-2025.csv" /var/log/nginx/access.log* toont elke keer dat het bestand werd opgevraagd, met de tijd erbij, en het getal 200 als het ook echt is meegegeven. Het logboek gaat ongeveer twee weken terug.

Stond er een sleutel in, vervang die dan meteen, zoals beschreven in Wachtwoorden en API-sleutels in je code. Stonden er gegevens van mensen in, zoals bij Jeroen, dan kan het om een datalek gaan, met een termijn van 72 uur om het te melden. Wat je dan doet, staat in Een datalek op je eigen site.

Loop de vijf stappen vandaag na, voor elke site die je hebt. Het kost een kwartier. Zet je werkbestanden daarna voortaan buiten de map die je publiceert, bijvoorbeeld in ~/werk, of in een map waarvan de naam met een punt begint. Dan kan je volgende publish je niet meer verrassen.