CAPTCHA Nedir? Bot Koruması Nasıl Çalışır?

CAPTCHA, insan ile botu kusursuz biçimde ayıran sihirli bir test değil; otomatik işlemleri pahalılaştıran bir risk kontrolüdür. Kullanıcıdan görev isteyebilir veya görünmez sinyaller değerlendirebilir. Güvenli uygulamada token sunucu tarafında doğrulanır ve oran sınırlama, oturum güvenliği ile erişilebilir alternatiflerle birlikte kullanılır.

CAPTCHA neden kullanılır?

Bir giriş formu, yorum alanı veya kayıt sayfası kısa sürede binlerce otomatik istek alabilir. Bu isteklerin tamamı saldırı değildir; arama motoru tarayıcıları, mobil uygulamalar ve kötü niyetli botlar aynı HTTP protokolünü kullanır. CAPTCHA, insan etkileşimi hakkında ek sinyal toplayarak otomatik işlemleri ayırmaya, şüpheli istekleri yavaşlatmaya veya ikinci bir doğrulama istemeye yarar.

CAPTCHA adı, “Completely Automated Public Turing test to tell Computers and Humans Apart” ifadesinin kısaltmasıdır. Klasik yaklaşımda kullanıcıdan bozuk harfleri okuması istenirken güncel sistemler davranış, tarayıcı özellikleri, oturum geçmişi ve risk puanı gibi sinyalleri birlikte değerlendirir.

Ne yapılmalı – CAPTCHA’yı tek savunma katmanı değil, oran sınırlama, oturum güvenliği ve sunucu tarafı doğrulamayla birlikte çalışan bir kontrol olarak konumlandırın.

CAPTCHA nedir ve nasıl çalışır?

CAPTCHA, bir işlemi yapan tarafın insan olma ihtimalini ölçen otomatik bir doğrulama mekanizmasıdır. Kullanıcıya bir görev gösterebilir, görünmez risk analizi yapabilir veya yalnızca yüksek riskli oturumlarda ek doğrulama açabilir. Hedef, insanı matematiksel olarak kanıtlamak değil, otomasyon maliyetini artırmaktır.

İstekten karara giden yol

1. Kullanıcı formu açar veya bir işlem başlatır.
2. CAPTCHA sağlayıcısının JavaScript kodu ya da widget’ı yüklenir.
3. Tarayıcı, etkileşim ve ortamla ilgili sinyalleri sağlayıcıya gönderir.
4. Sağlayıcı bir token, cevap veya risk puanı üretir.
5. Uygulama sunucusu bu değeri sağlayıcının doğrulama API’sine gönderir.
6. Sunucu; token geçerli mi, doğru site için mi üretildi, süresi doldu mu ve işlemle eşleşiyor mu diye kontrol eder.
7. Yalnızca sunucu tarafı kontrolü başarılıysa kayıt, giriş veya form gönderimi tamamlanır.

Token’ın tarayıcıdan gelmiş olması tek başına yeterli değildir. İstemci tarafındaki JavaScript değiştirilebilir; gizli anahtarlar yalnızca sunucuda tutulmalı, formun asıl işlemi doğrulama sonucundan sonra yapılmalıdır.

Hangi CAPTCHA türleri vardır?

Her CAPTCHA aynı kullanıcı deneyimini sunmaz. Seçim yapılırken yalnızca bot engelleme oranına değil, erişilebilirliğe, mobil tarayıcı davranışına, gizlilik gereksinimlerine ve başarısız doğrulamada oluşacak destek yüküne bakılmalıdır.

“Ben robot değilim” kutusu çoğu zaman yalnızca görünen parçadır. Asıl karar; IP adresi, çerez, oturum, istek hızı, tarayıcı sinyalleri ve önceki başarısız denemeler gibi verilerin birlikte değerlendirilmesiyle verilebilir. Sağlayıcıya göre ayrıntılar değişir; veri işleme ve saklama koşulları ayrıca okunmalıdır.

Bot koruması CAPTCHA ile sınırlı mıdır?

Hayır. CAPTCHA, bot yönetiminin yalnızca bir katmanıdır. Bir bot CAPTCHA’yı aşamasa bile login endpoint’ine saniyede yüzlerce istek gönderebilir, veritabanı bağlantı havuzunu tüketebilir veya nginx worker süreçlerini meşgul edebilir. Böyle bir durumda doğrulama ekranı sunucuyu korumaya yetmez.

