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

Шта је валидација улазних података?

Валидација улазних података је провера да подаци који стижу у апликацију од корисника, спољног сервиса или друге компоненте одговарају очекиваним критеријумима. Ови критеријуми укључују тип података (ниска, број, датум), формат (имејл, 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: одсеца неисправне податке пре него што стигну до других компоненти система.

Валидација наспрам санитизације

Валидација одбија податке који не испуњавају критеријуме. Санитизација (чишћење) мења податке, уклањајући или енкодујући опасне делове. На пример, при уносу 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) и auto-capitalization да смањите број грешака на нивоу уноса.

Валидација на Flutter-у

Flutter пружа класу Form и TextFormField са уграђеном валидацијом кроз validator повратни позив. Свако поље враћа грешку као ниску или 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 наспрам 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) доводе до катастрофалног бецктрацкинга на дугим нискама, потпуно оптерећујући процесор сервера. Користите проверене 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 тестирање (QuickCheck, fast-check) за генерисање насумичних података и проверу да валидација не пада са изузетком.