Bemeneti adatok validálása mobilalkalmazásokban — alapok, ellenőrzési módszerek és megvalósítás

Mi a bemeneti adatok validálása?

A bemeneti adatok validálása annak ellenőrzése, hogy a felhasználótól, külső szolgáltatástól vagy más komponenstől az alkalmazásba érkező adatok megfelelnek-e a várt kritériumoknak. Ezek a kritériumok magukban foglalják az adattípust (karaktersorozat, szám, dátum), a formátumot (e-mail, URL, telefon), az értéktartományt (életkor 18 és 120 között), a hosszúságot (jelszó 8 és 128 karakter között) és a megengedett karaktereket (csak latin betűk, számjegyek, kötőjel). Validálás nélkül az alkalmazás olyan adatokat dolgozhat fel, amelyek futásidejű hibákat, adatsérülést vagy biztonsági sérülékenységeket okoznak.

Miért kritikus biztonsági elem a validálás?

A bemeneti adatok validálásának hiánya olyan sérülékenységek gyökéroka, mint az SQL Injection, XSS, Command Injection, Path Traversal és Buffer Overflow. A MITRE CWE (2025) szerint a CWE-20 (Improper Input Validation) a második helyen áll a legveszélyesebb szoftverhibák rangsorában. A validálás a első védelmi vonal a Defense in Depth biztonsági modellben: lefogja a hibás adatokat, mielőtt azok elérnék a rendszer más komponenseit.

Validálás vs szanitizálás

A validálás elutasítja a kritériumoknak nem megfelelő adatokat. A szanitizálás (tisztítás) módosítja az adatokat a veszélyes részek eltávolításával vagy kódolásával. Például HTML-tartalom beírásakor a validálás ellenőrizheti a szöveg hosszát, a szanitizálás pedig eltávolíthatja a script-tageket a HTML Purifier vagy a DOMPurify könyvtár segítségével. A szanitizálás nem helyettesíti a validálást: együtt működnek. A validálás az „engedélyezett/tiltott“ politika, a szanitizálás pedig a „használat előtt megtisztított“.

A bemeneti adatok validálásának típusai

A validálást az ellenőrzés mélysége szerint osztályozzuk. A formátumvalidálás a legegyszerűbb és leggyorsabb, az üzleti validálás pedig a legösszetettebb és leginkább kontextusfüggő. Mindhárom szintet egymás után kell alkalmazni: először a formátumot, majd a szemantikát, végül az üzleti logikát. Bármely szint kihagyása a rendszer hibás működéséhez vagy sérülékenységekhez vezethet.

Formátumvalidálás

Az adattípus, a méret, a formátum és a megengedett karakterek ellenőrzése. Reguláris kifejezésekkel, a nyelvek beépített típusaival és validáló könyvtárakkal valósul meg. Példák: UUID-ellenőrzés (8-4-4-4-12 hexadecimális számjegy formátuma), telefonszám-ellenőrzés (csak számjegyek, + az elején, 7 és 15 karakter között), egész szám ellenőrzése (érték az Integer.MIN_VALUE — Integer.MAX_VALUE tartományban). A formátumvalidálás a minimálisan szükséges szint minden beviteli mezőhöz.

Szemantikai validálás

Az adatok logikai helyességének ellenőrzése a szakterület kontextusában. Például: a kezdő dátum nem későbbi, mint a záró dátum, az életkor az ésszerű határokon belül van a rendszer számára, a koordináták a szolgáltatási területen belül vannak. A szemantikai validálás üzleti kontextus megértését igényli, és nem végezhető el csak a formátum alapján. Példa: a „jegyek száma“ mező átmehet a formátumellenőrzésen (egész szám, > 0), de szemantikailag nem haladhatja meg a szabad helyek számát.

Üzleti validálás

A legösszetettebb szint — az adatok ellenőrzése az alkalmazás üzleti szabályainak való megfelelés szempontjából. Példák: a felhasználó nem törölheti az egyetlen adminisztrátort, a rendelés összege nem haladja meg a hitelkeretet, a termék csak akkor rendelhető, ha készleten van. Az üzleti validálás gyakran adatbázis-lekérdezéseket vagy külső szolgáltatásokat igényel, és a formátum- és szemantikai ellenőrzések után történik. Az üzleti validálás hibái a felhasználói elégedetlenség leggyakoribb okai.

