Iemand verstuurt je formulier met een ongeldig e-mailadres. Je formulier accepteert het. De welkomstmail komt niet aan. Die persoon hoort nooit meer iets van je. Iemand anders vult verplichte velden niet in. Het formulier gaat toch door. Je team heeft onvolledige gegevens. Beide fouten gebeuren omdat validatie ontbreekt of niet klopt.
Validatie is het controleren of formuliergegevens geldig zijn voordat je ze accepteert. Het gebeurt op twee plekken: in de browser en op de server. Beide zijn belangrijk. In dit artikel lees je hoe validatie werkt, waarom je beide nodig hebt en welke fouten vaak voorkomen.
Wat is validatie?
Validatie controleert of de gegevens in een formulier aan je eisen voldoen. Verplichte velden hebben een waarde. E-mailvelden bevatten een @-teken. Telefoonvelden bevatten alleen cijfers. Bestandsuploads blijven onder de groottelimiet.
Zonder validatie komen foute gegevens in je systeem. Je backend loopt vast. Je e-mailservice weigert berichten. Je verspilt tijd aan het opschonen van vuile data.
Validatie gebeurt op twee plekken: client-side (in de browser, vóór het verzenden) en server-side (op je server, na het verzenden). Je hebt allebei nodig.
Client-side validatie
De browser kan formuliergegevens controleren voordat hij ze verstuurt. HTML heeft ingebouwde validatieattributen. JavaScript kan ook valideren.
HTML-validatie
<input type="email" required> controleert of het veld een waarde heeft en op een e-mailadres lijkt. De browser toont een foutmelding als de gebruiker een ongeldig formulier probeert te versturen.
HTML-validatieattributen zijn onder andere required (het veld moet een waarde hebben), min/max voor getallen (waarden binnen een bereik houden), minlength/maxlength (aantal tekens afdwingen), pattern (past bij reguliere expressies) en type (valideert het veldtype zelf). Zo controleert type="email" het formaat en weigert type="number" niet-numerieke invoer.
HTML-validatie werkt direct zonder JavaScript, geeft nette foutmeldingen vanuit de browser en past het mobiele toetsenbord aan op het veldtype. Nadelen zijn dat de foutmeldingen van de browser algemeen en soms onduidelijk zijn, dat je ze zonder JavaScript niet kunt aanpassen en dat elke browser andere meldingen toont.
JavaScript-validatie
Voor meer controle valideer je met JavaScript, bijvoorbeeld met function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } en form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. Met JavaScript-validatie schrijf je eigen regels, toon je eigen foutmeldingen en valideer je velden terwijl de gebruiker typt (realtime validatie). Nadelen zijn dat JavaScript nodig is (niet betrouwbaar voor beveiliging), dat je meer code moet onderhouden en dat je fouten kunt tonen voordat de gebruiker klaar is met typen als je valideert op het input-event.
Server-side validatie
Nadat het formulier is verstuurd, controleert de server de gegevens opnieuw. Hier zit de echte beveiliging.
Vertrouw nooit op client-side validatie. Iemand kan JavaScript uitzetten. Iemand kan het verzoek onderscheppen en de gegevens aanpassen. Iemand kan curl of een ander hulpmiddel gebruiken om foute data te versturen zonder je formulier te gebruiken.
Server-side validatie is de enige bescherming die je hebt. Het is niet optioneel.
Als de server de inzending ontvangt, controleer je of verplichte velden aanwezig zijn, valideer je het formaat van e-mailadressen, telefoonnummers en URL's, check je of getallen binnen het verwachte bereik vallen, verifieer je dat bestandsuploads van het juiste type en de juiste grootte zijn, zorg je dat gegevens niet te lang zijn en schoon je data op om injectieaanvallen te voorkomen. Mislukt de validatie, stuur dan een foutmelding terug: het formulier mag niet worden verwerkt en de gebruiker hoort wat er niet klopt. Server-side validatie is trager omdat de gebruiker op een antwoord moet wachten, maar het is betrouwbaar en veilig, dus doe het altijd.
Wanneer gebruik je welk type validatie?
Client-side validatie is voor gebruiksgemak. Het vertelt de gebruiker direct dat er iets niet klopt. Ze hoeven het formulier niet te versturen om te ontdekken dat een e-mailadres ongeldig is.
Server-side validatie is voor de integriteit van je gegevens en voor beveiliging. Het zorgt dat foute data nooit je systeem binnenkomt.
Gebruik beide. Client-side validatie voor snelheid en feedback. Server-side validatie voor veiligheid en beveiliging.
Veelgemaakte validatiefouten
Alleen client-side valideren
Iemand zet JavaScript uit en je validatie is weg. Iemand gebruikt curl om foute data te POSTen en je validatie draait nooit. Je krijgt rommel in je database.
Valideer altijd op de server. De clientkant is een extra.
Te strikt valideren
Je e-mailvalidatie is zo strikt dat echte e-mailadressen worden afgewezen. Je telefoonvalidatie accepteert alleen het Amerikaanse formaat en wijst internationale nummers af. Je naamveld weigert streepjes, apostrofs en andere geldige tekens.
Test je validatie met echte data. Vraag gebruikers uit andere landen om te testen. Maak validatieregels zo ruim mogelijk, zolang ze foute data nog opvangen.
Geen duidelijke foutmeldingen tonen
"Ongeldige invoer." Wat is ongeldig? Welk veld? Wat moeten ze doen?
Foutmeldingen moeten specifiek zijn: "E-mailadres moet tussen 5 en 254 tekens lang zijn." "Telefoonnummer moet 10 cijfers hebben." "Wachtwoord moet minstens één cijfer bevatten."
Toon de fout naast het veld dat de fout veroorzaakte. Verstop fouten niet in een overzichtslijst waar de gebruiker naar moet zoeken.
Gevoelige gegevens op de client valideren
Stuur creditcardnummers of wachtwoorden niet door client-side validatie. Toon ze niet in de browserconsole. Log ze niet.
Valideer gevoelige gegevens alleen op de server, via HTTPS.
Bestandsuploads niet valideren
Iemand uploadt een bestand van 100 megabyte. Je server heeft geen opslagruimte meer. Iemand uploadt een uitvoerbaar bestand. Je server krijgt een virus.
Valideer bestandstype en grootte op de server. Controleer of het bestand echt het type is dat het zegt te zijn. Vertrouw niet alleen op de bestandsextensie of het MIME-type.
Realtime validatie of validatie bij verzenden
Realtime validatie controleert elk veld terwijl de gebruiker typt. De gebruiker ziet direct een foutmelding als hij iets verkeerd invoert. Hij kan het meteen herstellen.
Nadeel: als je fouten te vroeg toont, raakt de gebruiker gefrustreerd. Toon fouten pas nadat de gebruiker het veld verlaat (blur-event), niet terwijl hij nog typt.
Validatie bij verzenden controleert alles op het moment dat het formulier wordt verstuurd. De gebruiker vult het hele formulier in en ziet dan alle fouten tegelijk.
Nadeel: de gebruiker moet terug om fouten te herstellen nadat hij al heeft verstuurd. Dat onderbreekt de flow.
Beste aanpak: valideer bij blur (als de gebruiker een veld verlaat) voor realtime feedback. Valideer bij het verzenden als laatste controle. Toon alle fouten tegelijk als er iets mislukt.
Validatie per veldtype
E-mailvalidatie
Volledige e-mailvalidatie is ingewikkeld (RFC 5322 telt 60 pagina's). Controleer daarom in de meeste gevallen alleen of de waarde een @ en een domein bevat met const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Zo vang je de meeste ongeldige e-mailadressen op zonder zo strikt te zijn dat echte adressen falen.
Telefoonvalidatie
Het telefoonformaat verschilt per land. Het Amerikaanse formaat is (123) 456-7890, het Britse formaat is +44 20 7946 0958 en Duitsland gebruikt +49 30 123456. Accepteer het internationale formaat, haal niet-numerieke tekens weg op de server en sla het telefoonnummer op als tekst in plaats van als getal, zodat voorloopnullen in sommige landen behouden blijven.
Wachtwoordvalidatie
Een goed wachtwoord is lang (minstens 12 tekens) en moeilijk te raden. Eis geen speciale tekens of een mix van hoofdletters en kleine letters, want die regels frustreren gebruikers en verbeteren de beveiliging niet. Goede wachtwoordeisen zijn minstens 12 tekens en het vermijden van veelvoorkomende patronen (zoals "123456" of de naam van de gebruiker). Gebruik een wachtwoordsterkte-indicator om de gebruiker te laten zien hoe sterk zijn wachtwoord is.
Datumvalidatie
Controleer of de datum in de toekomst of het verleden ligt, afhankelijk van wat nodig is. Een formulier voor evenementregistratie moet datums in het verleden afwijzen. Een formulier voor een geboortedatum moet datums in de toekomst afwijzen.
Hoe WEMASY formuliervalidatie aanpakt
WEMASY-formulieren hebben ingebouwde client-side validatie (verplichte velden, e-mailformaat, enzovoort) voor directe feedback. Als formulieren worden verstuurd, valideren de servers van WEMASY alle gegevens opnieuw voordat ze worden verwerkt. Zo krijgen gebruikers snelle feedback en zijn je gegevens beschermd.
Bekijk de validatiefuncties in jouw WEMASY-abonnement.