Mobil proqramlarda giriş məlumatlarının yoxlanılması — əsaslar, yoxlama metodları və reallaşdırma

Giriş məlumatlarının yoxlanılması nədir?

Giriş məlumatlarının yoxlanılması — istifadəçidən, xarici xidmətdən və ya digər komponentdən proqrama daxil olan məlumatların gözlənilən meyarlara uyğunluğunun yoxlanmasıdır. Bu meyarlara məlumat tipi (sətir, rəqəm, tarix), format (email, URL, telefon), dəyər diapazonu (yaş 18-dən 120-dək), uzunluq (parol 8-dən 128 simvoladək) və icazə verilən simvollar (yalnız latın hərfləri, rəqəmlər, defis) daxildir. Validasiya olmadan proqram icra xətalarına, məlumatların zədələnməsinə və ya təhlükəsizlik zəifliklərinə səbəb ola biləcək məlumatları emal edə bilər.

Validasiya nə üçün təhlükəsizliyin kritik elementi hesab olunur?

Giriş məlumatları validasiyasının olmaması SQL Injection, XSS, Command Injection, Path Traversal və Buffer Overflow kimi zəifliklərin kök səbəbidir. MITRE CWE (2025)-in məlumatına görə, CWE-20 (Improper Input Validation) ən təhlükəli proqram xətaları reytinqində ikinci yeri tutur. Validasiya Defense in Depth təhlükəsizlik modelində ilk müdafiə xəttidir: o, səhv məlumatları sistemin digər komponentlərinə çatmamış kəsir.

Validasiya vs Sanitizasiya

Validasiya meyarlara uyğun gəlməyən məlumatları rədd edir. Sanitizasiya (təmizləmə) təhlükəli hissələri silmək və ya kodlaşdırmaqla məlumatları dəyişdirir. Məsələn, HTML-məzmun daxil edilərkən validasiya mətnin uzunluğunu yoxlaya bilər, sanitizasiya isə HTML Purifier və ya DOMPurify kitabxanası vasitəsilə script-teqlərini silə bilər. Sanitizasiya validasiyanı əvəz etmir: onlar birlikdə işləyirlər. Validasiya "icazə verilib/qadağan olunub" siyasətidir, sanitizasiya isə "istifadədən əvvəl təmizlənib".

Giriş məlumatları validasiyasının növləri

Validasiya yoxlamanın dərinliyinə görə təsnifləşdirilir. Format validasiyası ən sadə və ən sürətlidir, biznes validasiyası isə ən mürəkkəb və kontekstdən asılıdır. Hər üç səviyyə ardıcıl tətbiq edilməlidir: əvvəlcə format, sonra semantika, daha sonra biznes-məntiq. Hər hansı səviyyənin buraxılması sistemin düzgün işləməməsinə və ya zəifliyə səbəb ola bilər.

Format validasiyası

Məlumat tipinin, ölçüsünün, formatının və icazə verilən simvolların yoxlanması. Nizamlı ifadələr, dillərin daxili tipləri və validasiya kitabxanaları vasitəsilə həyata keçirilir. Nümunələr: UUID-nin yoxlanması (8-4-4-4-12 hexadecimal rəqəm formatı), telefon nömrəsinin yoxlanması (yalnız rəqəmlər, əvvəlində +, 7-dən 15 simvoladək), tam ədədin yoxlanması (Integer.MIN_VALUE — Integer.MAX_VALUE diapazonunda dəyər). Format validasiyası istənilən giriş sahəsi üçün minimum tələb olunan səviyyədir.

Semantik validasiya

Məlumatların predmet sahəsi kontekstində məntiqi düzgünlüyünün yoxlanması. Məsələn: başlama tarixi bitmə tarixindən gec deyil, yaş sistem üçün məqbul hədlərdədir, koordinatlar xidmət ərazisindədir. Semantik validasiya biznes kontekstinin dərk edilməsini tələb edir və yalnız format əsasında həyata keçirilə bilməz. Nümunə: "bilet sayı" sahəsi format yoxlamasından keçə bilər (tam ədəd, > 0), lakin semantik olaraq boş yerlərin sayından çox ola bilməz.

Biznes validasiya

Ən mürəkkəb səviyyə — məlumatların proqramın biznes qaydalarına uyğunluğunun yoxlanması. Nümunələr: istifadəçi yeganə administratoru silə bilməz, sifariş məbləği kredit limitini keçmir, məhsul yalnız mövcuddursa sifariş edilə bilər. Biznes validasiya çox vaxt verilənlər bazası sorğularını və ya xarici xidmətləri tələb edir və format ilə semantik yoxlamalardan sonra yerinə yetirilir. Biznes validasiya səhvləri istifadəçilərin narazılığının ən geniş yayılmış səbəbidir.

