Валидация на входни данни в мобилните приложения — основи, методи за проверка и реализация

Какво е валидация на входни данни?

Валидацията на входни данни е проверка, че данните, които постъпват в приложението от потребителя, външна услуга или друг компонент, отговарят на очакваните критерии. Тези критерии включват тип на данните (низ, число, дата), формат (имейл, URL, телефон), диапазон на стойностите (възраст от 18 до 120), дължина (парола от 8 до 128 знака) и допустими знаци (само латиница, цифри, тире). Без валидация приложението може да обработи данни, които ще причинят грешки при изпълнение, повреда на данни или уязвимости в сигурността.

Защо валидацията е критичен елемент на сигурността?

Липсата на валидация на входни данни е основната причина за уязвимости като SQL Injection, XSS, Command Injection, Path Traversal и Buffer Overflow. Според MITRE CWE (2025) CWE-20 (Improper Input Validation) заема второ място в класацията на най-опасните софтуерни грешки. Валидацията е първата линия на защита в модела за сигурност Defense in Depth: тя отсича некоректните данни, преди те да достигнат до другите компоненти на системата.

Валидация vs Санитизация

Валидацията отхвърля данните, които не отговарят на критериите. Санитизацията (почистването) променя данните, като премахва или кодира опасните части. Например при въвеждане на HTML съдържание валидацията може да провери дължината на текста, а санитизацията — да премахне script таговете чрез библиотеката HTML Purifier или DOMPurify. Санитизацията не заменя валидацията: те работят заедно. Валидацията е политиката „разрешено/забранено“, санитизацията е „почистено преди употреба“.

Видове валидация на входни данни

Валидацията се класифицира по дълбочината на проверката. Форматната валидация е най-простата и най-бърза, а бизнес валидацията е най-сложната и най-зависима от контекста. И трите нива трябва да се прилагат последователно: първо формат, след това семантика, после бизнес логика. Пропускането на което и да е ниво може да доведе до некоректна работа на системата или уязвимости.

Форматна валидация

Проверка на типа на данните, размера, формата и допустимите знаци. Реализира се чрез регулярни изрази, вградените типове на езиците и библиотеки за валидация. Примери: проверка на UUID (формат 8-4-4-4-12 шестнадесетични цифри), проверка на телефонен номер (само цифри, + в началото, от 7 до 15 знака), проверка на цяло число (стойност в диапазона Integer.MIN_VALUE — Integer.MAX_VALUE). Форматната валидация е минимално необходимото ниво за всяко поле за въвеждане.

Семантична валидация

Проверка на логическата коректност на данните в контекста на предметната област. Например: началната дата не е по-късна от крайната дата, възрастта е в разумни граници за системата, координатите са в територията на обслужване. Семантичната валидация изисква разбиране на бизнес контекста и не може да се извърши само на базата на формата. Пример: полето „брой билети“ може да премине форматната проверка (цяло число, > 0), но семантично не може да надвишава броя на свободните места.

Бизнес валидация

Най-сложното ниво — проверка на данните за съответствие с бизнес правилата на приложението. Примери: потребителят не може да изтрие единствения администратор, сумата на поръчката не надвишава кредитния лимит, продуктът може да се поръча само ако е наличен. Бизнес валидацията често изисква заявки към базата данни или външни услуги и се извършва след форматните и семантичните проверки. Грешките в бизнес валидацията са най-честите причини за недоволството на потребителите.

Клиентска и сървърна валидация

Клиентската валидация (в браузъра или мобилното приложение) е необходима за удобството на потребителя: незабавна обратна връзка без изпращане на данни до сървъра. Сървърната валидация обаче е единствено надеждна, тъй като клиентският код винаги може да бъде заобиколен. Изпратете заявките чрез инструментите за разработка, Postman или прокси (Burp Suite) — и клиентската валидация престава да съществува. Според PortSwigger Research (2025) повече от 90% от тестваните уеб приложения разчитат изключително на клиентска валидация за поне едно поле.

Правило: клиентът — за UX, сървърът — за сигурност

Клиентската валидация може да изключва бутона за изпращане, да откроява грешките, да показва подсказки. Сървърната валидация е задължителна проверка на всеки параметър, дори ако клиентът вече го е проверил. Дублирането на валидацията на двете нива е стандартна практика. Сървърът трябва да проверява данните така, сякаш клиентът не съществува. Това гарантира защита от модифицирани заявки, автоматизирани атаки и злонамерени клиенти.

Реализация на клиентската валидация

В уеб — HTML5 атрибути (required, pattern, min/max, type="email") и JavaScript. В мобилните приложения — вградени валидатори на текстови полета (InputFilter в Android, textField(:shouldChangeCharactersIn:) в iOS). React Hook Form и Formik за React, Vuelidate за Vue, Angular Reactive Forms — популярни библиотеки за клиентска валидация. Всички те поддържат персонализирани правила и асинхронна валидация (проверка на уникалността на потребителското име на сървъра).