Birlikte uygulanması gereken katmanlar

• Oran sınırlama: IP, hesap, API anahtarı veya cihaz başına saniye ve dakika sınırları koyun.
• Hesap kilitleme: Başarısız girişleri sınırsız bırakmayın; kalıcı kilitleme yerine artan gecikme daha dengeli olabilir.
• İstek doğrulama: CSRF token’ı, beklenen Origin ve Content-Type değerlerini kontrol edin.
• Sunucu tarafı doğrulama: Form alanlarının tipini, uzunluğunu ve izin verilen değerlerini uygulamada kontrol edin.
• Ağ katmanı: Ters proxy, WAF veya CDN üzerinde açıkça tanımlanmış kurallar kullanın.
• Gözlemleme: 4xx yanıtlarını, doğrulama başarısızlıklarını ve upstream gecikmesini birlikte izleyin.

İstemciye hata dönmeden önce sunucuda pahalı bir işlem başlatılıyorsa CAPTCHA geç kalmış demektir. Dosya yükleme, parola sıfırlama ve kupon deneme gibi akışlarda doğrulama mümkün olan en erken güvenlik sınırına yerleştirilmelidir.

Bir API’nin sürekli 429 Too Many Requests üretmesi, CAPTCHA eklenerek otomatik biçimde çözülmez. İstek sahibini, sınırı ve Retry-After davranışını incelemek için Too Many Requests Ne Demek? 429 Hatası ve Çözümü yazısındaki yaklaşım kullanılabilir.

Ne yapılmalı – CAPTCHA’dan önce oran sınırlama ve istek boyutu sınırı koyun; doğrulama servisi yavaşlasa bile uygulamanızın kaynaklarını tüketmeyin.

CAPTCHA doğrulaması sunucu tarafında nasıl yapılır?

Genel akış sağlayıcıdan sağlayıcıya değişse de güvenlik sınırları aynıdır. Tarayıcıdan gelen token uygulama sunucusuna gönderilir; uygulama token’ı gizli anahtarla sağlayıcının doğrulama uç noktasına iletir. Başarılı yanıt alınmadan veritabanına kayıt yazılmaz.

POST /api/register HTTP/1.1
Content-Type: application/json

{
  "email": "kullanici@example.net",
  "password": "...",
  "captcha_token": "tarayicidan-gelen-token"
}

Uygulama sunucusu token’ı kendi doğrulama isteğinde kullanır. Aşağıdaki örnek sağlayıcıdan bağımsız akışı gösterir; gerçek endpoint, alan adları ve yanıt şeması için seçilen ürünün resmi dokümantasyonu esas alınmalıdır.

curl --fail-with-body --silent \
  -X POST "https://captcha-provider.example/verify" \
  -d "secret=${CAPTCHA_SECRET}" \
  -d "response=${CAPTCHA_TOKEN}"

--fail-with-body hata durumunda gövdeyi kaybetmeden başarısız çıkış kodu verir. Gizli anahtarı shell geçmişine yazmamak için ortam değişkeni veya gizli bilgi deposu kullanın; anahtarı HTML, JavaScript veya Git deposuna koymayın.

Kontrol edilmesi gereken alanlar

• Doğrulama yanıtı başarılı mı?
• Token belirlenen site veya hostname için mi üretildi?
• Token ilgili aksiyonla eşleşiyor mu?
• Risk puanı uygulamanın kabul eşiğini geçiyor mu?
• Token daha önce kullanılmış veya süresi dolmuş mu?
• Doğrulama servisine yapılan istek zaman aşımına uğradı mı?

CAPTCHA sağlayıcısı erişilemiyorsa uygulamanın fail-open mı, fail-closed mı davranacağı önceden belirlenmelidir. Bülten aboneliğinde kontrollü bir kuyruğa almak makul olabilir; yönetici girişi veya para transferinde doğrulama olmadan devam etmek kabul edilemez.

Ne yapılmalı – Token’ı her işlemde tek kullanımlık kabul edin ve başarı kararını yalnızca sunucu tarafındaki doğrulama yanıtına bağlayın.

