Validatie van invoergegevens in mobiele apps — basisprincipes, controlemethoden en implementatie

Wat is validatie van invoergegevens?

Validatie van invoergegevens is het controleren of gegevens die in de applicatie terechtkomen van de gebruiker, een externe service of een andere component voldoen aan de verwachte criteria. Deze criteria omvatten het gegevenstype (string, getal, datum), het format (e-mail, URL, telefoon), het bereik van waarden (leeftijd van 18 tot 120), de lengte (wachtwoord van 8 tot 128 tekens) en toegestane tekens (alleen Latijnse letters, cijfers, streepje). Zonder validatie kan de applicatie gegevens verwerken die uitvoeringsfouten, gegevensbeschadiging of beveiligingskwetsbaarheden veroorzaken.

Waarom is validatie een kritiek beveiligingselement?

Het ontbreken van validatie van invoergegevens is de hoofdoorzaak van kwetsbaarheden zoals SQL Injection, XSS, Command Injection, Path Traversal en Buffer Overflow. Volgens MITRE CWE (2025) staat CWE-20 (Improper Input Validation) op de tweede plaats in de ranglijst van gevaarlijkste softwarefouten. Validatie is de eerste verdedigingslinie in het beveiligingsmodel Defense in Depth: het kapt onjuiste gegevens af voordat ze andere componenten van het systeem bereiken.

Validatie vs sanitisatie

Validatie wijst gegevens af die niet aan de criteria voldoen. Sanitisatie (opschonen) wijzigt gegevens door gevaarlijke delen te verwijderen of te escapen. Bij het invoeren van HTML-inhoud kan validatie bijvoorbeeld de tekstlengte controleren, terwijl sanitisatie script-tags verwijdert via de bibliotheek HTML Purifier of DOMPurify. Sanitisatie vervangt validatie niet: ze werken als een paar. Validatie is het beleid „toegestaan/verboden“, sanitisatie is „opgeschoond voor gebruik“.

Typen validatie van invoergegevens

Validatie wordt ingedeeld naar controlediepte. Formatvalidatie is het eenvoudigst en snelst, zakelijke validatie is het meest complex en contextafhankelijk. Alle drie de niveaus moeten achtereenvolgens worden toegepast: eerst format, dan semantiek, dan bedrijfslogica. Het overslaan van elk niveau kan leiden tot onjuist functioneren van het systeem of kwetsbaarheden.

Formatvalidatie

Controle van gegevenstype, grootte, format en toegestane tekens. Wordt uitgevoerd via reguliere expressies, ingebouwde typen van talen en validatiebibliotheken. Voorbeelden: controle van UUID (format 8-4-4-4-12 hexadecimale cijfers), controle van telefoonnummer (alleen cijfers, + aan het begin, 7 tot 15 tekens), controle van geheel getal (waarde in het bereik Integer.MIN_VALUE — Integer.MAX_VALUE). Formatvalidatie is het minimaal vereiste niveau voor elk invoerveld.

Semantische validatie

Controle van de logische correctheid van gegevens in de context van het vakgebied. Bijvoorbeeld: de startdatum is niet later dan de einddatum, de leeftijd ligt binnen redelijke grenzen voor het systeem, de coördinaten liggen binnen het servicegebied. Semantische validatie vereist inzicht in de zakelijke context en kan niet alleen op basis van format worden uitgevoerd. Voorbeeld: het veld „aantal tickets“ kan de formatcontrole doorstaan (geheel getal, > 0), maar mag semantisch niet groter zijn dan het aantal vrije plaatsen.

Zakelijke validatie

Het meest complexe niveau — het controleren van gegevens op overeenstemming met de bedrijfsregels van de applicatie. Voorbeelden: een gebruiker kan niet de enige beheerder verwijderen, het orderbedrag overschrijdt het kredietlimiet niet, een product kan alleen worden besteld als het op voorraad is. Zakelijke validatie vereist vaak databasequery's of externe services en wordt uitgevoerd na format- en semantische controles. Fouten in zakelijke validatie zijn de meest voorkomende oorzaak van ontevredenheid van gebruikers.

Client- en servervalidatie

Clientvalidatie (in de browser of mobiele app) is nodig voor gebruikersgemak: onmiddellijke feedback zonder gegevens naar de server te sturen. Servervalidatie is echter de enige betrouwbare, omdat clientcode altijd kan worden omzeild. Stuur verzoeken via ontwikkelaarstools, Postman of een proxy (Burp Suite) — en clientvalidatie houdt op te bestaan. Volgens PortSwigger Research (2025) vertrouwt meer dan 90% van de geteste webapplicaties voor minstens één veld uitsluitend op clientvalidatie.

Regel: client — voor UX, server — voor beveiliging

Clientvalidatie kan de verzendknop uitschakelen, fouten markeren en tips tonen. Servervalidatie is de verplichte controle van elke parameter, zelfs als de client die al heeft gecontroleerd. Het dupliceren van validatie op beide niveaus is standaardpraktijk. De server moet gegevens controleren alsof de client niet bestaat. Dit garandeert bescherming tegen gewijzigde verzoeken, geautomatiseerde aanvallen en kwaadaardige clients.

Implementatie van clientvalidatie

Op het web — HTML5-attributen (required, pattern, min/max, type="email") en JavaScript. In mobiele apps — native validators voor tekstvelden (InputFilter in Android, textField(:shouldChangeCharactersIn:) in iOS). React Hook Form en Formik voor React, Vuelidate voor Vue, Angular Reactive Forms — populaire bibliotheken voor clientvalidatie. Ze ondersteunen allemaal aangepaste regels en asynchrone validatie (het controleren van de uniekheid van een login op de server).

