Validarea datelor de intrare în aplicațiile mobile — baze, metode de verificare și implementare

Ce este validarea datelor de intrare?

Validarea datelor de intrare înseamnă verificarea că datele care ajung în aplicație de la utilizator, de la un serviciu extern sau de la alt component corespund criteriilor așteptate. Aceste criterii includ tipul datelor (șir, număr, dată), formatul (email, URL, telefon), intervalul de valori (vârsta de la 18 la 120), lungimea (parola de la 8 la 128 de caractere) și caracterele permise (doar litere latine, cifre, cratimă). Fără validare, aplicația poate prelucra date care provoacă erori de execuție, coruperea datelor sau vulnerabilități de securitate.

De ce este validarea un element critic de securitate?

Lipsa validării datelor de intrare este cauza principală a unor vulnerabilități precum SQL Injection, XSS, Command Injection, Path Traversal și Buffer Overflow. Conform MITRE CWE (2025), CWE-20 (Improper Input Validation) ocupă locul doi în clasamentul celor mai periculoase erori software. Validarea este prima linie de apărare în modelul de securitate Defense in Depth: elimină datele incorecte înainte ca acestea să ajungă la alte componente ale sistemului.

Validare vs Sanitizare

Validarea respinge datele care nu respectă criteriile. Sanitizarea (curățarea) modifică datele, eliminând sau escapând părțile periculoase. De exemplu, la introducerea conținutului HTML, validarea poate verifica lungimea textului, iar sanitizarea poate elimina tag-urile script prin biblioteca HTML Purifier sau DOMPurify. Sanitizarea nu înlocuiește validarea: ele lucrează împreună. Validarea este politica „permis/interzis”, sanitizarea este „curățat înainte de utilizare”.

Tipuri de validare a datelor de intrare

Validarea se clasifică după adâncimea verificării. Validarea de format este cea mai simplă și rapidă, iar validarea de business este cea mai complexă și dependentă de context. Toate cele trei niveluri trebuie aplicate secvențial: mai întâi formatul, apoi semantica, apoi logica de business. Omisiunea oricărui nivel poate duce la funcționarea incorectă a sistemului sau la vulnerabilități.

Validarea de format

Verificarea tipului datelor, dimensiunii, formatului și caracterelor permise. Se realizează prin expresii regulate, tipuri incorporate ale limbajelor și biblioteci de validare. Exemple: verificarea UUID (format 8-4-4-4-12 cifre hexazecimale), verificarea numărului de telefon (doar cifre, + la început, de la 7 la 15 caractere), verificarea numărului întreg (valoare în intervalul Integer.MIN_VALUE — Integer.MAX_VALUE). Validarea de format este nivelul minim necesar pentru orice câmp de intrare.

Validarea semantică

Verificarea corectitudinii logice a datelor în contextul domeniului. De exemplu: data de început nu este mai târziu decât data de sfârșit, vârsta este în limite rezonabile pentru sistem, coordonatele sunt în aria de servire. Validarea semantică necesită înțelegerea contextului de business și nu poate fi realizată doar pe baza formatului. Exemplu: câmpul „număr de bilete” poate trece de verificarea de format (număr întreg, > 0), dar semantic nu poate depăși numărul de locuri libere.

Validarea de business

Cel mai complex nivel — verificarea datelor pentru conformitatea cu regulile de business ale aplicației. Exemple: utilizatorul nu poate șterge singurul administrator, suma comenzii nu depășește limita de credit, produsul poate fi comandat doar dacă este în stoc. Validarea de business necesită adesea interogări ale bazei de date sau servicii externe și se realizează după verificările de format și semantice. Erorile de validare de business sunt cele mai frecvente cauze de nemulțumire a utilizatorilor.

Validarea pe client și pe server

Validarea pe client (în browser sau în aplicația mobilă) este necesară pentru confortul utilizatorului: feedback imediat fără trimiterea datelor pe server. Totuși, validarea pe server este singura fiabilă, deoarece codul clientului poate fi întotdeauna ocolit. Trimiteți cereri prin instrumentele de dezvoltare, Postman sau un proxy (Burp Suite) — și validarea pe client încetează să existe. Conform PortSwigger Research (2025), peste 90% dintre aplicațiile web testate se bazează exclusiv pe validarea pe client pentru cel puțin un câmp.

Regula: clientul — pentru UX, serverul — pentru securitate

Validarea pe client poate dezactiva butonul de trimitere, evidenția erorile, afișa sugestii. Validarea pe server este verificarea obligatorie a fiecărui parametru, chiar dacă clientul l-a verificat deja. Dublarea validării la ambele niveluri este o practică standard. Serverul trebuie să verifice datele ca și cum clientul nu ar exista. Aceasta garantează protecția împotriva cererilor modificate, atacurilor automatizate și clienților malițioși.

Implementarea validării pe client

Pe web — atributele HTML5 (required, pattern, min/max, type="email") și JavaScript. În aplicațiile mobile — validatoare native pentru câmpuri de text (InputFilter în Android, textField(:shouldChangeCharactersIn:) în iOS). React Hook Form și Formik pentru React, Vuelidate pentru Vue, Angular Reactive Forms — biblioteci populare pentru validarea pe client. Toate suportă reguli personalizate și validare asincronă (verificarea unicității loginului pe server).

