Bir web sitesine gelen trafiğin azımsanmayacak bir kısmı gerçek insanlardan değil, otomatik betiklerden gelir. Bunların bir bölümü arama motoru tarayıcıları gibi zararsızdır; ama önemli bir bölümü iletişim formunuza spam basmak, kayıt sayfanızda sahte hesap açmak, giriş ekranında çalınmış parolaları tek tek denemek ya da yorum alanınızı reklam bağlantısıyla doldurmak için çalışan kötü niyetli araçlardır. Bu botlar yorulmaz, saniyede onlarca istek gönderebilir ve yakalanmadıkları sürece işlerini sessizce büyütürler. Sonuç; şişmiş bir veritabanı, kirlenmiş bir e-posta listesi, gereksiz sunucu yükü ve bazen ele geçirilmiş müşteri hesaplarıdır.
Bu yazıda bot trafiğinin form spam, kayıt kötüye kullanımı ve credential stuffing (kimlik doldurma) saldırılarındaki rolünü, ardından bu trafiği süzmek için kullanılan başlıca araçları ele alacağız. reCAPTCHA v2/v3, hCaptcha ve Cloudflare Turnstile'ı hem kullanıcı deneyimi hem de mahremiyet açısından karşılaştıracak; işin görünmeyen ama en kritik parçası olan sunucu tarafı doğrulamayı, honeypot (bal küpü) alanını ve oran sınırlamayı gerçek yapılandırma örnekleriyle göstereceğiz. Amaç, tek bir sihirli kutu aramak yerine katmanlı ve dengeli bir savunma kurmanızı sağlamak.
Bot Trafiği Neden Bu Kadar Önemli?#
Botları tek bir kategori sanmak en sık yapılan hatadır. Gerçekte aralarında büyük fark vardır ve savunma stratejiniz de bu farka göre şekillenir. Kabaca üç sorunlu davranış öne çıkar.
Form spam, en görünür olanıdır. İletişim, yorum, üyelik veya bülten formlarınıza otomatik araçlar sürekli sahte içerik gönderir. Zararı sadece gelen kutunuzu kirletmekle kalmaz; e-posta gönderim itibarınızı düşürür, ekibinizin zamanını çalar ve bazı durumlarda formdan tetiklenen bildirim e-postalarıyla sunucunuzu bir spam relay'ine çevirir.
Kayıt kötüye kullanımı, biraz daha sinsidir. Botlar toplu halde sahte hesap açar; bu hesaplar kupon istismarı, deneme sürümü suistimali, referans (davet) puanı toplama ya da platform içi spam için kullanılır. Bir SaaS için bu, kullanıcı sayınızın yanıltıcı görünmesi ve ücretsiz kaynaklarınızın sömürülmesi demektir.
Credential stuffing, en tehlikelisidir. Başka sitelerden sızmış milyonlarca e-posta ve parola çiftini, botlar sizin giriş sayfanızda tek tek dener. Parolasını birden fazla yerde kullanan müşterileriniz için bu, hesabın ele geçirilmesiyle sonuçlanır. Bu saldırı biçimi klasik kaba kuvvetten farklıdır: her hesaba tek bir deneme yapıldığı için basit "5 yanlış girişte kilitle" kuralları çoğu zaman devreye girmez. Konunun derinine inmek isterseniz brute force saldırısı yazımız bu ayrımı daha ayrıntılı anlatıyor.
Bu üç davranışın ortak noktası otomasyon ve ölçektir. Dolayısıyla savunmanın kalbi de "bu isteği bir insan mı yoksa bir makine mi gönderiyor?" sorusuna güvenilir cevap verebilmektir. CAPTCHA bu sorunun en bilinen cevabı, ama tek başına yeterli değildir.
CAPTCHA Nasıl Çalışır?#
CAPTCHA, "Completely Automated Public Turing test to tell Computers and Humans Apart" ifadesinin kısaltmasıdır; yani bilgisayarlarla insanları ayırt etmeye yarayan otomatik bir testtir. Klasik hali, çarpık harfleri okumanızı ya da "trafik ışığı içeren kareleri seçin" demenizi isteyen görsel bulmacadır. Mantık basittir: bir insan için kolay, bir makine için (teorik olarak) zor olan bir görev sunulur.
Ne var ki bilgisayarlı görü ve makine öğrenimi ilerledikçe bu klasik testler zayıfladı; hem botlar bulmacaları çözebilir hale geldi hem de gerçek kullanıcılar bu testlerden nefret etmeye başladı. Bu yüzden modern CAPTCHA sistemleri artık görsel bulmacadan çok, arka planda davranışsal sinyaller toplar: fare hareketleri, tuş vuruş ritmi, tarayıcı parmak izi, IP itibarı ve tarayıcının otomasyon araçlarına özgü izler taşıyıp taşımadığı gibi.
Akış her zaman iki parçadan oluşur ve bu ayrımı anlamak kritiktir:
- İstemci tarafı (tarayıcı): Sağlayıcının JavaScript'i çalışır, kullanıcı testi (varsa) geçer ve tarayıcıya tek kullanımlık bir token verilir. Bu token, formun gizli bir alanına yerleştirilir.
- Sunucu tarafı (sizin backend'iniz): Form gönderildiğinde, sunucunuz bu token'ı sağlayıcının doğrulama API'sine yollar ve "bu token gerçekten geçerli mi?" diye sorar. Cevap olumluysa isteği işler, değilse reddeder.
Buradaki en yaygın ve en tehlikeli hata, ikinci adımı atlamaktır. Sadece tarayıcıda widget'ı göstermek hiçbir işe yaramaz; bir bot JavaScript'i hiç çalıştırmadan doğrudan formun POST adresine istek atabilir. Koruma, ancak sunucu token'ı doğruladığında gerçek olur. Bu noktaya birazdan geri döneceğiz.
reCAPTCHA, hCaptcha ve Turnstile Karşılaştırması#
Bugün pratikte üç seçenek öne çıkıyor. Hepsi "insan mı, bot mu?" sorusunu cevaplamaya çalışır ama kullanıcı deneyimi ve mahremiyet konusundaki tercihleri birbirinden ayrılır.
Google reCAPTCHA v2, "Ben robot değilim" kutucuğu olarak bildiğimiz sürümdür. Bazen tıklama yeterli olur, şüpheli durumlarda görsel bulmaca çıkar. Güçlü ama görünür bir sürtünme yaratır ve bulmacalar mobilde can sıkıcı olabilir.
reCAPTCHA v3, görünmezdir. Kullanıcıya hiçbir şey göstermez; onun yerine her etkileşime 0.0 ile 1.0 arasında bir "insan olma" skoru verir. Karar tamamen sizindir: örneğin 0.5 altını riskli sayıp ek doğrulama isteyebilirsiniz. Esnektir ama eşiği yanlış ayarlarsanız ya gerçek kullanıcıları engeller ya da botları içeri alırsınız. Ayrıca sitenin her sayfasında Google'a veri gönderdiği için mahremiyet açısından en çok eleştirilen seçenektir.
hCaptcha, reCAPTCHA v2'ye görsel olarak benzer ama farklı bir iş modeli ve daha güçlü bir mahremiyet duruşu vardır. GDPR/KVKK odaklı projelerde sık tercih edilir; kurumsal planlarında bot yakalama başına ödeme gibi modeller de sunar.
Cloudflare Turnstile, en yeni ve genellikle en dengeli seçenektir. Kullanıcıya bulmaca çözdürmeden, arka planda hafif bir doğrulama (managed challenge) yapar. Görsel bulmaca neredeyse hiç çıkmaz, ücretsizdir ve mahremiyet açısından reklam takibine dayanmaz. Nitekim Clou.TR panelinde bot korumasını biz de Turnstile ile sağlıyoruz.
| Özellik | reCAPTCHA v2 | reCAPTCHA v3 | hCaptcha | Turnstile |
|---|---|---|---|---|
| Kullanıcı etkileşimi | Kutucuk/bulmaca | Görünmez (skor) | Kutucuk/bulmaca | Görünmez/hafif |
| UX sürtünmesi | Orta-yüksek | Düşük | Orta | Çok düşük |
| Mahremiyet | Zayıf | Zayıf | Güçlü | Güçlü |
| Skor tabanlı | Hayır | Evet | Kısmen | Kısmen |
| Ücret | Ücretsiz | Ücretsiz | Ücretsiz/kurumsal | Ücretsiz |
| Öne çıkan yön | Yaygınlık | Sürtünmesiz akış | Mahremiyet | Denge |
Seçim yaparken pratik kural şudur: kullanıcı deneyimini en az bozmak istiyorsanız ve mahremiyet önemliyse Turnstile ile başlayın; halihazırda Google ekosistemine bağlıysanız ve skor tabanlı esneklik istiyorsanız reCAPTCHA v3 düşünülebilir; bulmaca göstermenin kabul edilebilir olduğu yüksek riskli formlarda ise açık kutucuklu v2 veya hCaptcha iş görür.
Sunucu Tarafı Doğrulama (En Kritik Adım)#
Hangi sağlayıcıyı seçerseniz seçin, korumayı gerçek kılan tek şey sunucu tarafı doğrulamadır. Widget'ın verdiği token'ı backend'de mutlaka sağlayıcıya sormalısınız. Aşağıda Cloudflare Turnstile için sade bir PHP örneği var; reCAPTCHA ve hCaptcha için de mantık birebir aynıdır, yalnızca doğrulama adresi ve parametre adları değişir.
<?php
// Formdan gelen token ve ziyaretçinin IP'si
$token = $_POST['cf-turnstile-response'] ?? '';
$ip = $_SERVER['REMOTE_ADDR'] ?? '';
// Boş token'ı hiç uğraşmadan reddet
if ($token === '') {
http_response_code(400);
exit('Doğrulama başarısız.');
}
$response = file_get_contents(
'https://challenges.cloudflare.com/turnstile/v0/siteverify',
false,
stream_context_create(['http' => [
'method' => 'POST',
'header' => 'Content-Type: application/x-www-form-urlencoded',
'content' => http_build_query([
'secret' => getenv('TURNSTILE_SECRET'), // gizli anahtar sadece sunucuda!
'response' => $token,
'remoteip' => $ip,
]),
'timeout' => 5,
]])
);
$result = json_decode($response, true);
if (empty($result['success'])) {
http_response_code(403);
exit('Bot doğrulaması geçilemedi.');
}
// Buraya ulaştıysak istek insan doğrulamasından geçti; formu işleyebilirsiniz.
reCAPTCHA için doğrulama adresi https://www.google.com/recaptcha/api/siteverify, hCaptcha için https://hcaptcha.com/siteverify olur; parametreler yine secret ve response şeklindedir. reCAPTCHA v3 kullanıyorsanız dönen JSON'daki score ve action alanlarını da kontrol etmeniz gerekir:
// reCAPTCHA v3'e özel: skor eşiği ve beklenen aksiyon kontrolü
if ($result['score'] < 0.5 || $result['action'] !== 'login') {
http_response_code(403);
exit('Şüpheli istek.');
}
Dikkat edilecek üç nokta var. Birincisi, gizli anahtar (secret key) asla istemci koduna girmez; yalnızca sunucuda, tercihen ortam değişkeninde durur. İkincisi, doğrulama isteğine daima bir zaman aşımı koyun ki sağlayıcı yavaşlarsa siteniz kilitlenmesin. Üçüncüsü, sonucu fail-closed yorumlayın: doğrulama net biçimde başarılı dönmediyse isteği reddedin — belirsizliği "geçti" saymayın. Bu yaklaşımın neden önemli olduğunu WAF (web uygulama güvenlik duvarı) yazımızdaki katmanlı savunma mantığında da göreceksiniz.
Honeypot ile Sessiz Bot Yakalama#
CAPTCHA, gerçek kullanıcıya bir maliyet bindirir; ne kadar hafif olsa da bir JavaScript yükler ve bazen bir tık ister. Bunun yanına, kullanıcıya hiç dokunmayan ama basit botların önemli bir kısmını sessizce eleyen bir teknik daha eklemek çok akıllıcadır: honeypot (bal küpü) alanı.
Fikir çok basittir. Forma, gerçek kullanıcının asla göremeyeceği ve dolduramayacağı gizli bir alan koyarsınız. İnsanlar bu alanı görmez, dolayısıyla boş bırakır. Otomatik botlar ise formdaki tüm alanları körü körüne doldurma eğilimindedir; bu tuzağı da doldururlar. Sunucu, alanın dolu geldiğini görürse isteğin bir bottan geldiğini anlar ve sessizce reddeder.
<!-- Ekranda görünmesin ama tarayıcı yine de render etsin (display:none botların bir kısmını uyarır) -->
<div style="position:absolute; left:-9999px;" aria-hidden="true">
<label>Bu alanı boş bırakın</label>
<input type="text" name="website" tabindex="-1" autocomplete="off">
</div>
Sunucu tarafında kontrol tek satırdır:
// İnsan bunu boş bırakır; doluysa bottur.
if (!empty($_POST['website'])) {
http_response_code(200); // Bota hata bile verme; başarılıymış gibi davran ki öğrenmesin
exit;
}
Honeypot'un iki püf noktası var. Birincisi, alan adını email veya phone gibi botların "değerli" sandığı bir isim seçmek yakalama oranını artırır; ama name, url, website gibi masum görünen isimler de iş görür. İkincisi, alanı type="hidden" yapmak yerine görünürde bir metin kutusu olarak bırakıp CSS ile gizlemek daha etkilidir, çünkü bazı botlar hidden alanları zaten atlar. Honeypot tek başına yeterli değildir ama CAPTCHA + oran sınırlama ile birleştiğinde botların büyük çoğunluğunu gürültüsüzce eler.
Aynı mantığın bir uzantısı da zaman tuzağıdır: formun ne zaman render edildiğini gizli bir alanda (imzalı olarak) tutup, gönderim iki saniyeden kısa sürede geldiyse reddedebilirsiniz. Hiçbir insan bir kayıt formunu 800 milisaniyede dolduramaz; botlar ise saniyenin altında doldurur.
Oran Sınırlama (Rate Limiting) ile Ölçeği Kırmak#
Botların en güçlü yanı ölçektir: aynı işlemi binlerce kez, çok hızlı yaparlar. Oran sınırlama, tam da bu ölçeği kırar. Bir IP'nin (ya da hesabın) belirli bir zaman diliminde kaç istek atabileceğine üst sınır koyarsınız. Tek bir sahte kayıt zararsızdır; ama dakikada 500 kayıt denemesi açık bir saldırıdır ve oran sınırlama bunu daha CAPTCHA'ya gelmeden durdurur.
En doğal yeri web sunucusudur. Nginx'te giriş ve kayıt gibi hassas uç noktalar için ayrı bir bölge tanımlamak birkaç satırdır:
# http {} bloğunda: IP başına dakikada ~30 istek (saniyede 0.5), 10MB'lik durum tablosu
limit_req_zone $binary_remote_addr zone=login_zone:10m rate=30r/m;
server {
location /giris {
# burst=10: ani sıçramalara izin ver ama fazlasını geciktir/reddet
limit_req zone=login_zone burst=10 nodelay;
limit_req_status 429; # sınırı aşan istemciye "429 Too Many Requests" dön
proxy_pass http://backend;
}
}
Nginx'in daha ayrıntılı güvenlik yapılandırması için Nginx oran sınırlama ve güvenlik başlıkları yazımıza göz atabilirsiniz. Apache tarafında ise mod_ratelimit daha çok bant genişliği içindir; istek sayısı sınırlaması için genellikle mod_evasive veya bir WAF katmanı tercih edilir.
Uygulama seviyesinde de sınır koymak, IP tabanlı sınırın yetmediği yerlerde işe yarar. Örneğin credential stuffing'de saldırgan IP'yi sürekli değiştirebilir; bu durumda "aynı e-posta adresine son 10 dakikada kaç başarısız giriş denemesi yapıldı?" sorusu daha ayırt edicidir. Basit bir mantık şöyle görünür:
// Redis ile hesap-bazlı deneme sayacı (kayan pencere yerine sade sabit pencere örneği)
$key = "login_attempts:" . strtolower($email);
$count = $redis->incr($key);
if ($count === 1) {
$redis->expire($key, 600); // 10 dakikalık pencere
}
if ($count > 5) {
http_response_code(429);
exit('Çok fazla deneme. Lütfen sonra tekrar deneyin.');
}
Oran sınırlamayı kurarken meşru kullanıcıyı cezalandırmamaya dikkat edin. Ortak IP'ler (kurumsal NAT, mobil operatör, okul ağı) arkasında yüzlerce gerçek kullanıcı olabilir. Bu yüzden sınırları çok kısıtlı tutmak yerine, "makul insan davranışının biraz üstü" bir tavan belirleyin ve sınırı aşanlara doğrudan blok yerine önce CAPTCHA gösterin. En etkili mimari çoğu zaman şudur: normal trafikte hiçbir engel yok, oran sınırı aşılınca CAPTCHA devreye giriyor, açık kötü niyet görülünce geçici blok uygulanıyor.
Katmanları Birleştirmek: Gerçekçi Bir Kurulum#
Tek bir aracın her şeyi çözmesini beklemek, en yaygın hayal kırıklığı kaynağıdır. Gerçek dünyada işleyen koruma, katmanların birbirini tamamladığı bir zincirdir. Sıralı bir istek şöyle akar:
- Ağ/CDN katmanı: Cloudflare gibi bir katman, bilinen kötü IP'leri ve kaba saldırıları daha sunucunuza ulaşmadan eler. Bu aynı zamanda hacimsel saldırılara karşı ilk siperdir; DDoS saldırısı nedir yazımız bu katmanın önemini ayrıntılandırıyor.
- Oran sınırlama: Web sunucusu, hassas uç noktalara gelen istek hızını sınırlar. Botun ölçek avantajı burada kırılır.
- Honeypot + zaman tuzağı: Basit botlar, kullanıcıya hiç dokunmadan, sessizce elenir.
- CAPTCHA/Turnstile: Kalan şüpheli isteklere insan doğrulaması uygulanır.
- Sunucu tarafı doğrulama: Token backend'de teyit edilir; fail-closed davranılır.
- İzleme ve loglama: Başarısız denemeler, 429 yanıtları ve reddedilen tokenlar loglanır; anormal artışlar alarm üretir.
Bu katmanların hepsini aynı anda kurmak zorunda değilsiniz. Küçük bir iletişim formu için honeypot + Turnstile + basit oran sınırlama fazlasıyla yeterlidir. Buna karşılık müşteri girişi, ödeme ya da kayıt gibi yüksek değerli akışlarda tüm zinciri işletmek gerekir. Sunucunuzun genel sağlamlaştırması için sunucu güvenliği temelleri ve tekrar eden saldırgan IP'leri otomatik banlamak için Fail2ban kurulumu yazılarımız bu resmi tamamlar.
Son olarak, korumanın ölçülebilir olduğunu unutmayın. Kurulumdan önce ve sonra form gönderim sayılarını, sahte kayıt oranını ve başarısız giriş loglarını karşılaştırın. İyi bir bot koruması, meşru dönüşümlerinizi neredeyse hiç düşürmeden spam ve otomasyon trafiğini gözle görülür biçimde azaltır. Bu iki eğriyi birlikte izlemek, hem eşiklerinizi ince ayarlamanızı hem de bir gün gerçek kullanıcıları yanlışlıkla engelleyip engellemediğinizi fark etmenizi sağlar.
Sıkça Sorulan Sorular#
CAPTCHA gerçekten botları tamamen durdurur mu?#
Hayır, hiçbir CAPTCHA yüzde yüz koruma sağlamaz. Gelişmiş saldırganlar CAPTCHA çözme servisleri ve otomasyon araçlarıyla bazı testleri geçebilir. CAPTCHA'nın amacı botları imkânsız kılmak değil, saldırının maliyetini ve ölçeğini kırmaktır. Bu yüzden onu honeypot, oran sınırlama ve sunucu tarafı doğrulama gibi katmanlarla birlikte kullanmak, tek başına kullanmaktan çok daha etkilidir.
reCAPTCHA v3 ile v2 arasında hangisini seçmeliyim?#
Kullanıcıya bulmaca göstermek istemiyorsanız ve akışı olabildiğince pürüzsüz tutmak önceliğinizse v3 mantıklıdır; ancak v3 skor tabanlı olduğu için eşiğinizi doğru ayarlamanız ve şüpheli skorlarda ek bir doğrulama planlamanız gerekir. Bulmaca göstermenin kabul edilebilir olduğu yüksek riskli formlarda ise açık kutucuklu v2 daha nettir. Mahremiyet ve sürtünmesizlik ikisi birden önemliyse Cloudflare Turnstile'ı da değerlendirmenizi öneririm.
Turnstile ücretsiz mi ve hangi durumda tercih edilmeli?#
Cloudflare Turnstile temel kullanımda ücretsizdir ve kullanıcıya çoğu zaman hiçbir bulmaca göstermeden arka planda doğrulama yapar. Reklam takibine dayanmadığı için mahremiyet açısından da rahatsınız. Kullanıcı deneyimini en az bozmak isteyen, KVKK/GDPR hassasiyeti olan ve Google ekosistemine bağlı kalmak istemeyen projeler için genellikle en dengeli seçenektir; Clou.TR panelinde de tercih ettiğimiz çözüm budur.
Honeypot alanı SEO veya erişilebilirliği bozar mı?#
Doğru kurulduğunda hayır. Gizli alanı ekran okuyuculardan da saklamak için aria-hidden="true" ve tabindex="-1" kullanmalı, üzerine "bu alanı boş bırakın" gibi bir etiket koymalısınız; böylece klavye veya ekran okuyucuyla gezen gerçek kullanıcı yanlışlıkla doldurmaz. Arama motorları bu alanı içerik olarak yorumlamaz. Yalnızca alanı display:none yerine ekran dışına taşımak (left:-9999px) bazı botları daha az uyardığı için genellikle daha etkilidir.
Oran sınırlama gerçek kullanıcıları engeller mi?#
Yanlış ayarlanırsa engelleyebilir; özellikle kurumsal NAT, mobil operatör veya okul ağı gibi çok sayıda kullanıcının aynı IP'yi paylaştığı durumlarda. Bunu önlemek için sınırları "makul insan davranışının biraz üstü" bir seviyede tutun ve sınırı aşan istemciyi doğrudan bloklamak yerine önce CAPTCHA gösterin. Kritik akışlarda IP tabanlı sınırın yanına hesap/e-posta tabanlı sayaçlar eklemek, meşru kullanıcıyı cezalandırmadan credential stuffing gibi dağıtık saldırıları yakalamanızı sağlar.
Sunucu tarafı doğrulamayı atlarsam ne olur?#
Koruma tamamen çöker. Widget yalnızca tarayıcıda çalıştığı için, bir bot JavaScript'i hiç yüklemeden doğrudan formun POST adresine istek atabilir ve token'ı hiç göndermeyebilir. Eğer sunucunuz token'ın varlığını ve geçerliliğini kontrol etmiyorsa bu istek sorunsuz kabul edilir. Bu yüzden CAPTCHA'nın gerçek koruması, her zaman backend'de sağlayıcıya yapılan doğrulama çağrısındadır; bu adım olmadan ekrandaki widget yalnızca dekoratif kalır.
Kapanış#
Bot koruması, tek bir kutucuğu forma eklemekle biten bir iş değil; ağdan uygulamaya uzanan katmanlı bir savunma disiplinidir. reCAPTCHA, hCaptcha veya Turnstile gibi bir CAPTCHA seçmek işin görünen yüzüdür; asıl korumayı sunucu tarafı doğrulama, honeypot ve oran sınırlama birlikte sağlar. Bu üçünü doğru kurduğunuzda form spam, sahte kayıt ve credential stuffing trafiğinin büyük kısmını gerçek kullanıcılarınızı hiç rahatsız etmeden eleyebilirsiniz.
Sitenizin altyapısını en baştan sağlam kurmak isterseniz Clou.TR olarak yanınızdayız. Bot ve saldırı trafiğini kenardan süzen WAF ve DDoS koruma hizmetlerimiz, güçlü bir güvenlik temeli için SSL sertifikaları ve isteğe bağlı sunucu yönetimi desteğimiz, korumanın her katmanını profesyonel ellere bırakmanızı sağlar. Yeni bir proje mi başlatıyorsunuz? Turnstile'ın hazır entegre olduğu güvenli panelimizle hosting ve sunucu çözümlerimizi inceleyerek işe başlayabilir, WordPress siteleriniz için WordPress bakım paketlerimizle güvenlik yükünü bize devredebilirsiniz.