// Voorbeeld van servervalidatie op Express met Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — al gecontroleerde en veilige gegevens
    const user = await User.create(value);
    res.status(201).json(user);
});

Validatie in mobiele apps

Mobiele apps stellen bijzondere eisen aan gegevensvalidatie. Het scherm is kleiner — fouten moeten bondig zijn, het toetsenbord contextueel (numeriek voor het invoeren van getallen), en de controle asynchroon om de UI niet te blokkeren. Native platforms bieden ingebouwde validatiemechanismen die standaard moeten worden gebruikt. Material Design Guidelines voor Android en Human Interface Guidelines voor iOS bevatten gedetailleerde aanbevelingen voor het tonen van validatiefouten.

Validatie op Android (Jetpack Compose)

Jetpack Compose biedt een declaratieve benadering van validatie via statusbeheer. Elk invoerveld is gekoppeld aan een status (MutableState) en de fout wordt berekend op basis van de huidige waarde. De bibliotheek Compose Validator vereenvoudigt het maken van regels: required, email, min/max length, pattern. Validatie wordt geactiveerd bij tekstwijziging (onValueChange) of bij een poging om het formulier te verzenden. Het wordt aanbevolen om de fout pas te tonen na de eerste verzending of nadat de gebruiker klaar is met invoeren (debounce 300-500ms).

Validatie op iOS (SwiftUI)

SwiftUI heeft geen ingebouwd validatiemechanisme voor formulieren, maar maakt eenvoudige implementatie mogelijk via Combine en property wrappers. Gebruik @State voor de waarde van het veld en een berekende eigenschap voor de fout. Het framework ValidatedPropertyKit biedt kant-en-klare decorators: @Validated().email(), @Validated().range(18...120). Aanbeveling van iOS — gebruik toetsenbordtypen (UIKeyboardType.emailAddress, .numberPad) en auto-capitalization om het aantal fouten op invoerniveau te verminderen.

Validatie op Flutter

Flutter biedt de klasse Form en TextFormField met ingebouwde validatie via een validator-callback. Elk veld retourneert een fout als string of null als de gegevens correct zijn. FormState.validate() start de controle van alle velden van het formulier. Het pakket reactive_forms voor complexe gevallen: aangepaste validators, asynchrone controle, dynamische regels. Flutter Web en de mobiele versie gebruiken dezelfde API, wat het onderhoud vereenvoudigt.

// Voorbeeld van formuliervalidatie op Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Validatietechnieken en -tools

Moderne frameworks bieden ingebouwde validators die 80% van de behoeften dekken. De resterende 20% vereist aangepaste regels, reguliere expressies of compositie van bestaande. Het kernprincipe — validatie moet declaratief zijn, zodat deze gemakkelijk kan worden gelezen, getest en onderhouden. Vermijd validatielogica die verspreid is over controllers en schermen — breng deze onder in afzonderlijke klassen of schema's.

White-list vs Black-list benaderingen

White-list (witte lijst) — je bepaalt welke gegevens zijn toegestaan, al het andere wordt afgewezen. Black-list — je bepaalt welke gegevens zijn verboden, al het andere wordt doorgelaten. White-list is altijd betrouwbaarder: je weet precies welke gegevens erdoorheen komen. Black-list vereist dat je alle mogelijke aanvallen voorziet, wat onmogelijk is. Voorbeeld: gebruik bij het controleren van leeftijd een white-list (alleen getallen van 18 tot 120), niet een black-list („0“, „-1“, „999999“ verbieden).

Reguliere expressies — kracht en gevaar

Reguliere expressies zijn een effectief hulpmiddel voor formatvalidatie, maar kunnen een bron zijn van ReDoS-aanvallen (Regular Expression Denial of Service). Sommige patronen (bijvoorbeeld (a+)+b) leiden tot catastrofale backtracking bij lange strings en belasten de CPU van de server volledig. Gebruik bewezen regex-bibliotheken en beperk de lengte van de string vóór het toepassen van de reguliere expressie. Gebruik voor complexe gevallen (e-mail, URL) de ingebouwde parsers van talen, niet zelfgemaakte reguliere expressies.

Typische fouten bij validatie

Zelfs ervaren ontwikkelaars maken fouten bij het implementeren van validatie. De meest voorkomende: alleen clientvalidatie, te strenge regels (wachtwoord „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters“), niet-informatieve foutmeldingen ("Error: invalid input") en het negeren van randgevallen (spaties aan het begin/einde, Unicode-tekens, lege strings). Elk van deze fouten verslechtert de UX en kan de formulierconversie verlagen.

• Alleen clientvalidatie — de gevaarlijkste fout: elk verzoek kan worden vervalst via Postman of cURL
• Te strenge regels — stoten gebruikers af: OWASP raadt minimale vereisten aan bij registratie
• Unicode negeren — het controleren van de stringlengte in bytes (in plaats van tekens) breekt Nederlands, Chinees, emoji
• Niet-informatieve fouten — „Invalid format“ in plaats van „Email must contain @ symbol after local part“
• Leeg veld controleren — if (value) maakt geen onderscheid tussen een lege string en nul, false of „0“

Beste praktijk — een gecentraliseerd validatiesysteem dat is bedekt met unittests. Elke regel moet afzonderlijk worden getest: grenswaarden, correcte gegevens, typische aanvallen (SQLi-pogingen, XSS-payloads, zeer lange strings). Regressietests voor validatie voorkomen dat regels per ongeluk worden verzwakt tijdens refactoring. Gebruik property-based testing (QuickCheck, fast-check) voor het genereren van willekeurige gegevens en om te controleren dat validatie niet crasht met een uitzondering.