Bir cevap, net ve kibar olabilir, ancak tam da önemli olan noktada yanlış olabilir. Bir destek görevlisi, doğru ürün açıklamasını aktardıktan sonra, kaynağın hiç vermemiş olduğu bir teslimat vaadini ekleyebilir.
Oluşturma ve doğrulama işlemlerini ayrı sorumluluklar olarak ele alıyorum. Model bir yanıt önerir. Uygulama ise bu yanıtın, sunum için gerekli olan kanıt ve ürün kurallarını karşılayıp karşılamadığını belirler.
Risk oluşturan iddiaları belirleyin
Her cümle aynı şekilde ele alınmak zorunda değildir. Bir selamlama cümlesi, pek az somut bilgi içerir. Bir fiyat, ürün kodu, garanti koşulu veya bağlantı ise müşterinin kararını doğrudan etkileyebilir.
Öncelikle bu somut iddiaları belirliyorum. Ardından doğrulayıcı, bunları elde edilen kaynaklarla veya güvenilir yapılandırılmış verilerle karşılaştırır. Bu süreçte ilişkiler korunmalıdır: Bir kaynakta 49 rakamını bulmak, seçilen ürünün fiyatının 49 € olduğunu doğrulamak için yeterli değildir.
Para birimi, varyant, miktar, tarih ve pazar, bir değerin anlamını değiştirebilir. Yararlı bir kontrol, iddianın tamamının ilgili bağlamda desteklenip desteklenmediğini sorgulamaktır.
Bağlantıları güvenilir kaynak kayıtlarıyla ilişkilendirin
Bir model, var olmayan ancak inandırıcı bir URL oluşturabilir. Ayrıca, yanlış bir ürüne yönlendiren gerçek bir URL de oluşturabilir. Ben, oluşturulan metinden derlenen yollar yerine, doğrulanmış kaynak kayıtlarından seçilen bağlantıları tercih ederim.
Bağlantı denetimi için açık bir normalleştirme politikası gereklidir. Yalnızca alan adlarını karşılaştırmak, birçok hatalı hedefi kabul etmesine neden olur. Geçerli biçimlendirme farklılıklarını dikkate almadan ham dizeleri karşılaştırmak ise geçerli bağlantıları reddedebilir.
Uygulama, bir URL’yi doğrulamak için oluşturulan bir URL’yi alırsa, bu alma işlemi kendi güvenlik sınırını oluşturur. Çoğu durumda, kontrollü bir kaynak kataloğuyla karşılaştırma yapmak, doğrulayıcıdan gelen rastgele ağ isteklerine izin vermekten daha basittir.
Etki alanı izin verdiği durumlarda deterministik denetimler kullanın
Yapılandırılmış ürün tanımlayıcıları ve bilinen fiyatlar, deterministik doğrulama için uygun adaylardır. Açık uçlu poliçe açıklamaları ise daha zordur: Anahtar kelimelerin eşleşmesi, bir cümlenin orijinal koşulları koruduğunu kanıtlayamaz.
Model tabanlı bir doğrulayıcı, anlamsal iddiaları incelemede yardımcı olabilir, ancak bu, hataya açık başka bir bileşen daha getirir. Ben bunu, insanlar tarafından incelenmiş örnekler temelinde kalibre ederdim ve yüksek etkili kuralları açık bir şekilde belirtirdim. Aynı üretim modeline bunun doğru olup olmadığını sormak, tek başına zayıf bir kanıttır.
Olası bir sonuç yapısı şöyledir:
{
"karar": "gözden_geçirilmesi_gerekiyor",
"desteklenmeyen_iddialar": ["istenen_tarihte_teslimat"],
"izin_verilen_kaynak_kimlikleri": ["shipping-policy-v3"],
"sonraki_eylem": "posta_kodu_iste"
}Bu örnek bir sözleşmedir. Önemli olan nokta, başarısızlık durumunda, sonraki kodların göz ardı edebileceği genel bir Boolean değeri yerine, işlem yapılabilir bir durumun ortaya çıkmasıdır.
Doğrulama başarısız olduğunda ne olacağını planlayın
Uygulama, daha sınırlı kanıtlara dayanarak işlemi yeniden başlatabilir, dayanağı olmayan bir iddiayı kaldırabilir, eksik bilgileri isteyebilir veya görüşmeyi bir kişiye devredebilir. Bu seçim, başarısızlığın nedenine göre yapılmalıdır.
Yeniden denemeler için bir sınır belirlenmelidir. Bir yanıt alınana kadar tekrar tekrar deneme yapmak, maliyeti artırabilir ve aynı zamanda doğrulayıcıdaki zayıf noktaları ortaya çıkarabilir. Her deneme, isteğin zaman ve harcama bütçesi sınırları içinde kalmalıdır.
Akış, tasarımı da değiştirir. Müşteriye halihazırda gösterilmiş olan metinler gizlenemez. Ürün, teslimattan önce doğrulama vaat ediyorsa, etkileyici iddiaların yayınlanmadan önce tamponlanmaları veya onaylanmış yapılandırılmış alanlardan oluşturulması gerekir.
Kanıt doğrulamasını, talimatlara duyulan güvenden ayrı tutun
Elde edilen bir belge, yararlı bilgiler ve zararlı talimatlar içerebilir. Kanıt denetiminden geçmek, o belgeye araç izinlerini veya sistem davranışını değiştirme yetkisi vermez. OWASP’nin hızlı enjeksiyon kılavuzu bu ayrı güven sınırı için yararlı bir referans niteliğindedir.
Doğrulama hatalarının değerlendirme örnekleri haline gelmesini istiyorum. Desteklenmeyen her bir taahhüt veya hatalı bağlantı, sistemin bir dahaki sefere tanımlaması gereken somut bir davranışı ve ekibin iş akışını değiştirmeden önce çalıştırabileceği bir regresyon kontrolünü ifade eder.
25 Eylül 2026 tarihinde güncellenmiştir.