Kliens- és szerveroldali validálás

A kliensoldali validálásra (böngészőben vagy mobilalkalmazásban) a felhasználó kényelme miatt van szükség: azonnali visszajelzés anélkül, hogy az adatokat elküldenénk a szerverre. A szerveroldali validálás azonban az egyetlen megbízható, mert a kliens kódja mindig megkerülhető. Küldje el a kéréseket fejlesztői eszközökön, a Postmanen vagy proxyn (Burp Suite) keresztül — és a kliensoldali validálás megszűnik létezni. A PortSwigger Research (2025) szerint a tesztelt webalkalmazások több mint 90%-a legalább egy mező esetében kizárólag a kliensoldali validálásra támaszkodik.

Szabály: kliens — az UX-ért, szerver — a biztonságért

A kliensoldali validálás letilthatja a küldés gombot, kiemelheti a hibákat, tippeket jeleníthet meg. A szerveroldali validálás minden paraméter kötelező ellenőrzése, még akkor is, ha a kliens már ellenőrizte. A validálás megkettőzése mindkét szinten bevett gyakorlat. A szervernek úgy kell ellenőriznie az adatokat, mintha a kliens nem is létezne. Ez garantálja a védelmet a módosított kérések, az automatizált támadások és a káros kliensek ellen.

A kliensoldali validálás megvalósítása

A weben — HTML5-attribútumok (required, pattern, min/max, type="email") és JavaScript. Mobilalkalmazásokban — a szövegmezők natív validátorai (InputFilter Androidon, textField(:shouldChangeCharactersIn:) iOS-en). React Hook Form és Formik a Reacthez, Vuelidate a Vue-hoz, Angular Reactive Forms — népszerű könyvtárak a kliensoldali validáláshoz. Mindegyik támogatja az egyedi szabályokat és az aszinkron validálást (a bejelentkezési név egyediségének ellenőrzése a szerveren).

// Példa szerveroldali validálásra Expressen a Joival
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 — már ellenőrzött és biztonságos adatok
    const user = await User.create(value);
    res.status(201).json(user);
});

Validálás mobilalkalmazásokban

A mobilalkalmazások különleges követelményeket támasztanak az adatvalidálással szemben. A képernyő kisebb — a hibáknak tömöreknek kell lenniük, a billentyűzet kontextuális (numerikus a számok beviteléhez), az ellenőrzés pedig aszinkron, hogy ne blokkolja a felületet. A natív platformok beépített validálási mechanizmusokat kínálnak, amelyeket alapértelmezetten használni kell. A Material Design Guidelines Androidhoz és a Human Interface Guidelines iOS-hez részletes ajánlásokat tartalmaz a validálási hibák megjelenítéséről.

Validálás Androidon (Jetpack Compose)

A Jetpack Compose deklaratív megközelítést kínál a validáláshoz állapotkezelésen keresztül. Minden beviteli mező egy állapothoz (MutableState) kapcsolódik, a hiba pedig az aktuális érték alapján számítódik ki. A Compose Validator könyvtár leegyszerűsíti a szabályok létrehozását: required, email, min/max length, pattern. A validálás a szöveg változásakor (onValueChange) vagy az űrlap elküldésére tett kísérletkor aktiválódik. Javasolt a hibát csak az első elküldés után vagy a felhasználó bevitele befejezése után megjeleníteni (debounce 300-500ms).

Validálás iOS-en (SwiftUI)

A SwiftUI-nak nincs beépített űrlapvalidálási mechanizmusa, de lehetővé teszi annak könnyű megvalósítását Combine és property wrappers segítségével. Használjon @State-et a mező értékéhez és számított tulajdonságot a hibához. A ValidatedPropertyKit keretrendszer kész dekorátorokat biztosít: @Validated().email(), @Validated().range(18...120). iOS-ajánlás — használja a billentyűzettípusokat (UIKeyboardType.emailAddress, .numberPad) és az auto-capitalization-t, hogy csökkentse a hibák számát a bevitelek szintjén.

Validálás Flutterben

