Validering av indata i mobilappar — grunder, kontrollmetoder och implementering

Vad är validering av indata?

Validering av indata är att kontrollera att data som kommer in i applikationen från användaren, en extern tjänst eller en annan komponent uppfyller de förväntade kriterierna. Dessa kriterier omfattar datatyp (sträng, tal, datum), format (e-post, URL, telefon), värdeintervall (ålder från 18 till 120), längd (lösenord från 8 till 128 tecken) och tillåtna tecken (endast latinska bokstäver, siffror, bindestreck). Utan validering kan applikationen bearbeta data som orsakar körningsfel, dataskada eller säkerhetssårbarheter.

Varför är validering ett kritiskt säkerhetselement?

Avsaknaden av validering av indata är grundorsaken till sårbarheter som SQL Injection, XSS, Command Injection, Path Traversal och Buffer Overflow. Enligt MITRE CWE (2025) ligger CWE-20 (Improper Input Validation) på andra plats i rankningen av de farligaste programvarufelen. Validering är den första försvarslinjen i säkerhetsmodellen Defense in Depth: den kapar felaktiga data innan de når systemets andra komponenter.

Validering vs sanering

Validering avvisar data som inte uppfyller kriterierna. Sanering (rensning) ändrar data genom att ta bort eller koda farliga delar. Vid inmatning av HTML-innehåll kan validering till exempel kontrollera textens längd, medan sanering kan ta bort script-taggar via biblioteket HTML Purifier eller DOMPurify. Sanering ersätter inte validering: de arbetar tillsammans. Validering är policyn "tillåtet/förbjudet", sanering är "rensat före användning".

Typer av validering av indata

Validering klassificeras efter kontrollens djup. Formatvalidering är enklast och snabbast, medan affärsvalidering är mest komplex och kontextberoende. Alla tre nivåerna bör tillämpas i följd: först format, sedan semantik, därefter affärslogik. Att hoppa över vilken nivå som helst kan leda till felaktig systemfunktion eller sårbarheter.

Formatvalidering

Kontroll av datatyp, storlek, format och tillåtna tecken. Implementeras via reguljära uttryck, språkens inbyggda typer och valideringsbibliotek. Exempel: UUID-kontroll (format 8-4-4-4-12 hexadecimala siffror), telefonnummerkontroll (endast siffror, + i början, 7 till 15 tecken), heltalskontroll (värde i intervallet Integer.MIN_VALUE — Integer.MAX_VALUE). Formatvalidering är den miniminivå som krävs för varje inmatningsfält.

Semantisk validering

Kontroll av datans logiska korrekthet i domänens sammanhang. Till exempel: startdatumet är inte senare än slutdatumet, åldern ligger inom rimliga gränser för systemet, koordinaterna ligger inom tjänsteområdet. Semantisk validering kräver förståelse för affärskontexten och kan inte utföras enbart utifrån format. Exempel: fältet "antal biljetter" kan klara formatkontrollen (heltal, > 0), men får semantiskt inte överstiga antalet lediga platser.

Affärsvalidering

Den mest komplexa nivån — kontroll av data mot applikationens affärsregler. Exempel: användaren kan inte ta bort den enda administratören, orderbeloppet överstiger inte kreditgränsen, produkten kan endast beställas om den finns i lager. Affärsvalidering kräver ofta databasfrågor eller externa tjänster och utförs efter format- och semantiska kontroller. Fel i affärsvalideringen är de vanligaste orsakerna till användarnas missnöje.

Klient- och servervalidering

Klientvalidering (i webbläsaren eller mobilappen) behövs för användarens bekvämlighet: omedelbar återkoppling utan att skicka data till servern. Servervalidering är dock den enda tillförlitliga, eftersom klientkoden alltid kan kringgås. Skicka förfrågningar via utvecklarverktyg, Postman eller en proxy (Burp Suite) — och klientvalideringen upphör att existera. Enligt PortSwigger Research (2025) förlitar sig mer än 90 % av de testade webbapplikationerna enbart på klientvalidering för åtminstone ett fält.

Regel: klienten — för UX, servern — för säkerhet

Klientvalidering kan avaktivera skicka-knappen, markera fel och visa tips. Servervalidering är obligatorisk kontroll av varje parameter, även om klienten redan kontrollerat den. Att duplicera validering på båda nivåerna är standardpraxis. Servern ska kontrollera data som om klienten inte fanns. Det garanterar skydd mot modifierade förfrågningar, automatiserade attacker och skadliga klienter.

Implementering av klientvalidering

På webben — HTML5-attribut (required, pattern, min/max, type="email") och JavaScript. I mobilappar — inbyggda validerare för textfält (InputFilter i Android, textField(:shouldChangeCharactersIn:) i iOS). React Hook Form och Formik för React, Vuelidate för Vue, Angular Reactive Forms — populära bibliotek för klientvalidering. Alla stödjer anpassade regler och asynkron validering (kontroll av användarnamnets unikhet på servern).

// Exempel på servervalidering i Express med 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 — redan kontrollerade och säkra data
    const user = await User.create(value);
    res.status(201).json(user);
});

