Een contactformulier laat interne foutdetails zien

Het gaat om de publieke response: alles wat een bezoeker te zien krijgt, in de pagina, in de HTML-broncode, in de netwerkresponse of in headers. Interne foutdetails zijn bijvoorbeeld een stacktrace, een bestandspad op de server, een SQL-fragment, de naam of versie van het framework, een e-mailserveradres, een API-sleutel of een stuk configuratie.

MDN omschrijft webbeveiliging als het beschermen van websites en hun gebruikers tegen schade door kwaadwillende derden, en benoemt veilige verwerking van invoer en goede operationele praktijken, zoals het zorgvuldig omgaan met geheimen, als kernpunten (MDN over webbeveiliging). Die bron geeft het kader, maar geen kant-en-klare instructie voor jouw formuliersoftware. Hoe je foutweergave uitschakelt, hangt af van je CMS, plug-in of framework. Dat zoek je op in de documentatie ervan of vraag je aan je webbouwer.

Buiten de scope: juridische beoordeling van gegevensbescherming en een volledige penetratietest. Dit is een praktische eigen controle van wat je formulier zichtbaar lekt.

Test op een staging-omgeving als je die hebt. Heb je er geen, doe dan live alleen onschuldige tests zoals een leeg veld of een ongeldig e-mailadres en zeg je hostingpartij of webbouwer vooraf wat je doet. Test dubbel verzenden, een onbereikbare mailserver of database en uploads alleen in staging. Een timeout of foutmelding kan ook optreden nadat het bericht al is opgeslagen of verstuurd. Gebruik daarom een herkenbare testtekst die je daarna kunt opvragen en controleer of er geen dubbele verwerking is. Probeer nooit aanvalstechnieken uit tegen systemen die je niet beheert.

1. Verstuur het formulier volledig leeg.
2. Vul een e-mailadres in zonder apenstaartje en een telefoonnummer met letters.
3. Plak een zeer lange tekst (bijvoorbeeld enkele duizenden tekens) in het berichtveld.
4. Voer speciale tekens in: aanhalingstekens, haakjes, een kleiner-dan-teken, emoji en accenten.
5. Verstuur twee keer snel na elkaar, om dubbele verwerking te zien.
6. Laat een bijlage weg of upload een verkeerd bestandstype, als het formulier uploads toestaat.
7. Open de URL van de formulierverwerking rechtstreeks in de browser (een GET in plaats van een POST), als je dat adres kent.
8. Vraag je beheerder, indien mogelijk, om tijdelijk de mailserver of database onbereikbaar te maken in staging, zodat je ook een serverfout ziet.

Noteer per test wat je zag: een nette melding, een lege pagina, een algemene foutpagina of technische details.

De zichtbare tekst is maar een deel. Een nette melding op het scherm kan nog steeds details bevatten in de broncode of netwerkresponse. Bekijk daarom drie lagen.

• Het scherm: staat er iets wat een gewone klant niet hoeft te weten?
• De paginabroncode: zoek naar commentaarblokken, verborgen velden en foutteksten die niet getoond worden.
• De netwerkresponse: open de ontwikkelaarstools van je browser, tabblad netwerk, en bekijk de response en headers van het verzendverzoek. Let op headers die softwarenamen en versies tonen.

Het exacte menu van de ontwikkelaarstools verschilt per browser en versie, dus kijk in de hulp van je eigen browser. Let ook op ajax-formulieren: de pagina toont dan 'Er ging iets mis', terwijl de achterliggende JSON-respons een volledige foutmelding bevat.

Let op: een publieke scan van je website ziet alleen wat zichtbaar is voor bezoekers. Interne configuratie die niet in een response terechtkomt, zie je met zo'n controle niet.

Het doel is niet minder diagnose, maar diagnose op de juiste plaats. De bezoeker krijgt een korte, bruikbare melding. Je team krijgt de details in een afgeschermd logboek.

Een praktische oplossing is een referentiecode: de bezoeker ziet 'Er ging iets mis, noteer code X als je contact opneemt' en je logboek koppelt die code aan de volledige fout. Zo verlies je geen diagnose.

Stel dat je een webbouwer inschakelt. Een fictieve overdrachtsnota kan zo luiden.

Invoer: contactformulier op de pagina Contact, verzonden met een leeg e-mailveld. Waargenomen: de pagina toont een technische foutmelding met een serverpad. Gewenst: een korte melding bij het e-mailveld en geen technische tekst in scherm, broncode of netwerkresponse. Details moeten in de serverlogs terechtkomen met een tijdstip en referentiecode.

Verwachte technische controles na de wijziging: herhaal alle teststappen uit sectie twee, controleer de drie lagen uit sectie drie, en controleer dat een opzettelijk uitgelokte fout in staging wel in het logboek verschijnt. Zie je dat niet, dan is de diagnose verloren gegaan en is de oplossing niet af. Vraag je webbouwer ook uitdrukkelijk te bevestigen welke omgeving (staging of live) is aangepast. Debuginstellingen staan soms enkel in de ene omgeving uit.

Herhaal na elke aanpassing het volledige testscript, niet alleen het geval dat je net hebt opgelost. Een fix voor een leeg veld repareert niet automatisch de foutpagina bij een uitgevallen mailserver.

• Bewaar de testresultaten per datum, zodat je ze bij een update van je CMS of plug-in kan herhalen.
• Controleer na elke grote update opnieuw, want debuginstellingen kunnen terugspringen.
• Beperk wie toegang heeft tot de logs en bewaar er geen onnodige persoonsgegevens in. Ga bij twijfel over wat je mag loggen te rade bij een deskundige.
• Als er sleutels of wachtwoorden zichtbaar waren, beschouw ze als blootgesteld en laat ze vervangen.
• Bescherm beheeraccounts met een tweede inlogstap. Google beschrijft voor Google-accounts hoe tweestapsverificatie een extra beveiligingslaag toevoegt voor het geval een wachtwoord wordt gestolen (Google over tweestapsverificatie). Die bron gaat over Google-accounts, niet over jouw CMS. Of en hoe je CMS tweede stappen ondersteunt, controleer je in de documentatie ervan.

Wil je zien welke signalen van je website publiek zichtbaar zijn, bekijk ze dan via Marketing Scan. De scan vervangt de controles uit dit artikel niet. Controleer zelf in de scanresultaten wat ze wel en niet meeneemt.