A Flutter biztosítja a Form és TextFormField osztályt beépített validálással a validator-callback segítségével. Minden mező hibát ad vissza szövegként, vagy null-t, ha az adatok helyesek. A FormState.validate() elindítja az űrlap összes mezőjének ellenőrzését. A reactive_forms csomag az összetett esetekhez: egyedi validátorok, aszinkron ellenőrzés, dinamikus szabályok. A Flutter Web és a mobil verzió ugyanazt az API-t használja, ami leegyszerűsíti a karbantartást.

// Példa űrlapvalidálásra Flutterben
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'),
            ),
        ],
    ),
)

Validálási technikák és eszközök

A modern keretrendszerek beépített validátorokat kínálnak, amelyek a szükségletek 80%-át lefedik. A fennmaradó 20% egyedi szabályokat, reguláris kifejezéseket vagy a meglévők kombinációját igényli. A kulcsfontosságú elv — a validálásnak deklaratívnak kell lennie, hogy könnyen lehessen olvasni, tesztelni és karbantartani. Kerülje a vezérlők és képernyők között szétszórt validálási logikát — helyezze azt külön osztályokba vagy sémákba.

White-list vs Black-list megközelítések

White-list (fehér lista) — Ön határozza meg, mely adatok engedélyezettek, minden más elutasításra kerül. Black-list — Ön határozza meg, mely adatok tiltottak, minden más átengedésre kerül. A white-list mindig megbízhatóbb: pontosan tudja, mely adatok fognak átmenni. A black-list megköveteli az összes lehetséges támadás előrejelzését, ami lehetetlen. Példa: az életkor ellenőrzésekor használjon white-listet (csak számok 18 és 120 között), ne black-listet („0“, „-1“, „999999“ tiltása).

Reguláris kifejezések — erő és veszély

A reguláris kifejezések hatékony eszközei a formátumvalidálásnak, de ReDoS-támadások (Regular Expression Denial of Service) forrásai lehetnek. Egyes minták (például a (a+)+b) hosszú karaktersorozatokon katasztrofális visszalépést (backtracking) okoznak, teljesen leterhelve a szerver CPU-ját. Használjon kipróbált regex-könyvtárakat, és a reguláris kifejezés alkalmazása előtt korlátozza a karaktersorozat hosszát. Összetett esetekben (e-mail, URL) használja a nyelvek beépített elemzőit a saját reguláris kifejezések helyett.

Tipikus hibák a validálás során

Még a tapasztalt fejlesztők is hibáznak a validálás megvalósítása során. A leggyakoribbak: csak kliensoldali validálás, túl szigorú szabályok (jelszó „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters“), nem informatív hibaüzenetek ("Error: invalid input") és a határesetek (szóközök elején/végén, Unicode-karakterek, üres karaktersorozatok) figyelmen kívül hagyása. Mindegyik hiba rontja az UX-et, és csökkentheti az űrlapok konverzióját.

• Csak kliensoldali validálás — a legveszélyesebb hiba: bármely kérés meghamisítható a Postmanen vagy a cURL-lel
• Túl szigorú szabályok — elriasztják a felhasználókat: az OWASP minimális követelményeket javasol a regisztrációnál
• Unicode figyelmen kívül hagyása — a karaktersorozat hosszának bájtokban (nem karakterekben) történő ellenőrzése elrontja a magyart, a kínait, az emojikat
• Nem informatív hibák — „Invalid format“ az „Email must contain @ symbol after local part“ helyett
• Üres mező ellenőrzése — az if (value) nem különbözteti meg az üres karaktersorozatot a nullától, a false-tól vagy a „0“-tól

A legjobb gyakorlat — egységtesztekkel lefedett, központosított validálási rendszer. Minden szabályt külön kell tesztelni: határértékek, helyes adatok, tipikus támadások (SQLi-kísérletek, XSS-payloadok, nagyon hosszú karaktersorozatok). A validálás regressziós tesztjei megakadályozzák a szabályok véletlen meggyengülését refaktorálás közben. Használjon property-based testing-et (QuickCheck, fast-check) véletlenszerű adatok generálásához és annak ellenőrzéséhez, hogy a validálás nem esik össze kivétellel.