Çoğu işletme sahibi girdi doğrulamayı "formda yıldız işareti koyduk, boş bırakılamıyor" diye anlar. Zorunlu alan işaretlemek doğrulama değil; sadece kullanıcıya nezaket göstermektir. Senin panelinde gerçek risk, boş bırakılan alanda değil; beklenmeyen bir değerle dolduruldığında hiçbir yerin itiraz etmediği alanda saklanır. Bir e-pin satış scriptinde tutar, adet, kupon kodu, bakiye referansı ve sipariş kimliği gibi alanlar sadece görüntülenmez; arka planda hesap yapar, stok düşer, kod teslim eder.
Sahadaki tablo şu: dijital ürün satan panellerde yaşanan zararların büyük kısmı egzotik bir sıfır gün açığından değil, tarayıcıdan gelen veriye fazla güvenmekten doğar. Saldırgan sistemi kırmaz; sistemin kendi mantığını kendisine karşı kullanır. 10 adet yerine -3 adet yazar, 250 TL yerine 2,5 yazar, aynı kuponu 40 kez gönderir. Bu yazıda bir e-pin scriptinde girdi doğrulamayı tek tek yamalarla değil, disiplin olarak nasıl kuracağını konuşacağız. Çünkü yama biter, disiplin kalır.
Çoğu e-pin scripti girdiyi neden sadece "temizlemekle" yetinir?
Hazır bir dijital ürün satış scripti aldığında içinde mutlaka bir temizleme fonksiyonu bulursun: tırnakları kaçırır, etiketleri söker, boşlukları kırpar. Bu iyidir ama eksiktir. Temizleme, verinin zararsız görünmesini sağlar; doğrulama ise verinin anlamlı olmasını sağlar. "abc" metni tırnaksız ve etiketsizdir, yani tertemizdir; ama adet alanına yazıldığında hiçbir anlamı yoktur. Tertemiz bir saçmalık, kirli bir gerçekten daha tehlikelidir çünkü kontrolden geçmiş gibi görünür.
İkinci sorun sıralamadır. Pek çok e-pin yazılımında veri önce kullanılır, sonra kontrol edilir. Sipariş satırı açılır, stok rezerve edilir, ardından tutar kontrolü yapılır. Araya bir hata düşerse ortada yarım kalmış, sahibi belirsiz bir kayıt durur. Doğru sıra tektir: doğrula, sonra dokun. Bir değer kuralı geçmediyse veritabanına hiç yaklaşmamalı. Pinova'da bu yaklaşımı bir alışkanlık olarak kurgulamak, sonradan onlarca istisna yazmaktan çok daha az emek ister.
Hangi alanlar gerçekten tehlikeli? Önce sırala, sonra kilitle
Bütün alanlar eşit değildir. Müşterinin adı yanlış yazılırsa kimse zarar görmez; tutar yanlış yazılırsa kasadan para çıkar. Bu yüzden ilk iş bir risk envanteri çıkarmaktır. Panelindeki her formu aç, her alanı üç soruyla işaretle: bu değer para ile mi çarpılıyor, stoktan mı düşüyor, başka bir kaydın kimliği mi? Üç sorudan birine "evet" diyen her alan yüksek risklidir ve en az iki katmanda doğrulanmalıdır.
Envanteri çıkardığında şaşırtıcı bir şey görürsün: gerçekten kritik alan sayısı sandığından azdır. Onlarca alanın içinde beş ila yedi tanesi bütün riski taşır. Enerjini oraya yığdığında, geri kalan alanlar için genel kurallar yeter. Bu, güvenlik bütçesini akıllı harcamanın en kısa yoludur. Aşağıdaki tablo, tipik bir e-pin satış scriptinde bu alanların nasıl haritalandığını gösteriyor.
| Alan | Görünen İşlev | Gerçek Risk | Uygulanacak Kural |
|---|---|---|---|
| adet | Kaç kod alınacak | Negatif veya ondalık değerle bedava stok | Tam sayı, 1 ile stok üst sınırı arası |
| tutar | Ödenecek bedel | İstemciden gelen fiyatla eksik ödeme | Asla istemciden alınmaz, sunucuda hesaplanır |
| kupon_kodu | İndirim | Tekrar kullanım ve deneme saldırısı | Beyaz liste karakter seti + kullanım sayacı |
| urun_id | Hangi ürün | Yetkisiz veya pasif ürüne erişim | Sayısal + aktiflik ve bayi yetkisi kontrolü |
| bakiye_referans | Cüzdan işlemi | Başka kullanıcının kaydını hedefleme | Sahiplik doğrulaması zorunlu |
| dosya (toplu kod) | Stok yükleme | Bozuk satır, çift kayıt, bellek tükenmesi | Uzantı + satır biçimi + boyut sınırı |
| iletisim_eposta | Teslim adresi | Başlık enjeksiyonu, yanlış teslim | Biçim doğrulama + tek satır zorunluluğu |
Beyaz liste mi, kara liste mi? Bu tercih bütün savunmayı belirler
Kara liste yaklaşımı "şu karakterler yasak" der. Kulağa pratik gelir, pratikte kaybeder. Çünkü yasaklar listesi her zaman eksiktir; saldırgan senin listende olmayan bir biçimi bulmak için sadece zamana ihtiyaç duyar. Beyaz liste ise "sadece şunlar serbest" der. Bu, savunmayı sonsuz bir ihtimal avından sonlu bir tanım işine indirir.
Uygulaması da düşündüğünden basittir. Kupon kodun büyük harf ve rakamdan oluşuyorsa kuralın bir satırdır. Sipariş kimliği sayısalsa kuralın bir satırdır. Ürün kodun belirli bir kalıba uyuyorsa kuralın bir satırdır. Beyaz liste, iş kuralını yazıya dökmeye zorladığı için aynı zamanda dokümantasyon üretir. Bir epin yazılım projesinde altı ay sonra "bu alan ne kabul ediyordu" sorusuna cevap veren tek şey genellikle bu kurallardır.
Tutar ve adet alanı: sepetteki sessiz kâr sızıntısı
Bir dijital ürün satış yazılımında en pahalı hata, fiyatı tarayıcıdan kabul etmektir. Gizli bir alanda taşınan tutar, bir sepet özetinde gösterilen ara toplam, kampanya hesabı için taşınan indirim oranı — bunların hiçbiri güvenilir veri değildir. Kural nettir: istemci sadece neyi istediğini söyler, kaça istediğini sunucu söyler. Fiyatı her zaman ürün kaydından, kampanyayı her zaman kampanya kaydından oku.
Adet alanı ise sessiz sızıntının ta kendisidir. Negatif adet, bazı hesap akışlarında bakiye artıran bir işleme dönüşebilir. Ondalıklı adet, stok düşümünde yuvarlama farkı yaratır. Çok büyük adet, hem stok hem de bellek tarafında beklenmedik davranışa yol açar. Üç kuralla kapanır: tam sayıya zorla, alt sınırı 1 yap, üst sınırı hem stoktan hem de iş kuralından gelen en küçük değere bağla. Bunu tek bir merkezî fonksiyonda topla; her sipariş noktasına ayrı ayrı yazarsan biri mutlaka atlanır.
Girdi kaynaklı olayların dağılımı
- Tutar ve adet manipülasyonu 45%
- Kupon ve promosyon suistimali 25%
- Kimlik/ID üzerinden yetkisiz erişim 20%
- Dosya ve toplu yükleme hataları 10%
Dosya ve toplu yükleme: e-pin havuzunu kirleten kapı
Toplu kod yükleme, bir e-pin scriptinin en çok sevilen ama en az denetlenen özelliğidir. Tedarikçiden gelen dosyayı panele atarsın, binlerce kod havuza girer. Sorun şu ki o dosya senin yazmadığın bir veri kaynağıdır. İçinde kopyalanmış satır, görünmez karakter, yanlış ayırıcı, bitmemiş son satır olabilir. Bu satırlar teslimat anında "geçersiz kod" olarak müşterinin karşısına çıkar ve ödediğin bedel para değil itibar olur.
Doğru akış üç aşamalıdır: ön izleme, doğrulama, işleme. Dosya yüklendiğinde hiçbir kayıt açılmadan kaç satır okunduğu, kaçının biçime uyduğu, kaçının havuzda zaten var olduğu ekranda gösterilir. Onay verdiğinde sadece geçerli satırlar tek bir işlem bütünlüğü içinde yazılır. Böylece yarı yüklenmiş stok diye bir şey olmaz. Bir de boyut ve satır sayısı sınırı koy; sınırsız kabul eden bir yükleyici, kötü niyet olmadan bile sunucunu yorar.
Doğrulama disiplinini panelde nasıl kurumsallaştırırsın?
Disiplin, tek tek geliştiricilerin dikkatine bırakıldığında dağılır. Bu yüzden doğrulamayı merkezî bir katmana taşımak gerekir: her istek, iş mantığına ulaşmadan önce kendi kural setinden geçer. Yeni bir uç nokta eklediğinde kuralı yazmadan çalışmaz. Bu "kural yoksa geçemez" yaklaşımı, unutmayı sistemsel olarak imkânsız kılar.
İkinci adım gözlemdir. Doğrulamada takılan her istek bir sinyaldir. Aynı kullanıcıdan dakikada onlarca kural ihlali geliyorsa bu bir kullanım hatası değil, bir deneme saldırısıdır. Bu sinyalleri sayıp eşiğe bağladığında hız sınırlama ve geçici kilit gibi önlemler kendiliğinden anlam kazanır. Pinova ile çalışan işletmelerde en çok işe yarayan pratik de bu oluyor: kuralları merkezde topla, ihlalleri say, eşiği aşanı yavaşlat. Aşağıdaki kontrol listesi bu yapıyı adım adım kurmanı sağlar.
| # | Kontrol | Nasıl Test Edilir | Durum |
|---|---|---|---|
| 1 | Fiyat istemciden alınmıyor | Sepette tutarı değiştirip sipariş dene | Zorunlu |
| 2 | Adet tam sayı ve sınırlı | -1 ve 1.5 değerleriyle dene | Zorunlu |
| 3 | Tüm kimlik alanlarında sahiplik kontrolü | Başka kullanıcının kayıt numarasını gönder | Zorunlu |
| 4 | Kupon beyaz liste + kullanım sayacı | Aynı kuponu iki kez uygula | Zorunlu |
| 5 | Toplu yüklemede ön izleme | Bozuk satır içeren dosya yükle | Yüksek |
| 6 | Hız sınırlama ve eşikli kilit | Formu hızlı ardışık gönder | Yüksek |
| 7 | Doğrulama ihlalleri kaydediliyor | Kasıtlı hatalı istek sonrası kayıtlara bak | Orta |
| 8 | Hata mesajları teknik detay sızdırmıyor | Hatalı girdi çıktısını oku | Orta |
Bir değer para ile çarpılıyorsa, stoktan düşüyorsa ya da bir kaydın kimliğini taşıyorsa o değer istemciden gelmez. Bu cümleyi panelindeki her forma uygula; risk envanterinin yarısı kendiliğinden kapanır.
Doğrulama disiplini kurulu bir altyapıyla başla
Sıfırdan kural yazmak yerine, merkezî doğrulama katmanı, stok ön izleme ve eşikli kilit mekanizmaları hazır gelen bir e-pin satış yazılımıyla yola çıkabilirsin. Özellikler ve fiyatlandırma sayfalarında ayrıntıları bulacaksın.
Girdi doğrulamayı sadece tarayıcı tarafında yapmak yeterli mi?
Hayır. Tarayıcıdaki kontroller kullanıcı deneyimi içindir ve tamamen atlanabilir. Her kural mutlaka sunucu tarafında tekrar edilmelidir; tarayıcı kontrolü sadece kullanıcıyı erken uyarır.
Beyaz liste yaklaşımı esnekliği azaltmaz mı?
Azaltmaz, netleştirir. İş kuralın zaten belli bir biçim bekliyordur. Beyaz liste bunu yazıya döker; kural değiştiğinde tek bir yerde güncellersin, tahmin oyununa girmezsin.
Toplu kod yüklemede en sık hangi hata görülür?
Çift kayıt ve görünmez karakter. Aynı kod iki kez havuza girdiğinde iki müşteriye teslim edilir. Yükleme öncesi tekillik kontrolü ve karakter temizliği bu sorunu tamamen ortadan kaldırır.
Doğrulama hatalarını kullanıcıya ne kadar detaylı göstermeliyim?
Kullanıcının düzeltebileceği kadar: hangi alan, hangi biçim bekleniyor. Veritabanı adı, sorgu metni veya dosya yolu gibi teknik bilgiler ekranda değil, yalnızca kendi kayıtlarında yer almalı.
Girdi doğrulama, panelinde göze görünmeyen ama her siparişte devreye giren bir sigortadır. Bugün ayıracağın iki saat, altı ay sonra yaşayacağın bir stok kaybını ya da bir müşteri şikâyetini baştan silecektir. Kuralları merkezde topla, riskli alanları listele, ihlalleri say ve kimseye "acaba atladık mı" diye sorma. Bu yapının hazır kurulu hâlini kendi gözünle görmek istersen canlı demo üzerinden sipariş akışını baştan sona deneyebilir, hatalı girdilerle sistemi kendin zorlayabilirsin.