Müştəri və server validasiyası

Müştəri tərəfli validasiya (brauzerdə və ya mobil proqramda) istifadəçi rahatlığı üçün lazımdır: məlumatları serverə göndərmədən ani rəy bildirişi. Lakin server validasiyası yeganə etibarlıdır, çünki müştəri kodu həmişə yan keçilə bilər. Sorğuları tərtibatçı alətləri, Postman və ya proksi (Burp Suite) vasitəsilə göndərin — müştəri validasiyası artıq mövcud olmayacaq. PortSwigger Research (2025)-in məlumatına görə, sınaqdan keçirilmiş veb-proqramların 90%-dən çoxu ən azı bir sahə üçün yalnız müştəri validasiyasına etibar edir.

Qayda: müştəri — UX üçün, server — təhlükəsizlik üçün

Müştəri validasiyası göndərmə düyməsini söndürə, xətaları vurğulaya, ipucları göstərə bilər. Server validasiyası hər bir parametrin məcburi yoxlanmasıdır, hətta müştəri artıq onu yoxlasa belə. Hər iki səviyyədə validasiyanın təkrarlanması standart təcrübədir. Server məlumatları elə yoxlamalıdır ki, sanki müştəri mövcud deyil. Bu, dəyişdirilmiş sorğulardan, avtomatlaşdırılmış hücumlardan və zərərli müştərilərdən qorunmağa zəmanət verir.

Müştəri validasiyasının reallaşdırılması

Vebdə — HTML5 atributları (required, pattern, min/max, type="email") və JavaScript. Mobil proqramlarda — mətn sahələrinin native validasiyaları (Android-də InputFilter, iOS-da textField(:shouldChangeCharactersIn:)). React üçün React Hook Form və Formik, Vue üçün Vuelidate, Angular Reactive Forms — müştəri validasiyası üçün məşhur kitabxanalardır. Onların hamısı xüsusi qaydaları və asinxron validasiyanı (serverdə loqinin unikallığının yoxlanması) dəstəkləyir.

// Express və Joi ilə server validasiyası nümunəsi
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 — artıq yoxlanmış və təhlükəsiz məlumatlar
    const user = await User.create(value);
    res.status(201).json(user);
});

Mobil proqramlarda validasiya

Mobil proqramlar məlumat validasiyasına xüsusi tələblər irəli sürür. Ekran kiçikdir — xətalar yığcam olmalıdır, klaviatura kontekstli (rəqəm daxil etmək üçün rəqəmli), yoxlama isə UI-ni bloklamamaq üçün asinxron olmalıdır. Native platformalar defolt olaraq istifadə edilməli olan daxili validasiya mexanizmləri təqdim edir. Android üçün Material Design Guidelines və iOS üçün Human Interface Guidelines validasiya xətalarının göstərilməsi ilə bağlı ətraflı tövsiyələr ehtiva edir.

Android-də validasiya (Jetpack Compose)

Jetpack Compose state-idarəetmə vasitəsilə validasiyaya deklarativ yanaşma təklif edir. Hər giriş sahəsi vəziyyətlə (MutableState) əlaqələndirilir, xəta isə cari dəyər əsasında hesablanır. Compose Validator kitabxanası qaydaların yaradılmasını sadələşdirir: required, email, min/max length, pattern. Validasiya mətnin dəyişməsi (onValueChange) və ya formanın göndərilmə cəhdi zamanı işə düşür. Xətanın yalnız ilk göndərmədən sonra və ya istifadəçi daxil etməni bitirdikdən sonra (debounce 300-500ms) göstərilməsi tövsiyə olunur.

iOS-da validasiya (SwiftUI)

SwiftUI-nin formanın daxili validasiya mexanizmi yoxdur, lakin onu Combine və property wrappers vasitəsilə asanlıqla həyata keçirmək mümkündür. Sahənin dəyəri üçün @State, xəta üçün isə hesablanan xüsusiyyətdən istifadə edin. ValidatedPropertyKit freymvorku hazır dekoratorlar təqdim edir: @Validated().email(), @Validated().range(18...120). iOS tövsiyəsi — daxiletmə səviyyəsində xətaların sayını azaltmaq üçün klaviatura tiplərindən (UIKeyboardType.emailAddress, .numberPad) və auto-capitalization-dan istifadə edin.

Flutter-də validasiya