Validering i mobilappar

Mobilappar ställer särskilda krav på datavalidering. Skärmen är mindre — fel måste vara koncisa, tangentbordet kontextuellt (numeriskt för sifferinmatning) och kontrollen asynkron så att gränssnittet inte blockeras. Inbyggda plattformar erbjuder inbyggda valideringsmekanismer som ska användas som standard. Material Design Guidelines för Android och Human Interface Guidelines för iOS innehåller detaljerade rekommendationer om hur valideringsfel visas.

Validering i Android (Jetpack Compose)

Jetpack Compose erbjuder ett deklarativt förhållningssätt till validering genom tillståndshantering. Varje inmatningsfält är kopplat till ett tillstånd (MutableState) och felet beräknas utifrån det aktuella värdet. Biblioteket Compose Validator förenklar skapandet av regler: required, email, min/max length, pattern. Valideringen aktiveras vid textändring (onValueChange) eller vid försök att skicka formuläret. Det rekommenderas att visa felet först efter den första inlämningen eller efter att användaren har avslutat inmatningen (debounce 300-500ms).

Validering i iOS (SwiftUI)

SwiftUI har ingen inbyggd mekanism för formulärvalidering, men det går enkelt att implementera via Combine och property wrappers. Använd @State för fältets värde och en beräknad egenskap för felet. Ramverket ValidatedPropertyKit erbjuder färdiga dekoratörer: @Validated().email(), @Validated().range(18...120). iOS-rekommendation — använd tangentbordstyper (UIKeyboardType.emailAddress, .numberPad) och automatisk versalisering för att minska antalet fel på inmatningsnivån.

Validering i Flutter

Flutter tillhandahåller klassen Form och TextFormField med inbyggd validering via validator-callback. Varje fält returnerar ett fel som en sträng eller null om data är korrekta. FormState.validate() startar kontrollen av alla formulärets fält. Paketet reactive_forms för komplexa fall: anpassade validerare, asynkron kontroll, dynamiska regler. Flutter Web och mobilversionen använder samma API, vilket förenklar underhållet.

// Exempel på formulärvalidering i 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'),
            ),
        ],
    ),
)

Valideringstekniker och -verktyg

Modern ramverk tillhandahåller inbyggda validerare som täcker 80 % av behoven. De återstående 20 % kräver anpassade regler, reguljära uttryck eller kombination av befintliga. Nyckelprincipen — validering ska vara deklarativ så att den är lätt att läsa, testa och underhålla. Undvik valideringslogik som är utspridd över kontroller och skärmar — flytta ut den till separata klasser eller scheman.

White-list vs Black-list-metoder

White-list (vitlista) — du anger vilka data som är tillåtna, allt annat avvisas. Black-list — du anger vilka data som är förbjudna, allt annat släpps igenom. White-list är alltid mer tillförlitlig: du vet exakt vilka data som passerar. Black-list kräver att man förutser alla möjliga attacker, vilket är omöjligt. Exempel: vid ålderskontroll använd white-list (endast tal från 18 till 120), inte black-list (förbud mot "0", "-1", "999999").

Reguljära uttryck — kraft och fara

Reguljära uttryck är ett effektivt verktyg för formatvalidering, men de kan vara en källa till ReDoS-attacker (Regular Expression Denial of Service). Vissa mönster (till exempel (a+)+b) leder till katastrofal backtracking på långa strängar, vilket fullständigt belastar serverns CPU. Använd beprövade regex-bibliotek och begränsa strängens längd innan du tillämpar det reguljära uttrycket. För komplexa fall (e-post, URL) använd språkens inbyggda parsers i stället för egna reguljära uttryck.

Typiska misstag vid validering

Även erfarna utvecklare gör misstag vid implementeringen av validering. De vanligaste: enbart klientvalidering, alltför strikta regler (lösenord "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), oinformativ felmeddelanden ("Error: invalid input") och att ignorera gränsfall (mellanslag i början/slutet, Unicode-tecken, tomma strängar). Vart och ett av dessa misstag försämrar UX och kan sänka formulärkonverteringen.

• Endast klientvalidering — det farligaste misstaget: vilken förfrågan som helst kan förfalskas via Postman eller cURL
• Alltför strikta regler — skrämmer bort användare: OWASP rekommenderar minimikrav vid registrering
• Att ignorera Unicode — att kontrollera stränglängden i byte (i stället för tecken) förstör svenska, kinesiska, emoji
• Oinformativ felmeddelanden — "Invalid format" i stället för "Email must contain @ symbol after local part"
• Kontroll av tomt fält — if (value) skiljer inte en tom sträng från noll, false eller "0"

Bästa praxis — ett centraliserat valideringssystem täckt av enhetstester. Varje regel bör testas separat: gränsvärden, korrekta data, typiska attacker (SQLi-försök, XSS-payloads, mycket långa strängar). Regressionstester för validering förhindrar att regler försvagas av misstag vid refaktorering. Använd property-based testing (QuickCheck, fast-check) för att generera slumpmässiga data och kontrollera att valideringen inte kraschar med ett undantag.