Form Doğrulamayı Neden Hem İstemcide Hem Sunucuda Yapmalısınız?

Form doğrulama konusunda sahada en sık gördüğümüz hata, iki farklı amacı tek bir işmiş gibi ele almaktır. İstemci tarafındaki kontrol kullanıcıya anında geri bildirim vermek içindir; sunucu tarafındaki denetim ise sistemin bütünlüğünü korumak için vardır. Bunlar birbirinin alternatifi değil, tamamlayıcısıdır — ve ikisinden birini atlamak, farklı ama gerçek bir maliyet doğurur.

İstemci kontrolü neden güvenlik sağlamaz?

Tarayıcıda çalışan hiçbir kod güvenilir değildir. Kullanıcı geliştirici araçlarını açıp required özniteliğini silebilir, JavaScript'i devre dışı bırakabilir veya formu hiç kullanmadan doğrudan uca istek gönderebilir. curl ile atılan tek satırlık bir istek, sizin özenle yazdığınız tüm istemci kontrollerini görmezden gelir. Bu yüzden istemcideki kontrolü bir kapı kilidi değil, kapıdaki "lütfen ayakkabılarınızı çıkarın" tabelası gibi düşünmek gerekir: iyi niyetli kullanıcıya yardımcı olur, kötü niyetliyi durdurmaz.

Bu, güvenlik açıklarının en klasik kaynaklarından biridir; sahada en sık rastlanan diğer açıklar için web uygulama güvenliği yazımıza bakmanızı öneririz.

Sunucu denetimi neden tek başına yetmez?

Tersi de doğrudur. Yalnızca sunucuda kontrol yapan bir formda kullanıcı, sekiz alanı doldurup gönder tuşuna bastıktan sonra sayfanın yeniden yüklenmesini bekler ve ancak o zaman "parola en az 10 karakter olmalı" uyarısını görür. Bu döngü hem yavaştır hem de terk oranını artırır. Kullanıcının hatayı, hatayı yaptığı anda ve yaptığı alanın yanında görmesi gerekir.

Katmanlı kurgunun pratik hâli

İşleyen bir düzen üç katmandan oluşur:

1. HTML5 ve JavaScript (istemci): type="email", minlength, pattern gibi yerleşik özniteliklerle başlayın; yerleşik denetim erişilebilirlik açısından da avantajlıdır çünkü ekran okuyucular bunları anlar. Karmaşık kurallar için JavaScript ekleyin, ancak yerleşik olanı gereksiz yere devre dışı bırakmayın.
2. Uygulama katmanı (sunucu): Gelen her alanı, istemcide ne yazdığınızdan bağımsız olarak yeniden doğrulayın. Burası tek gerçek otoritedir. Framework'ünüzün hazır kütüphanesini kullanın; elle yazılmış if yığınları zamanla tutarsızlaşır.
3. Veritabanı (son savunma): NOT NULL, UNIQUE, uzunluk ve CHECK kısıtları, uygulama katmanındaki bir hatanın veriyi kalıcı olarak bozmasını engeller. Bu kısıt, kodunuzdaki her yol için ayrı ayrı düşünmek zorunda kalmadan bütünlük garantisi verir.

Sunucuda mutlaka yeniden doğrulanması gerekenler

Bazı alanlar özellikle risklidir çünkü istemciden gelen değer doğrudan bir yetki veya fiyat kararına dönüşür:

• Gizli alanlar ve seçim listeleri: <select> içindeki seçenekler istemcide değiştirilebilir. Gelen değerin izin verilen kümede olduğunu sunucuda kontrol edin.
• Fiyat, indirim, adet: Tutarı asla istemciden gelen değere güvenerek hesaplamayın; ürün fiyatını sunucuda veritabanından okuyun.
• Kimlik ve sahiplik alanları: user_id gibi alanlar istekten değil, oturumdan alınmalıdır. Aksi hâlde klasik bir yetki aşımı (IDOR) açığı doğar.
• Dosya yüklemeleri: Uzantı ve MIME tipi istemcide kolayca taklit edilir; sunucuda içerik imzasına bakmak gerekir.

Aynı doğrulama disiplini API uçları için de geçerlidir — hatta orada tek katman zaten sunucudur. API tasarımında girdi doğrulama ve hata sözleşmesi için REST API tasarım rehberimiz iyi bir başlangıç noktasıdır.

Kuralları iki yerde tutmanın tuzağı ve çözümü

Katmanlı yapının en can sıkıcı yan etkisi, aynı kuralın iki yerde yazılmasıdır: parola uzunluğu istemcide 10, sunucuda 8 kalır ve kullanıcı neden reddedildiğini anlamaz. Bu tutarsızlığı önlemenin birkaç pratik yolu var. En temizi, kuralları tek bir kaynakta tanımlayıp istemciye veri olarak aktarmaktır — örneğin sunucudaki kural tanımlarından üretilen bir JSON'u forma gömmek. Daha basit projelerde ise kuralları tek bir yapılandırma dosyasında toplamak ve iki tarafta da oradan okumak yeterlidir. En azından, iki taraftaki kuralları aynı gözden geçirme sırasında güncellemeyi ekip kuralı hâline getirin.

Tarayıcı tarafındaki yerleşik doğrulama API'sinin ayrıntıları için MDN form doğrulama rehberi kapsamlı bir kaynaktır.

Hata mesajlarını yazarken

Bu, ön yüz tarafında sıkça göz ardı edilen bir kalite kalemidir; genel bir çerçeve için web geliştirme yol haritamıza bakabilirsiniz. İyi bir hata mesajı üç şeyi yapar: neyin yanlış olduğunu söyler, nerede olduğunu gösterir ve nasıl düzeltileceğini anlatır. "Geçersiz giriş" bunların hiçbirini yapmaz. "Telefon numarası 10 haneli olmalı, başında 0 olmadan yazın" üçünü de yapar. Ayrıca mesajları alanın hemen yanında ve aria-describedby ile ilişkilendirilmiş şekilde göstermek, ekran okuyucu kullanan kullanıcılar için farkı büyüktür.

Sonuç

Form doğrulama tek bir iş değil, farklı amaçlara hizmet eden iki ayrı iştir: istemci tarafı deneyimi hızlandırır, sunucu tarafı sistemi korur, veritabanı kısıtları ise son ağ görevi görür. Bu üç katmanı birbirinin yerine koymak, ya kullanıcıyı yoran ya da sistemi savunmasız bırakan sonuçlar üretir. Projenizde hızlı bir kontrol yapın: istemcideki doğrulamayı devre dışı bırakıp formu gönderdiğinizde sunucu aynı hatayı yakalıyor mu? Cevap hayırsa, kapatılması gereken bir açığınız var demektir.