CAPTCHA hangi durumlarda kullanıcı deneyimini bozar?

CAPTCHA yanlış yapılandırıldığında gerçek kullanıcıları cezalandırabilir. Mobil cihazda üçüncü taraf çerezleri engellenmiş olabilir, kurumsal proxy JavaScript’i değiştirebilir veya ekran okuyucu bir görsel testi kullanamayabilir. Aynı IP’den çıkan büyük bir ofis ya da CGNAT arkasındaki aboneler de tek bir kötü sinyal gibi görünebilir.

W3C’nin erişilebilirlik yaklaşımı, yalnızca görsel algıya dayalı bir görevin tek seçenek olarak bırakılmamasını gerektirir. Sesli alternatif, erişilebilir doğrulama akışı, klavye ile kullanım ve açık hata mesajları değerlendirilmelidir. Alternatif yöntem de aynı güvenlik seviyesini taşımalıdır; kolayca atlanabilen bir erişilebilirlik düğmesi koruma sağlamaz.

• Görevi tamamlamak için sınırsız deneme hakkı vermeyin; geçici hata ile kasıtlı başarısızlığı ayırın.
• Başarısızlık mesajında “CAPTCHA başarısız” demek yerine yeni doğrulama gerektiğini ve form verisinin korunup korunmadığını açıklayın.
• JavaScript kapalı kullanıcılar için iş akışını tamamen kırmak yerine e-posta doğrulaması veya manuel inceleme gibi alternatifleri değerlendirin.
• CAPTCHA’yı ödeme, parola sıfırlama ve yönetici erişimi gibi işlemlerde tek faktör olarak kullanmayın.

Ne yapılmalı – Klavye, ekran okuyucu ve mobil bağlantıyla test edin; gerçek kullanıcıların sürekli döngüye girdiği akışları yayına almayın.

CAPTCHA gizlilik açısından ne ifade eder?

Bir CAPTCHA hizmeti, doğrulama sırasında IP adresi, tarayıcı bilgisi, çerezler, zamanlama ve etkileşim verileri işleyebilir. Hangi verinin toplandığı, ne kadar saklandığı ve üçüncü taraflarla paylaşılıp paylaşılmadığı sağlayıcının gizlilik belgelerinde açıklanır. Bu ayrıntılar ülkeden ülkeye değişen mevzuat yükümlülükleri de doğurabilir.

Gizlilik değerlendirmesinde yalnızca çerez bildirimi yeterli değildir. Veri akışını çıkarın: tarayıcı hangi alan adına bağlanıyor, token uygulamanıza hangi değerlerle geliyor, loglara hangi tanımlayıcılar yazılıyor? Ters proxy kullanılıyorsa yanlış yapılandırılmış Proxy Nedir? Proxy Sunucu Ne İşe Yarar? içindeki temel başlıklar – istemci IP’si ve güvenilen başlıklar – ayrıca incelenmelidir.

Loglarda token’ın tamamını saklamayın. Gerekiyorsa yalnızca sağlayıcı yanıtı, aksiyon adı, zaman damgası ve red nedeninin sınırlı bir özeti tutulabilir. Hassas değerleri maskeleyin; debug seviyesini üretimde sürekli açık bırakmayın.

WordPress ve nginx üzerinde CAPTCHA nereye yerleştirilir?

WordPress’te CAPTCHA eklentisi yalnızca görünen formu koruyorsa XML-RPC, REST API, özel AJAX endpoint’leri veya parola sıfırlama akışı açık kalabilir. Korunan yolları uygulamanın gerçek istek akışıyla karşılaştırın. Yönetim paneline erişim için CAPTCHA eklemek, güçlü parola ve çok faktörlü doğrulamanın yerine geçmez.

nginx tarafında basit bir istek limiti örneği şöyledir:

http {
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

    server {
        location = /wp-login.php {
            limit_req zone=login_limit burst=3 nodelay;
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        }
    }
}

Bu yapılandırma, istemci adresi başına ortalama dakikada 5 isteğe izin verir ve kısa süreli 3 isteklik bir patlamayı kabul eder. PHP-FPM soket yolu dağıtıma göre değişir; yayına almadan önce nginx -t ile sözdizimini, ardından erişim loglarıyla gerçek davranışı kontrol edin.

