Mobil uygulamalarda girdi doğrulama — temeller, denetim yöntemleri ve uygulama

Girdi doğrulama nedir?

Girdi doğrulama, bir kullanıcıdan, harici hizmetten veya başka bir bileşenden uygulamaya gelen verilerin beklenen ölçütlere uygun olup olmadığının kontrolüdür. Bu ölçütler veri türünü (dize, sayı, tarih), biçimi (e-posta, URL, telefon), değer aralığını (18 ile 120 arası yaş), uzunluğu (8 ile 128 karakter arası parola) ve izin verilen karakterleri (yalnızca Latin harfleri, rakamlar, kısa çizgi) içerir. Doğrulama olmadan uygulama, çalışma zamanı hatalarına, veri bozulmasına veya güvenlik açıklarına neden olan verileri işleyebilir.

Doğrulama neden kritik bir güvenlik unsurudur?

Girdi doğrulamanın olmaması, SQL Injection, XSS, Command Injection, Path Traversal ve Buffer Overflow gibi güvenlik açıklarının kök nedenidir. MITRE CWE (2025) verilerine göre CWE-20 (Improper Input Validation), en tehlikeli yazılım hataları sıralamasında ikinci sıradadır. Doğrulama, Defense in Depth güvenlik modelindeki ilk savunma hattıdır: hatalı verileri sistemin diğer bileşenlerine ulaşmadan keser.

Doğrulama vs Temizleme

Doğrulama, ölçütlere uymayan verileri reddeder. Temizleme (arındırma), tehlikeli kısımları kaldırarak veya kaçışlayarak verileri değiştirir. Örneğin HTML içerik girildiğinde doğrulama metnin uzunluğunu kontrol edebilir, temizleme ise HTML Purifier veya DOMPurify kitaplığıyla script etiketlerini kaldırabilir. Temizleme doğrulamanın yerini almaz: birlikte çalışırlar. Doğrulama "izinli/yasak" politikasıdır, temizleme ise "kullanımdan önce temizlenmiş"tir.

Girdi doğrulama türleri

Doğrulama, denetimin derinliğine göre sınıflandırılır. Biçim doğrulaması en basit ve hızlı olanıdır, iş doğrulaması ise en karmaşık ve bağlama bağımlı olanıdır. Üç düzey de sırayla uygulanmalıdır: önce biçim, sonra anlambilim, sonra iş mantığı. Herhangi bir düzeyi atlamak sistemin yanlış çalışmasına veya güvenlik açıklarına yol açabilir.

Biçim doğrulaması

Veri türü, boyut, biçim ve izin verilen karakterlerin kontrolü. Düzenli ifadeler, dillerin yerleşik türleri ve doğrulama kitaplıkları aracılığıyla uygulanır. Örnekler: UUID kontrolü (8-4-4-4-12 onaltılık basamak biçimi), telefon numarası kontrolü (yalnızca rakamlar, başında +, 7 ile 15 karakter), tam sayı kontrolü (Integer.MIN_VALUE — Integer.MAX_VALUE aralığında değer). Biçim doğrulaması, herhangi bir girdi alanı için minimum gereken düzeydir.

Anlamsal doğrulama

Verilerin etki alanı bağlamında mantıksal doğruluğunun kontrolü. Örneğin: başlangıç tarihi bitiş tarihinden sonra değil, yaş sistem için makul sınırlar içinde, koordinatlar hizmet alanı içinde. Anlamsal doğrulama, iş bağlamının anlaşılmasını gerektirir ve yalnızca biçime göre yapılamaz. Örnek: "bilet sayısı" alanı biçim doğrulamasını geçebilir (tam sayı, > 0), ancak anlamsal olarak mevcut koltuk sayısını aşamaz.

İş doğrulaması

En karmaşık düzey — verilerin uygulamanın iş kurallarına uygunluğunun kontrolü. Örnekler: kullanıcı tek yöneticiyi silemez, sipariş tutarı kredi limitini aşmaz, ürün yalnızca stokta varsa sipariş edilebilir. İş doğrulaması genellikle veritabanı sorguları veya harici hizmetler gerektirir ve biçim ile anlamsal denetimlerden sonra yapılır. İş doğrulaması hataları, kullanıcı memnuniyetsizliğinin en sık nedenidir.

