# Başvuru formları spamden nasıl korunur? Sunucu doğrulaması, doğrulanmış bot koruma tokenı ve ölçülü istek sınırını birlikte kullanın. Gönderimin güvenilirliğine yalnız tarayıcı karar veremez. Bir onay işareti veya rahatlatıcı animasyon, formun korunduğunun kanıtı değildir. Aynı idempotency anahtarıyla yinelenen istek önceki sonucu döndürmeli; aynı anahtarlı farklı veri reddedilmelidir. Turnstile kutusunu gösterip tokenı sunucuda doğrulamamak eksik korumadır. ## Görünen güvenlik kontrolünün arkasını sorun Bir onay işareti veya rahatlatıcı animasyon, formun korunduğunun kanıtı değildir. Tarayıcı sunucuya istek gönderir; sunucu da kaydetmeden önce bu isteğin kabul edilebilir olup olmadığına karar vermelidir. Geliştiriciden hangi alanların ve boyutların kabul edildiğini, gönderimin nereden gelebileceğini, güvenlik servisi çalışmadığında ne olacağını sade biçimde açıklamasını isteyin. Turnstile için [Cloudflare sunucuda doğrulama ister](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/). Token geçicidir ve tek kullanımlıktır. Dolayısıyla formda yenileme ve güvenli yeniden deneme davranışı gerekir. Yalnız widget yerleştirmek önemli senaryoları çözümsüz bırakır. Güvenlik, ekrandaki yeşil durumdan daha kapsamlı bir işlemdir. Yalnız güzel hazırlanmış formu doldurmakla yetinmeyin; endpoint geçersiz veriyle doğrudan denendiğinde de kontrol çalışmalıdır. Biri sayfayı atladığında sunucu kuralları değişmemelidir. HTML'de isteğe bağlı telefon ile sunucu koşulları uyumlu olmalı, ziyaretçinin gönderdiği fiyat başvurunun yetkili paket fiyatını belirlememelidir. ## Kötüye kullanım sınırını gerçek müşteriyi düşünerek kurun Ortak ofiste aynı bağlantıyı kullanan birkaç işletmeyi düşünün. Çok katı IP sınırı farklı kişilerin gerçek başvurularını engelleyebilir. Sınırsız kabul ise kaynak tüketip başvuru listesini kullanışsızlaştırabilir. Genel denemeler ile doğrulanmış gönderimleri ayırın. Seçilen limitleri mutlak güvenlik garantisi olarak değil, işletim kararı olarak belgeleyin. Sınır için hangi verinin ne kadar saklandığını sorun. Ham IP ve tam form gövdesi günlük operasyon kayıtlarında çoğu zaman gerekli değildir. Kısa ömürlü ve amaca özel türetilmiş anahtarlar maruziyeti azaltabilir, ancak bunlar da dikkatle ele alınmalıdır. Erişim, temizlik ve saklama kararı algoritma kadar önemlidir. Fazla büyük istekleri reddetmek ve yardımcı teknolojileri şaşırtmayan gizli tuzak alanı kullanmak ek katmanlar olabilir. Hiçbiri alan doğrulamasının veya güvenli veritabanı işleminin yerini almaz. Hatalarda sakin, yerelleştirilmiş açıklama ve yeniden deneme yolu sunun. Kaydedilmeyen başvuruya alındı demek, sorunu müşteriye aktarmaktan başka işe yaramaz. ## Kesilen ve tekrarlanan gönderimleri özellikle deneyin Kayıt oluştuğu halde ziyaretçinin yanıtı almadan bağlantısının kesildiğini düşünün. Tekrar gönderdiğinde aynı talep için iki kayıt oluşmamalıdır. Aşırı basit token denetimi de ilk token tüketildiği için kişiyi çıkmaza sokmamalıdır. İstenen sonuç, tek kalıcı başvuru ve aynı güçlü istek anahtarı için güvenle yinelenebilen onaydır. Teslim kontrolüne süresi dolmuş doğrulama, eksik alan, büyük açıklama, geçici kayıt hatası ve tekrarlanan geçerli istek ekleyin. Düzeltilebilir hatada yazılan metin kaybolmamalı; bunun için özel içerik tarayıcıya kalıcı kaydedilmemelidir. Teşekkür adresini doğrudan açmak da gönderim olmuş gibi davranmamalıdır. Başvuruyu değerlendiren kişinin güvenliği de bu yolun parçasıdır. Gönderilen metin yönetim ekranında çalıştırılabilir HTML olmamalı, dışa aktarılan hücre kullanıcı formülü yürütmemelidir. Bunlar spam filtresinden farklı kontrollerdir, ancak herkese açık formdan özel değerlendirmeye uzanan aynı sistemin gereğidir. Güvenli form, gönder düğmesinin yanındaki bir rozete indirgenemez. **Hata kontrolü için kısa bir karar listesi hazırlayın.** Reddedilen her gönderimde ziyaretçi alanı mı düzeltecek, güvenlik kontrolünü mü yenileyecek, biraz mı bekleyecek, sonra mı dönecek anlaşılmalıdır. Bunlar ayrı durumlardır. İç ayrıntıları açığa çıkarmayan kısa yönlendirme, her yerde bir sorun oldu demekten daha yararlıdır. Mesaj formun diliyle aynı olmalı ve ekran okuyucuya ulaşmalıdır. Geçici hatada yazılan açıklamanın sayfada kaldığını sorun. Özenle brief yazan kişi bir ağ yanıtı kesildi diye her şeyi yeniden oluşturmamalıdır. Öte yandan bu özel metni ortak tarayıcıda kalıcı saklamak başka sorun getirir. Bilgiyi mevcut etkileşim için gereken ölçüde tutun; kolaylık gerekçesiyle uzun ömürlü kişisel kayıt oluşturmaktan kaçının. Yetkili test kaydını işletmeci bulsun ve aynı isteğin ikinci başvuru yaratmadığını görsün. Hangi ortamın denendiğini yazın. Yerel başarı yerel yolu gösterir; canlı anahtar, izinli host ve üretim veritabanı ayrıca doğrulanmış ayar ister. Bunları ayrı söylemek güvenlik raporunu daha doğru kılar. Statik sayfanın açılması, form altyapısının çalıştığını kanıtlamaz. Formun gereksiz bilgi istememesini de inceleyin. Teklif için dosya gerekmiyorsa yükleme alanı eklemek hem ziyaretçiye yük hem ek saldırı yüzeyi yaratabilir. Yazılan site adresini sunucudan otomatik açmak da bu basit başvuru süreci için gerekli olmayabilir. Her özellik hangi gerçek ihtiyacı karşıladığıyla gerekçelendirilmelidir; daha fazla teknik işlem kendiliğinden daha iyi hizmet değildir. Son olarak işletim sorumlusunun neyi izleyeceğini belirleyin. Hata türü artarsa başvuruların yanlış başarılı gösterilmediğini ve verinin güvenli kaldığını kontrol etsin. Servis geçici kapalıysa doğrulanmış alternatif kanal varsa sunulabilir; yoksa numara uydurulmaz. Kullanıcının gerçek durumu bilmesi, görünürde kesintisiz başarı mesajından daha değerlidir. Dürüst hata davranışı güvenli formun temel teslim kalemidir. **Tekrarlanan gönderim senaryosunu kayıt tarafında izleyin.** Aynı deneme için güçlü anahtar bir kez üretildiğinde tekrar deneme aynı talebi temsil etmelidir. Kullanıcı içeriği değiştirip yeni talep göndermek istiyorsa bunun ayrı işlem olduğu anlaşılmalıdır. Sunucu aynı anahtar altında farklı metin kabul edip sessizce önceki kaydı değiştirmemelidir. Başarı cevabı da kişinin adını ve e-postasını gereksiz yere geri taşımamalıdır. Kısa referans yeterli olabilir. Referansın URL'ye eklenmesi yerine kişisel veri içermeyen geçici onay yolu kullanılabilir. Bu davranışları masaüstünde ve telefonda deneyin. Gönder düğmesi devre dışı kalırken açıklayıcı durum gösterilsin. Hata sonrası düğme yeniden kullanılabilir olmalıdır. Kullanıcı sayfayı açtığında gerçekleşmemiş başvuru için başarı görmemelidir. Her adım, veri kaydının gerçekte hangi aşamada olduğunu doğru yansıtmalıdır. Güvenli tasarım böylece hem tekrarları hem yanlış onayı azaltır. ## Uygulama kontrolü - Beklenen alanları doğrulayın - Turnstile tokenını sunucuda kontrol edin - Tekrarlanan başvuruları önleyin **Somut örnek:** Aynı idempotency anahtarıyla yinelenen istek önceki sonucu döndürmeli; aynı anahtarlı farklı veri reddedilmelidir. **Dikkat edilmesi gereken sınır:** Turnstile kutusunu gösterip tokenı sunucuda doğrulamamak eksik korumadır. ## Sonraki adım [Projenizi Orvunweb’e anlatın](/tr/basvuru/) ## İlgili okumalar - [Tamamlanabilir bir iletişim formu nasıl tasarlanır?](/tr/blog/tamamlanabilir-bir-iletisim-formu-nasil-tasarlanir/) - [Cloudflare üzerinde tanıtım sitesi yayınlamak](/tr/blog/cloudflare-uzerinde-tanitim-sitesi-yayinlamak/) - [Web sitesi yayından sonra nasıl güncel tutulur?](/tr/blog/web-sitesi-yayindan-sonra-nasil-guncel-tutulur/) - [Kurumsal web sitesi hizmeti](/tr/hizmetler/kurumsal-web-sitesi/) - [Paketleri karşılaştırın](/tr/paketler/) ## İlgili hizmetler - [Kurumsal tanıtım sitesi](/tr/hizmetler/kurumsal-web-sitesi/) --- Locale: tr Canonical: https://orvunweb.com/tr/blog/basvuru-formlari-spamden-nasil-korunur/ Updated: 2026-09-16 - [Cloudflare — Server-side Turnstile validation](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/)