Een onveilig downloadformulier voor klantdocumenten

Een downloadformulier bestaat uit drie delen die elk apart kunnen falen: de toegang (wie mag het bestand zien), de bestands-URL (hoe wordt het bestand aangeboden) en het vervalpad (wanneer verdwijnt de toegang). Een veilig formulier met een onveilige URL blijft een lek.

MDN beschrijft in de webbeveiligingsgids van MDN dat de te overwegen dreigingen sterk afhangen van wat je site precies doet. Het risico waar deze gids op mikt is Insecure Direct Object Reference (IDOR): toegang tot gegevens via een rechtstreeks verwijzende identifier die de server niet tegen rechten controleert. Voor jouw situatie bepaal je zelf welke bestanden gevoelig zijn, bijvoorbeeld identiteitsdocumenten, offertes of contracten.

Doe de volgende controles met testbestanden, nooit met echte klantdocumenten.

1. Upload twee testbestanden na elkaar en vergelijk de twee URL's. Verschillen ze alleen in een oplopend nummer of een datum? Dan is de link voorspelbaar.
2. Kopieer de bestands-URL en open die in een privévenster zonder ingelogde sessie. Krijg je het bestand? Dan hangt de toegang alleen aan de kennis van de link.
3. Pas in de URL een cijfer of tekendeel aan, met alleen je eigen testbestanden. Krijg je een ander testbestand zonder dat je daarvoor rechten hebt? Dan ontbreekt een toegangscontrole. Een afwijkende foutmelding ten opzichte van een niet-bestaande URL kan wijzen op informatielekkage.
4. Zoek in de paginabron en in je bevestigingsmails of de link ergens zichtbaar staat, bijvoorbeeld in een openbaar bereikbare bedankpagina.
5. Zoek in Google naar de mapnaam of bestandsnaam van je uploads met een site-zoekopdracht op je domein. Een leeg resultaat bewijst niets, een treffer is wel een duidelijk signaal.

Let op: een browsertest bewijst niet wat een zoekmachine kan crawlen. Dat hangt af van robots.txt en van waar de link openbaar staat.

Gebruik dit beslisblad om een bevinding te vertalen naar een actie.

Een niet te raden naam is een extra laag, geen vervanging van een toegangscontrole.

Als klanten moeten inloggen om documenten te halen, zijn zwakke accounts de volgende zwakke plek. MDN raadt aan om niet alleen op wachtwoorden te vertrouwen: passkeys zijn volgens die gids de veiligste methode en tijdgebonden eenmalige codes (TOTP) zijn veiliger dan een gewoon wachtwoord. Voor je eigen beheerdersaccounts toont de hulppagina van Google over tweestapsverificatie hoe zo'n extra stap werkt bij een Google-account. Dat is een voorbeeld van het principe, geen instelling voor jouw formulier. Let op: volgens die pagina zijn codes via sms of telefoontje kwetsbaarder voor aanvallen op telefoonnummers dan andere methoden.

Vraag je webbouwer of platformleverancier schriftelijk: welke inlogmethoden ondersteunt het systeem voor klanten en voor beheerders, worden sessiecookies beperkt met de attributen Secure en HttpOnly, en hoe lang blijft een ingelogde sessie geldig? Waar je dit instelt verschilt per systeem, dus laat de beheerder het aanwijzen in plaats van het te raden.

Fictieve invoer: een kmo laat klanten een offerte-aanvraag met bijlage insturen. Testbestand A krijgt de URL met eindcijfer 0041, testbestand B eindcijfer 0042. In een privévenster opent link A zonder inlog.

Verwachte technische controles na aanpassing, als opdracht aan de bouwer:

1. Link A en B zijn niet uit elkaar af te leiden.
2. Een privévenster zonder sessie krijgt een weigering, geen bestand.
3. Een tweede testaccount kan het bestand van het eerste testaccount niet openen.
4. Een link in een oudere mail geeft na de afgesproken vervaltermijn geen bestand meer.
5. De uploadmap is niet rechtstreeks via een URL bereikbaar.

Laat de bouwer per punt noteren hoe getest is. Dit voorbeeld bevat bewust geen resultaten: die moet jouw eigen test opleveren.

Herhaal na elke wijziging de vijf diagnosestappen met nieuwe testbestanden en noteer datum, tester en uitkomst. Herhaal ze ook na een update van je website-platform of formulierplug-in, omdat standaardinstellingen kunnen veranderen.

Grenzen: deze gids vervangt geen beveiligingsaudit of penetratietest en zegt niets over wettelijke naleving, bijvoorbeeld rond persoonsgegevens. Bij bijzonder gevoelige documenten raadpleeg je een specialist. Een publieke scan van je website kan alleen zichtbare signalen bekijken en bewijst niet hoe uploads server-side beschermd zijn. Wil je weten welke publieke signalen je site nu toont? Bekijk ze via Marketing Scan, zonder dat dit de controles hierboven vervangt.