API Güvenliği: Rate Limit ve WAF Neyi Çözer, Neyi Çözmez?

API'ler neden ayrı bir güvenlik konusudur?

API, uygulamanın veri ve işlem kapısıdır; çoğu zaman tarayıcı arayüzünden daha az sınırlama içerir. Saldırgan bir formu doldurmaz, doğrudan uç noktayı çağırır ve parametreleri değiştirir. Bu yüzden web sitesi için işe yarayan "ziyaretçi insan mı?" sorusu API'lerde yetersiz kalır.

OWASP API Security Top 10 listesi bu riskleri sıralar. Başlıkları kısaca:

• BOLA (nesne düzeyinde yetki ihlali): /orders/123 yerine /orders/124 isteyip başkasının verisini okumak.
• Bozuk kimlik doğrulama: zayıf token üretimi, süresiz token, brute force'a açık giriş.
• Sınırsız kaynak tüketimi: hız sınırı, boyut sınırı ve sayfalama sınırı olmayan uç noktalar.
• Bozuk işlev düzeyinde yetki: normal kullanıcının yönetici uç noktasını çağırabilmesi.
• SSRF, yanlış yapılandırma, envanter eksikliği: unutulmuş eski sürümlerin hâlâ açık olması.

WAF ve hız sınırı neyi yapar, neyi yapmaz?

Dengeli bir beklenti için ayırın:

WAF, isteğin geçerli ama yetkisiz olduğunu bilemez. GET /orders/124 sözdizimi olarak temizdir; o siparişin bu kullanıcıya ait olmadığını yalnızca uygulama bilir. WAF'ın genel çalışması için WAF nedir rehberine bakın.

Hız sınırı nasıl tasarlanır?

Anahtarı seçin. IP tek başına kaba bir anahtardır: aynı ofis veya mobil operatör NAT'ı arkasındaki yüzlerce müşteri tek IP görünür. Kimlikli API'lerde token başına sınır daha adildir; IP sınırını ikinci katman olarak tutun.

Pencereyi seçin. Sabit pencere, dakikanın başında patlamaya izin verir. Kayan pencere daha düzgün sonuç verir.

Reddi iyi bildirin. Sınır aşılınca 429 Too Many Requests döndürün (RFC 6585) ve ne kadar bekleneceğini Retry-After başlığıyla söyleyin (RFC 9110). İyi istemciler bu değere göre geri çekilir; gövdesiz bir 429 ise yeniden deneme fırtınası doğurur.

Maliyete göre ağırlıklandırın. Arama uç noktası ile sağlık kontrolü aynı limiti paylaşmamalıdır.

Token kapsamları ve idempotency

Her token, yalnızca ihtiyaç duyduğu işlemi yapabilmelidir (en az yetki). Salt okuma token'ı ile site oluşturan token'ı ayırın; sızan bir token'ın zararı böylece sınırlı kalır. Token'ları süreli yapın ve düzenli döndürün.

Idempotency anahtarı, aynı isteğin ağ hatası sonrası tekrarında işlemin yinelenmesini önler. İstemci her mantıksal işlem için benzersiz bir değer gönderir, sunucu aynı değeri görünce ilk yanıtı geri verir. Ödeme ve kaynak oluşturma çağrılarında özellikle işe yarar.

Webhook ve mobil uygulamalar

Tarayıcıya yönelik doğrulama sayfaları (CAPTCHA, proof-of-work) JavaScript çalıştırmayan istemcilerde işlemez. Webhook gönderen bir ödeme sistemi, mobil uygulama veya sunucudan sunucuya çağrı bu sayfayı çözemez; engellenir. Çözüm, bu yolları ayrı ele almaktır: webhook'ları imza doğrulamasıyla kendi tarafınızda koruyun, yolu doğrulama sayfasından hariç tutun ve IP veya hız sınırıyla sınırlayın. Bot tarafının nasıl ele alındığını bot koruması rehberinde bulabilirsiniz.

Sık yapılan hatalar

• Tek global limit. Giriş ve parola sıfırlama uç noktalarına, genel okuma uç noktalarından çok daha sıkı bir sınır gerekir.
• Sınırı yalnızca kenarda tutmak. Proxy sınırı yanında uygulama içinde de kaynak başına denetim bırakın; proxy atlanırsa son savunma uygulamadır.
• Token'ı URL'ye koymak. Sorgu dizesindeki token erişim günlüklerine, tarayıcı geçmişine ve referrer'a sızar. Başlık kullanın.
• Sınırı bildirmemek. İstemci sınırı bilmiyorsa körlemesine yeniden dener; sınırı belgeleyin.

Hata yanıtları ve envanter

Ayrıntılı hata mesajları saldırgana yol gösterir: yığın izi, SQL hata metni veya dosya yolu bilgi sızdırır (CWE-209). API'nizde istemciye genel bir mesaj ve bir korelasyon kimliği, sunucu günlüğünde ayrıntı bırakın.

Envanter de güvenlik işidir. /v1 ile birlikte unutulmuş /v0 hâlâ yayında olabilir ve eski, yamasız bir kod yolunu açık tutar. Yayındaki her sürümü, her ortamı (staging dahil) ve her uç noktayı listeleyin; kullanılmayanı kapatın. Staging'i kimlik katmanının arkasına almak için Zero Trust rehberine bakın.

curl -s https://shield.nexren.info/api/v1/whoami \
  -H "Authorization: Bearer YOUR_API_TOKEN"

Kontrol listesi

1. Her uç nokta sahiplik ve rol denetimi yapıyor mu? (BOLA)
2. Token'lar kapsamlı, süreli ve döndürülebilir mi?
3. Hız sınırı token ve IP için ayrı ayrı tanımlı mı?
4. 429 yanıtları Retry-After içeriyor mu?
5. Webhook ve mobil yolları doğrulama sayfasından hariç tutuldu mu, imza doğrulaması var mı?
6. Eski API sürümleri envanterde ve kapalı mı?

Kaynaklar

• OWASP API Security Project
• RFC 6585: 429 Too Many Requests
• RFC 9110: HTTP Semantics (Retry-After)

İlgili ürün sayfaları:Teknoloji