sudo nginx -t
sudo systemctl reload nginx

Paylaşımlı proxy veya CDN arkasında herkes aynı IP olarak görünüyorsa $binary_remote_addr yerine gelen başlıkları doğrudan kullanmak tehlikeli olabilir. Yalnızca güvenilen proxy adreslerinden gelen ve doğru yapılandırılmış istemci IP başlığı değerlendirilmelidir. WordPress tarafındaki bellek ve PHP sorunları için WordPress Bellek Sınırı Hatası Nasıl Çözülür? başlığındaki kaynak tüketimi yaklaşımı da birlikte düşünülmelidir.

Ne yapılmalı – CAPTCHA’yı login, kayıt, yorum ve parola sıfırlama gibi tüm ilgili endpoint’lerde doğrulayın; yalnızca formun göründüğü sayfayı korumakla yetinmeyin.

Bir CAPTCHA sistemi nasıl test edilir?

Test yalnızca “kutuyu işaretledim, form gönderildi” seviyesinde bırakılmamalıdır. Başarılı, başarısız, süresi dolmuş, tekrar kullanılmış ve yanlış site için üretilmiş token senaryoları ayrı ayrı denenmelidir.

1. Geçerli token ile normal işlemi doğrulayın.
2. Token alanını silip isteği gönderin.
3. Token’ı değiştirerek doğrulama hatasını gözlemleyin.
4. Aynı token ile iki kez işlem yapmayı deneyin.
5. Doğrulama servisini zaman aşımına uğratıp uygulamanın kararını kontrol edin.
6. Hız sınırını aşan isteklerde uygulama ve proxy loglarını karşılaştırın.
7. Ekran okuyucu, klavye, dar ekran ve düşük bant genişliğiyle akışı tamamlayın.

İzlenecek metrikler arasında CAPTCHA başarı oranı, red oranı, sağlayıcı yanıt süresi, uygulama yanıt kodları, endpoint başına istek sayısı ve kullanıcıların tekrar deneme oranı bulunur. Bir anda yükselen red oranı saldırı, sağlayıcı değişikliği veya bozuk site anahtarı anlamına gelebilir.

Bir hosting ortamında bu sinyalleri Nginx access log, PHP-FPM log ve uygulama loguyla ilişkilendirmek gerekir. Yalnızca CPU kullanımına bakmak geç kalmış bir alarmdır; botlar işlemciyi doldurmadan önce bağlantı, oturum veya veritabanı havuzunu tüketebilir.

CAPTCHA kullanırken en sık yapılan hatalar

• Gizli anahtarı frontend koduna koymak.
• Token doğrulanmadan form verisini veritabanına yazmak.
• Site anahtarı ile sunucu gizli anahtarını karıştırmak.
• CAPTCHA başarısızlığında kullanıcıya sonsuz tekrar hakkı vermek.
• IP başlığını güvenilen proxy kontrolü olmadan kabul etmek.
• CAPTCHA’yı oran sınırlamanın yerine koymak.
• Loglarda token ve kişisel verileri düz metin saklamak.
• Görsel testi erişilebilir alternatif olmadan zorunlu tutmak.
• Üretim değişikliğini test etmeden yapmak.

Bir doğrulama hizmetinin yanıt vermemesi, bütün siteyi sınırsız biçimde açmak için gerekçe değildir. İş akışının riskine göre kuyruklama, geçici bakım yanıtı veya daha güçlü ikinci doğrulama seçilebilir.

CAPTCHA'yı Yayına Almadan Önce Kontrol Edin

• Token'ı sunucu tarafında doğrulayın.
• Gizli anahtarı yalnızca sunucuda saklayın.
• Token süresi dolduğunda işlemi durdurun.
• Tek kullanımlık token tekrarını reddedin.
• İlgili tüm endpoint'leri listeleyin.
• IP ve hesap bazlı oran sınırı ekleyin.
• Klavye ve ekran okuyucu testi yapın.

Sık Sorulan Sorular

Kaynaklar

• Google reCAPTCHA – Siteverify API — developers.google.com
• MDN – 429 Too Many Requests — developer.mozilla.org
• W3C WAI – Web Accessibility Initiative — w3.org
• nginx – Request Rate Limiting — nginx.org