İstemci ve sunucu tarafı doğrulama

İstemci tarafı doğrulama (tarayıcıda veya mobil uygulamada) kullanıcı rahatlığı için gereklidir: verileri sunucuya göndermeden anında geri bildirim. Ancak sunucu tarafı doğrulama tek güvenilir olanıdır, çünkü istemci kodu her zaman atlanabilir. Geliştirici araçları, Postman veya bir proxy (Burp Suite) aracılığıyla istek gönderin — istemci tarafı doğrulama ortadan kalkar. PortSwigger Research (2025) verilerine göre test edilen web uygulamalarının %90'ından fazlası en az bir alan için yalnızca istemci tarafı doğrulamaya güvenir.

Kural: istemci UX için, sunucu güvenlik için

İstemci tarafı doğrulama, gönder düğmesini devre dışı bırakabilir, hataları vurgulayabilir ve ipuçları gösterebilir. Sunucu tarafı doğrulama, istemci zaten kontrol etmiş olsa bile her parametrenin zorunlu denetimidir. Her iki düzeyde doğrulamanın tekrarlanması standart bir uygulamadır. Sunucu, verileri istemci yokmuş gibi kontrol etmelidir. Bu, değiştirilmiş isteklere, otomatik saldırılara ve kötü niyetli istemcilere karşı korumayı garanti eder.

İstemci tarafı doğrulamanın uygulanması

Web'de — HTML5 öznitelikleri (required, pattern, min/max, type="email") ve JavaScript. Mobil uygulamalarda — metin alanlarının yerel doğrulayıcıları (Android'de InputFilter, iOS'ta textField(:shouldChangeCharactersIn:)). React için React Hook Form ve Formik, Vue için Vuelidate, Angular Reactive Forms — istemci tarafı doğrulama için popüler kitaplıklar. Hepsi özel kuralları ve zaman uyumsuz doğrulamayı (sunucuda oturum açma adının benzersizliğini kontrol etme) destekler.

// Express ve Joi ile sunucu tarafı doğrulama örneği
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 — zaten doğrulanmış ve güvenli veriler
    const user = await User.create(value);
    res.status(201).json(user);
});

Mobil uygulamalarda doğrulama

Mobil uygulamalar veri doğrulamaya özel gereksinimler getirir. Ekran daha küçüktür — hatalar öz olmalı, klavye bağlamsal olmalı (sayı girmek için sayısal) ve arayüzü engellememek için denetim zaman uyumsuz olmalıdır. Yerel platformlar, varsayılan olarak kullanılması gereken yerleşik doğrulama mekanizmaları sağlar. Android için Material Design Guidelines ve iOS için Human Interface Guidelines, doğrulama hatalarının görüntülenmesi hakkında ayrıntılı öneriler içerir.

Android'de doğrulama (Jetpack Compose)

Jetpack Compose, durum yönetimi aracılığıyla bildirimsel bir doğrulama yaklaşımı sunar. Her girdi alanı bir duruma (MutableState) bağlanır ve hata geçerli değere göre hesaplanır. Compose Validator kitaplığı kural oluşturmayı basitleştirir: required, email, min/max length, pattern. Doğrulama, metin değiştiğinde (onValueChange) veya form gönderilmeye çalışıldığında tetiklenir. Hatayı yalnızca ilk gönderimden sonra veya kullanıcı yazmayı bitirdikten sonra göstermek önerilir (debounce 300-500ms).

iOS'ta doğrulama (SwiftUI)

SwiftUI'da yerleşik form doğrulama mekanizması yoktur, ancak Combine ve özellik sarmalayıcıları aracılığıyla kolayca uygulanabilir. Alan değeri için @State, hata için hesaplanan bir özellik kullanın. ValidatedPropertyKit çerçevesi hazır dekoratörler sağlar: @Validated().email(), @Validated().range(18...120). iOS önerisi — giriş düzeyindeki hata sayısını azaltmak için klavye türlerini (UIKeyboardType.emailAddress, .numberPad) ve otomatik büyük harf kullanımını kullanın.

Flutter'da doğrulama