// Пример за сървърна валидация в Express с 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 — вече проверени и безопасни данни
    const user = await User.create(value);
    res.status(201).json(user);
});

Валидация в мобилните приложения

Мобилните приложения поставят специални изисквания към валидацията на данни. Екранът е по-малък — грешките трябва да са кратки, клавиатурата — контекстуална (цифрова за въвеждане на числа), а проверката — асинхронна, за да не блокира интерфейса. Вградените платформи предоставят вградени механизми за валидация, които трябва да се използват по подразбиране. Material Design Guidelines за Android и Human Interface Guidelines за iOS съдържат подробни препоръки за показване на грешки при валидация.

Валидация в Android (Jetpack Compose)

Jetpack Compose предлага декларативен подход към валидацията чрез управление на състоянието. Всяко поле за въвеждане е обвързано със състояние (MutableState), а грешката се изчислява на базата на текущата стойност. Библиотеката Compose Validator опростява създаването на правила: required, email, min/max length, pattern. Валидацията се задейства при промяна на текста (onValueChange) или при опит за изпращане на формуляра. Препоръчва се грешката да се показва едва след първото изпращане или след като потребителят е приключил с въвеждането (debounce 300-500ms).

Валидация в iOS (SwiftUI)

SwiftUI няма вграден механизъм за валидация на формуляри, но позволява лесната му реализация чрез Combine и property wrappers. Използвайте @State за стойността на полето и изчисляемо свойство за грешката. Фреймуъркът ValidatedPropertyKit предоставя готови декоратори: @Validated().email(), @Validated().range(18...120). Препоръка за iOS — използвайте типовете клавиатура (UIKeyboardType.emailAddress, .numberPad) и автоматичното главни букви, за да намалите броя на грешките на ниво въвеждане.

Валидация в Flutter

Flutter предоставя класа Form и TextFormField с вградена валидация чрез validator callback. Всяко поле връща грешка като низ или null, ако данните са коректни. FormState.validate() стартира проверката на всички полета на формуляра. Пакетът reactive_forms за сложни случаи: персонализирани валидатори, асинхронна проверка, динамични правила. Flutter Web и мобилната версия използват един и същ API, което опростява поддръжката.

// Пример за валидация на формуляр в 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'),
            ),
        ],
    ),
)

Техники и инструменти за валидация

Съвременните фреймуъркове предоставят вградени валидатори, които покриват 80% от потребностите. Останалите 20% изискват персонализирани правила, регулярни изрази или комбинация от съществуващите. Ключовият принцип — валидацията трябва да е декларативна, за да може лесно да се чете, тества и поддържа. Избягвайте логиката за валидация, разпръсната по контролерите и екраните — извадете я в отделни класове или схеми.

Подходи White-list vs Black-list

White-list (бял списък) — определяте кои данни са разрешени, всичко останало се отхвърля. Black-list — определяте кои данни са забранени, всичко останало се пропуска. White-list винаги е по-надеждна: точно знаете кои данни ще преминат. Black-list изисква да се предвидят всички възможни атаки, което е невъзможно. Пример: при проверка на възрастта използвайте white-list (само числа от 18 до 120), а не black-list (забрана на „0“, „-1“, „999999“).

Регулярните изрази — мощ и опасност

Регулярните изрази са ефективен инструмент за форматна валидация, но могат да бъдат източник на ReDoS атаки (Regular Expression Denial of Service). Някои модели (например (a+)+b) водят до катастрофален backtracking върху дълги низове, напълно натоварвайки процесора на сървъра. Използвайте проверени regex библиотеки и ограничавайте дължината на низа преди прилагането на регулярния израз. За сложни случаи (имейл, URL) използвайте вградените анализатори на езиците, а не собствени регулярни изрази.

Типични грешки при валидация

Дори опитни разработчици допускат грешки при реализацията на валидацията. Най-честите: валидация само на клиента, твърде строги правила (парола „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters“), неинформативни съобщения за грешки ("Error: invalid input") и игнориране на крайните случаи (интервали в началото/края, Unicode знаци, празни низове). Всяка от тези грешки влошава UX и може да намали конверсията на формулярите.

• Само клиентска валидация — най-опасната грешка: всяка заявка може да бъде фалшифицирана чрез Postman или cURL
• Твърде строги правила — отблъскват потребителите: OWASP препоръчва минимални изисквания при регистрация
• Игнориране на Unicode — проверката на дължината на низа в байтове (а не в знаци) чупи българския, китайския, емотиконите
• Неинформативни грешки — „Invalid format“ вместо „Email must contain @ symbol after local part“
• Проверка на празното поле — if (value) не различава празния низ от нула, false или „0“

Най-добрата практика — централизирана система за валидация, покрита с unit тестове. Всяко правило трябва да се тества отделно: гранични стойности, коректни данни, типични атаки (опити за SQLi, XSS payloads, много дълги низове). Регресионните тестове за валидация предотвратяват случайното отслабване на правилата при рефакторинг. Използвайте property-based testing (QuickCheck, fast-check) за генериране на случайни данни и проверка, че валидацията не се срива с изключение.