Flutter validator-kolbəki vasitəsilə daxili validasiyaya malik Form və TextFormField siniflərini təqdim edir. Hər sahə səhvi sətir kimi və ya məlumatlar düzgündürsə null qaytarır. FormState.validate() formanın bütün sahələrinin yoxlanmasını işə salır. Mürəkkəb hallar üçün reactive_forms paketi: xüsusi validasiyalar, asinxron yoxlama, dinamik qaydalar. Flutter Web və mobil versiyalar eyni API-dən istifadə edir ki, bu da dəstəkləməni sadələşdirir.

// Flutter-də forma validasiyası nümunəsi
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'),
            ),
        ],
    ),
)

Validasiya texnikaları və alətləri

Müasir freymvorklar ehtiyacların 80%-ni əhatə edən daxili validasiyalar təqdim edir. Qalan 20% xüsusi qaydalar, nizamlı ifadələr və ya mövcudların kompozisiyasını tələb edir. Əsas prinsip — validasiya deklarativ olmalıdır ki, onu asanlıqla oxumaq, test etmək və saxlamaq mümkün olsun. Kontrollerlər və ekranlar üzrə yayılmış validasiya məntiqindən qaçının — onu ayrıca siniflərə və ya sxemlərə çıxarın.

White-list vs Black-list yanaşmaları

White-list (ağ siyahı) — hansı məlumatların icazəli olduğunu müəyyən edirsiniz, qalan hər şey rədd edilir. Black-list — hansı məlumatların qadağan olduğunu müəyyən edirsiniz, qalan hər şey buraxılır. White-list həmişə daha etibarlıdır: hansı məlumatların keçəcəyini dəqiq bilirsiniz. Black-list bütün mümkün hücumları qabaqcadan görməyi tələb edir, bu isə qeyri-mümkündür. Nümunə: yaşı yoxlayarkən white-list (yalnız 18-dən 120-dək rəqəmlər) istifadə edin, black-list deyil ("0", "-1", "999999" qadağan etmək).

Nizamlı ifadələr — güc və təhlükə

Nizamlı ifadələr format validasiyası üçün effektiv alətdir, lakin onlar ReDoS-hücumlarının (Regular Expression Denial of Service) mənbəyi ola bilər. Bəzi nümunələr (məsələn, (a+)+b) uzun sətirlərdə katastrofik backtracking-ə gətirib çıxarır və serverin CPU-sunu tam yükləyir. Sınaqdan keçmiş regex-kitabxanalarından istifadə edin və nizamlı ifadəni tətbiq etməzdən əvvəl sətrin uzunluğunu məhdudlaşdırın. Mürəkkəb hallar üçün (email, URL) öz nizamlı ifadələrinizi yazmaq əvəzinə dillərin daxili parserlərindən istifadə edin.

Validasiya zamanı tipik səhvlər

Hətta təcrübəli tərtibatçılar da validasiyanın reallaşdırılmasında səhv edirlər. Ən geniş yayılmışlar: yalnız müştəri tərəfli validasiya, həddən artıq sərt qaydalar (parol "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), məlumatlı olmayan xəta mesajları ("Error: invalid input") və edge-case-lərin (əvvəlində/sonunda boşluqlar, Unicode simvolları, boş sətirlər) nəzərə alınmaması. Bu səhvlərin hər biri UX-i pisləşdirir və formaların konversiyasını aşağı sala bilər.

• Yalnız müştəri validasiyası — ən təhlükəli səhv: istənilən sorğu Postman və ya cURL vasitəsilə saxtalaşdırıla bilər
• Həddən artıq sərt qaydalar — istifadəçiləri uzaqlaşdırır: OWASP qeydiyyat zamanı minimum tələbləri tövsiyə edir
• Unicode-un nəzərə alınmaması — sətrin uzunluğunun simvollar deyil, baytlarla yoxlanması azərbaycanca, çincə, emoji simvollarını pozur
• Məlumatlı olmayan xətalar — "Invalid format" əvəzinə "Email must contain @ symbol after local part"
• Boş sahənin yoxlanması — if (value) boş sətri sıfırdan, false-dan və ya "0"-dan ayırmır

Ən yaxşı təcrübə — unit-testlər ilə əhatə olunmuş mərkəzləşdirilmiş validasiya sistemidir. Hər qayda ayrıca test edilməlidir: sərhəd dəyərləri, düzgün məlumatlar, tipik hücumlar (SQLi-cəhdləri, XSS-payloads, çox uzun sətirlər). Validasiya üzrə reqressiya testləri refaktoring zamanı qaydaların təsadüfən zəiflədilməsinin qarşısını alır. Təsadüfi məlumatlar yaratmaq və validasiyanın istisna ilə çökmədiyini yoxlamaq üçün property-based testing-dən (QuickCheck, fast-check) istifadə edin.