Flutter, doğrulayıcı geri çağrısı ile yerleşik doğrulamaya sahip Form ve TextFormField sınıflarını sağlar. Her alan, veriler doğruysa hatayı dize olarak veya null olarak döndürür. FormState.validate(), formun tüm alanlarının denetimini çalıştırır. Karmaşık durumlar için reactive_forms paketi: özel doğrulayıcılar, zaman uyumsuz denetim, dinamik kurallar. Flutter Web ve mobil sürüm aynı API'yi kullanır, bu da bakımı basitleştirir.

// Flutter'da form doğrulama örneği
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()) {
                        // Geçerli verileri işle
                    }
                },
                child: Text('Gönder'),
            ),
        ],
    ),
)

Doğrulama teknikleri ve araçları

Modern çerçeveler, ihtiyaçların %80'ini karşılayan yerleşik doğrulayıcılar sağlar. Kalan %20, özel kurallar, düzenli ifadeler veya mevcut kuralların birleştirilmesini gerektirir. Temel ilke, doğrulamanın bildirimsel olması gerektiğidir; böylece kolayca okunabilir, test edilebilir ve bakımı yapılabilir. Denetleyicilere ve ekranlara yayılmış doğrulama mantığından kaçının — onu ayrı sınıflara veya şemalara taşıyın.

White-list vs Black-list yaklaşımları

White-list (beyaz liste) — hangi verilerin izinli olduğunu tanımlarsınız; geri kalan her şey reddedilir. Black-list (kara liste) — hangi verilerin yasak olduğunu tanımlarsınız; geri kalan her şey kabul edilir. Beyaz liste her zaman daha güvenilirdir: hangi verilerin geçeceğini tam olarak bilirsiniz. Kara liste, olası tüm saldırıları öngörmeyi gerektirir, bu da imkansızdır. Örnek: yaşı kontrol ederken kara liste yerine ("0", "-1", "999999" yasakla) beyaz liste kullanın (yalnızca 18 ile 120 arası sayılar).

Düzenli ifadeler — güç ve tehlike

Düzenli ifadeler, biçim doğrulaması için etkili bir araçtır, ancak ReDoS saldırılarının (Regular Expression Denial of Service) kaynağı olabilirler. Bazı desenler (örneğin, (a+)+b) uzun dizelerde felaketle sonuçlanan geri izlemeye neden olur ve sunucunun CPU'sunu tamamen yükler. Kanıtlanmış regex kitaplıkları kullanın ve düzenli bir ifade uygulamadan önce dizenin uzunluğunu sınırlayın. Karmaşık durumlar (e-posta, URL) için kendi yaptığınız regex yerine dillerin yerleşik ayrıştırıcılarını kullanın.

Doğrulamada tipik hatalar

Deneyimli geliştiriciler bile doğrulama uygularken hatalar yapar. En sık görülenler: yalnızca istemcide doğrulama, çok katı kurallar (parola "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), bilgi vermeyen hata mesajları ("Error: invalid input") ve uç durumların göz ardı edilmesi (başta/sonda boşluklar, Unicode karakterler, boş dizeler). Bu hataların her biri UX'i kötüleştirir ve form dönüşümünü düşürebilir.

• Yalnızca istemci tarafı doğrulama — en tehlikeli hata: herhangi bir istek Postman veya cURL ile sahteleştirilebilir
• Çok katı kurallar — kullanıcıları uzaklaştırır: OWASP kayıt sırasında minimum gereksinimleri önerir
• Unicode'u yok sayma — dizenin uzunluğunu karakter cinsinden değil bayt cinsinden kontrol etmek Rusça, Çince ve emojiyi bozar
• Bilgi vermeyen hatalar — "Email must contain @ symbol after local part" yerine "Invalid format"
• Boş alan kontrolü — if (value) boş dizeyi sıfırdan, false'tan veya "0"dan ayırt etmez

En iyi uygulama, birim testleriyle kapsanan merkezi bir doğrulama sistemidir. Her kural ayrı ayrı test edilmelidir: sınır değerler, doğru veriler, tipik saldırılar (SQLi denemeleri, XSS yükleri, çok uzun dizeler). Doğrulama üzerindeki regresyon testleri, yeniden düzenleme sırasında kuralların kazara zayıflatılmasını önler. Rastgele veri üretmek ve doğrulamanın bir özel durumla başarısız olmadığını doğrulamak için özellik tabanlı testler (QuickCheck, fast-check) kullanın.