// Exemplu de validare pe server cu Express și 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 — date deja verificate și sigure
    const user = await User.create(value);
    res.status(201).json(user);
});

Validarea în aplicațiile mobile

Aplicațiile mobile impun cerințe speciale pentru validarea datelor. Ecranul este mai mic — erorile trebuie să fie concise, tastatura contextuală (numerică pentru introducerea numerelor), iar verificarea — asincronă, pentru a nu bloca interfața. Platformele native oferă mecanisme incorporate de validare care ar trebui folosite implicit. Material Design Guidelines pentru Android și Human Interface Guidelines pentru iOS conțin recomandări detaliate despre afișarea erorilor de validare.

Validarea pe Android (Jetpack Compose)

Jetpack Compose oferă o abordare declarativă a validării prin gestionarea stării. Fiecare câmp de intrare este legat de o stare (MutableState), iar eroarea este calculată pe baza valorii curente. Biblioteca Compose Validator simplifică crearea regulilor: required, email, min/max length, pattern. Validarea se declanșează la schimbarea textului (onValueChange) sau la încercarea de trimitere a formularului. Se recomandă afișarea erorii doar după prima trimitere sau după ce utilizatorul a terminat introducerea (debounce 300-500ms).

Validarea pe iOS (SwiftUI)

SwiftUI nu are un mecanism incorporat de validare a formularelor, dar permite implementarea ușoară a acestuia prin Combine și property wrappers. Folosiți @State pentru valoarea câmpului și o proprietate calculată pentru eroare. Framework-ul ValidatedPropertyKit oferă decoratori gata pregătiți: @Validated().email(), @Validated().range(18...120). Recomandarea iOS — folosiți tipurile de tastatură (UIKeyboardType.emailAddress, .numberPad) și auto-capitalization pentru a reduce numărul de erori la nivelul introducerii.

Validarea pe Flutter

Flutter oferă clasa Form și TextFormField cu validare incorporată prin callback-ul validator. Fiecare câmp returnează eroarea ca șir sau null dacă datele sunt corecte. FormState.validate() declanșează verificarea tuturor câmpurilor formularului. Pachetul reactive_forms pentru cazuri complexe: validatoare personalizate, verificare asincronă, reguli dinamice. Flutter Web și versiunea mobilă folosesc același API, ceea ce simplifică întreținerea.

// Exemplu de validare a formularului pe 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'),
            ),
        ],
    ),
)

Tehnici și instrumente de validare

Framework-urile moderne oferă validatoare incorporate care acoperă 80% din necesități. Restul de 20% necesită reguli personalizate, expresii regulate sau compoziția celor existente. Principiul-cheie — validarea trebuie să fie declarativă pentru a fi ușor de citit, testat și întreținut. Evitați logica de validare împrăștiată prin controllere și ecrane — mutați-o în clase sau scheme separate.

Abordările White-list vs Black-list

White-list (lista albă) — stabiliți ce date sunt permise, tot restul este respins. Black-list — stabiliți ce date sunt interzise, tot restul este permis. White-list este întotdeauna mai sigură: știți exact ce date vor trece. Black-list necesită anticiparea tuturor atacurilor posibile, ceea ce este imposibil. Exemplu: la verificarea vârstei folosiți white-list (doar numere de la 18 la 120), nu black-list (interzicerea „0”, „-1”, „999999”).

Expresiile regulate — putere și pericol

Expresiile regulate sunt un instrument eficient pentru validarea de format, dar pot fi sursa atacurilor ReDoS (Regular Expression Denial of Service). Unele modele (de exemplu, (a+)+b) provoacă backtracking catastrofal pe șiruri lungi, încărcând complet CPU-ul serverului. Folosiți biblioteci regex verificate și limitați lungimea șirului înainte de aplicarea expresiei regulate. Pentru cazuri complexe (email, URL) folosiți parserele incorporate ale limbajelor, nu expresii regulate proprii.

Greșeli tipice la validare

Chiar și dezvoltatorii experimentați fac greșeli la implementarea validării. Cele mai frecvente: validarea doar pe client, reguli prea stricte (parola „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters”), mesaje de eroare neinformative ("Error: invalid input") și ignorarea cazurilor-limită (spații la început/sfârșit, caractere Unicode, șiruri vide). Fiecare dintre aceste greșeli înrăutățește UX și poate reduce conversia formularelor.

• Doar validare pe client — cea mai periculoasă greșeală: orice cerere poate fi falsificată prin Postman sau cURL
• Reguli prea stricte — alungă utilizatorii: OWASP recomandă cerințe minime la înregistrare
• Ignorarea Unicode — verificarea lungimii șirului în octeți (nu în caractere) strică româna, chineza, emoji
• Erori neinformative — „Invalid format” în loc de „Email must contain @ symbol after local part”
• Verificarea câmpului gol — if (value) nu distinge șirul vid de zero, false sau „0”

Cea mai bună practică — un sistem centralizat de validare acoperit de teste unitare. Fiecare regulă trebuie testată separat: valori-limită, date corecte, atacuri tipice (încercări SQLi, XSS-payloads, șiruri foarte lungi). Testele de regresie pentru validare previn slăbirea accidentală a regulilor la refactorizare. Folosiți property-based testing (QuickCheck, fast-check) pentru generarea de date aleatorii și verificarea că validarea nu cade cu excepție.