Rate Limiting Nedir? API’ler Aşırı Kullanımdan Nasıl Korunur?

Bir API teknik olarak çalışıyor olsa bile sınırsız istek kabul etmesi güvenli değildir. Hatalı bir mobil uygulama saniyeler içinde binlerce çağrı gönderebilir, bir bot parola sıfırlama veya SMS doğrulama endpoint’ini kötüye kullanabilir, tek bir müşteri pahalı rapor sorgularıyla diğer kullanıcıların kapasitesini tüketebilir. Rate limiting, belirli bir istemcinin veya işlem türünün kabul edilen süre ve maliyet içinde ne kadar kaynak kullanabileceğini sınırlar.

Doğru oran sınırlama yalnızca “IP başına dakikada 100 istek” kuralı değildir. Kimliği doğrulanmış kullanıcı, API anahtarı, tenant, endpoint, eş zamanlı işlem, dosya boyutu veya hesaplama maliyeti gibi farklı boyutlar birlikte değerlendirilebilir. Bazı işlemler kısa trafik patlamalarını kaldırabilirken ödeme, OTP, rapor dışa aktarma veya yapay zekâ çağrıları daha katı politikalara ihtiyaç duyabilir.

Bu rehber DDoS korumasının genel katmanlarını tekrar etmez. Odak, uygulama ve API seviyesindeki rate limiting algoritmaları, 429 yanıtı, dağıtık sayaçlar, abuse önleme ve kapasiteyi kullanıcılar arasında adil biçimde paylaştırma problemidir.

Rate limiting nedir?

Rate limiting, belirli bir anahtarın tanımlı zaman aralığında yapabileceği istek, işlem veya kaynak tüketimini sınırlandırma yöntemidir. Anahtar bir IP adresi, kullanıcı hesabı, API key, şirket hesabı, cihaz veya endpoint olabilir. Limit aşıldığında istek reddedilebilir, geciktirilebilir, kuyruğa alınabilir veya daha düşük önceliğe indirilebilir.

OWASP API Security Top 10, sınırsız kaynak tüketiminin ağ, CPU, bellek ve depolamanın yanında SMS, e-posta, biyometrik doğrulama veya üçüncü taraf API maliyetlerini de tüketebileceğini belirtir OWASP API4:2023. Rate limiting bu riskin önemli kontrollerinden biridir; ancak tek başına bütün güvenlik ve kapasite sorunlarını çözmez.

Rate limiting ile throttling ve quota arasındaki fark nedir?

Bu terimler günlük kullanımda birbirinin yerine kullanılabilir; fakat tasarım sırasında ayrılmaları yararlıdır. Rate limit genellikle kısa zaman aralığındaki istek hızını sınırlar. Throttling, aşırı trafiği reddetme veya kontrollü biçimde yavaşlatma davranışıdır. Quota ise saatlik, günlük veya aylık toplam kullanım hakkını ifade edebilir.

Google Cloud Apigee dokümantasyonu, SpikeArrest politikasını ani trafik yükselişlerini yumuşatan koruma; Quota politikasını ise daha uzun dönemli kullanım miktarını sınırlayan kontrol olarak ayırır Apigee Rate Limiting Politikaları. Bir API aynı anda saniyelik burst limiti, dakikalık işlem limiti ve aylık paket kotası uygulayabilir.

API’lerde neden rate limiting gerekir?

• Kapasite koruması: Veritabanı, worker, üçüncü taraf API veya işlemci kaynaklarının kaldırabileceği yük aşılmaz.
• Adil kullanım: Tek müşteri veya entegrasyon diğer kullanıcıların kapasitesini tüketmez.
• Brute-force azaltma: Giriş, OTP, parola sıfırlama ve kod doğrulama akışları seri denemelere karşı sınırlandırılır.
• Maliyet kontrolü: SMS, e-posta, harita, ödeme, yapay zekâ veya dış veri çağrılarının kontrolsüz faturası önlenir.
• Hatalı istemci koruması: Sonsuz döngüye giren uygulama veya yanlış retry politikası backend’i çökertmez.
• Ürün paketleri: Ücretsiz ve ücretli planlara farklı kullanım hakları uygulanabilir.
• Hassas iş akışları: Bilet, rezervasyon, kupon veya stok toplama gibi otomasyona açık süreçler korunur.

OWASP, hassas iş akışlarına otomasyonla aşırı erişimin işletme modelini bozabileceğini ve sınırların iş bağlamına göre belirlenmesi gerektiğini vurgular OWASP API6:2023.

Rate limit hangi kimliğe göre uygulanmalıdır?

Limit anahtarı yanlış seçilirse gerçek kullanıcılar engellenebilir veya saldırgan kolayca sınırı aşabilir. IP adresi kimliği doğrulanmamış trafik için yararlıdır; fakat aynı kurumsal ağ, mobil operatör veya NAT arkasındaki çok sayıda kullanıcı tek IP’yi paylaşabilir. Saldırgan ise proxy ağıyla IP değiştirebilir.

Çoğu üretim sisteminde tek anahtar yerine katmanlı politika gerekir. Örneğin anonim IP limiti, kullanıcı limiti, tenant limiti ve pahalı endpoint limiti birlikte uygulanabilir. API entegrasyonu planlanırken partner, son kullanıcı ve dahili servis trafiği aynı kurala zorlanmamalıdır.

Fixed window algoritması nasıl çalışır?

Fixed window, zamanı sabit bölümlere ayırır. Kullanıcı için 14.30–14.31 arasında belirli sayıda istek sayılır; pencere değiştiğinde sayaç sıfırlanır. Uygulaması basittir ve Redis gibi ortak sayaç deposunda atomik artış ile süre sonu kullanılarak dağıtık biçimde kurulabilir.

Temel sorun pencere sınırıdır. İstemci bir dakikanın sonunda bütün hakkını, yeni dakikanın başında da yeni hakkını kullanarak çok kısa sürede iki pencerenin toplamına yakın trafik oluşturabilir. Düşük riskli endpoint’lerde bu kabul edilebilirken kritik kapasite veya abuse kontrolünde daha dengeli algoritma gerekebilir.

Sliding window algoritmaları ne sağlar?

Sliding window, son sabit takvim dakikası yerine isteğin yapıldığı andan geriye doğru gerçek bir zaman aralığını değerlendirir. Sliding window log yaklaşımında her isteğin zamanı saklanır ve pencere dışındaki kayıtlar silinir. Doğru ve adil sonuç verir; ancak yüksek trafikte daha fazla bellek ve işlem maliyeti oluşturur.

Sliding window counter ise önceki ve mevcut sabit pencere sayaçlarını ağırlıklandırarak yaklaşık bir kayan pencere üretir. Daha az veri saklar, fakat tam log kadar kesin değildir. Redis’in resmî rate limiting eğitiminde fixed window, sliding window log, sliding window counter, token bucket ve leaky bucket yaklaşımlarının doğruluk, burst ve kaynak maliyeti farklılıkları karşılaştırılır Redis Rate Limiting Algoritmaları.

Token bucket nasıl çalışır?

Token bucket modelinde her istemci için belirli kapasitede bir kova düşünülür. Kova sabit hızda token ile dolar; her istek bir veya işlemin maliyetine göre birden fazla token tüketir. Token yoksa istek reddedilir veya bekletilir.

Bu model sürdürülebilir ortalama hızı korurken kısa süreli burst trafiğine izin verir. Kullanıcı uzun süre istek göndermediyse biriken token’larla kısa sürede daha fazla çağrı yapabilir. AWS API Gateway, istek throttling için token bucket algoritmasını ve ayrı rate ile burst kapasitesini kullanır AWS API Gateway Throttling.

Redis’in resmî rate limiter rehberi, dağıtık token bucket uygulamasını Redis ve atomik Lua işlemleriyle örnekler Redis Rate Limiter. Dağıtık sistemde token hesaplama ve tüketme işlemi atomik değilse eş zamanlı sunucular limitin üzerinde istek kabul edebilir.

Leaky bucket ne zaman kullanılır?

Leaky bucket yaklaşımı, gelen trafiği belirli hızda akan bir çıkışa dönüştürür. Kapasite içindeki burst istekleri kısa süre bekletilebilir; kova dolduğunda yeni istekler reddedilir. Amaç yalnızca toplam sayıyı sınırlamak değil, backend’e giden akışı daha düzgün hale getirmektir.

NGINX’in limit_req modülü, tanımlanmış anahtara göre istek işleme hızını leaky bucket yöntemiyle sınırlar ve burst ile geciktirme davranışını yapılandırabilir NGINX limit_req Modülü. Uzun bekleme kullanıcı deneyimini kötüleştirebileceği için geciktirme ve doğrudan reddetme kararı endpoint’e göre verilmelidir.

Algoritma seçimi nasıl yapılmalıdır?

Bir algoritmanın teorik doğruluğu tek karar kriteri değildir. Sayaç depolama maliyeti, global tutarlılık ihtiyacı, izin verilen burst, kullanıcı deneyimi ve limit servisinin kendisinin gecikmesi birlikte değerlendirilmelidir.

İstek sayısı yerine işlem maliyeti sınırlandırılabilir mi?

Her API çağrısı aynı maliyette değildir. Basit profil okuma ile geniş tarih aralığında rapor üretme aynı sayaca bir istek olarak yazılırsa pahalı endpoint sistem kapasitesini tüketebilir. Maliyet bazlı limiting, operasyonlara farklı ağırlık verir.

GitHub REST API, bazı ikincil limitlerde yalnızca istek sayısını değil eş zamanlı çağrıları ve işlem maliyetini de dikkate alır; rate limit aşıldığında istemcilerin Retry-After veya reset bilgisine uymasını ister GitHub REST API Rate Limits. GraphQL sistemlerinde sorgu karmaşıklığı, yapay zekâ servislerinde token sayısı, dosya işlemlerinde boyut veya tahmini CPU süresi maliyet birimi olabilir.

429 Too Many Requests yanıtı nasıl olmalıdır?

RFC 6585, belirli zaman aralığında çok fazla istek yapan istemci için 429 Too Many Requests durum kodunu tanımlar. Yanıtın limit koşulunu açıklayabileceğini ve istemcinin ne kadar beklemesi gerektiğini belirten Retry-After başlığını içerebileceğini söyler RFC 6585.

• İstemciye hangi genel limit kategorisinin aşıldığını açıklayın.
• Uygunsa Retry-After ile yeniden deneme zamanını verin.
• API dokümantasyonunda limit kapsamını ve reset davranışını belirtin.
• İç kapasite, güvenlik kuralı veya başka kullanıcı bilgilerini açığa çıkarmayın.
• İstemcinin exponential backoff ve jitter kullanmasını önerin.
• 429 yanıtını sonsuz hızlı retry döngüsüne sokmayın.

Rate limiting yalnızca API gateway’de mi uygulanmalıdır?

Gateway veya reverse proxy, genel istek hızı ve IP tabanlı burst koruması için uygun noktadır. Fakat yalnızca gateway iş bağlamını bilmeyebilir. Bir kullanıcının SMS gönderme, kupon oluşturma veya rapor üretme limiti uygulama servisinde daha doğru hesaplanabilir.

Katmanlı yaklaşımda edge katmanı kaba trafik patlamalarını, API gateway client veya API key limitlerini, uygulama katmanı ise iş kuralı ve kaynak maliyetini sınırlar. özel web yazılım projelerinde bu sorumlulukların tek noktaya yığılması yerine hangi katmanın hangi riski gördüğü belirlenmelidir.

Dağıtık rate limiter nasıl tasarlanır?

Birden fazla uygulama sunucusu kendi belleğinde ayrı sayaç tutarsa gerçek limit sunucu sayısıyla çarpılabilir. Ortak Redis, rate limit servisi veya gateway tabanlı merkezi sayaç kullanılması gerekir. Sayaç artışı, TTL kontrolü ve limit kararı atomik olmalıdır.

• Sayaç anahtarının kullanıcı, endpoint ve zaman kapsamını açık tanımlayın.
• Atomik komut veya script ile yarış koşullarını önleyin.
• Sunucu saatleri arasındaki farkı azaltın veya merkezi zaman kaynağı kullanın.
• Çok bölgeli sistemde kesin global limit ile düşük gecikme arasındaki trade-off’u belirleyin.
• Limit deposu yavaşladığında bütün istek yolunun etkilenmesini ölçün.
• Anahtar sayısı ve TTL nedeniyle oluşan bellek büyümesini izleyin.

Rate limiter çökerse fail-open mı fail-closed mı olmalıdır?

Fail-open davranışında limit sistemi erişilemezse istek kabul edilir. Kullanıcı deneyimi korunur; fakat abuse ve kapasite riski artar. Fail-closed davranışında karar verilemeyen istek reddedilir. Güvenlik korunabilir; fakat limiter arızası bütün API’yi kullanılmaz hale getirebilir.

Tek bir politika bütün endpoint’lere uygun değildir. Genel içerik okuma fail-open çalışabilirken OTP, ödeme veya pahalı dış servis çağrısı fail-closed ya da düşük acil durum limitiyle çalışabilir. Lokal yedek sayaç, circuit breaker ve önceden tanımlanmış degrade mod kullanılabilir.

Rate limiting ile DDoS koruması arasındaki fark nedir?

Rate limiting, uygulama veya API seviyesindeki istek sıklığını ve iş kullanımını yönetir. Büyük hacimli ağ saldırılarında trafik uygulamaya ulaşmadan önce CDN, WAF, ağ sağlayıcısı ve DDoS koruma hizmetleri devreye girmelidir. Uygulama içindeki Redis sayacı, bağlantı veya bant genişliği daha önce tükendiyse sistemi kurtaramaz.

Bu nedenle rate limiting DDoS korumasının yerine geçmez. Aynı şekilde WAF kullanmak da kullanıcı başına SMS, rapor veya ödeme denemesi limitini otomatik olarak çözmez. Her katman farklı riski kontrol eder.

Proxy arkasında gerçek IP nasıl güvenli alınır?

Uygulama reverse proxy veya CDN arkasındaysa doğrudan bağlantı adresi proxy’ye ait olabilir. X-Forwarded-For gibi başlıklar yalnızca güvenilen proxy tarafından yazıldığında kullanılmalıdır. İstemcinin doğrudan gönderdiği başlığa güvenmek, saldırganın IP anahtarını kolayca değiştirmesine izin verir.

Güvenilen proxy zinciri, gerçek IP çıkarma kuralı ve IPv6 normalizasyonu açık biçimde yapılandırılmalıdır. Yine de IP tek başına güvenilir kullanıcı kimliği değildir; anonim katmandaki sinyallerden biri olarak değerlendirilmelidir.

Limit değerleri nasıl belirlenmelidir?

Rastgele yuvarlak sayılar üretmek yerine gerçek trafik ve kapasite ölçülmelidir. Normal kullanıcıların istek dağılımı, yoğun kullanım seviyeleri, backend doygunluk noktası, üçüncü taraf maliyeti ve hassas iş akışlarındaki insan davranışı birlikte analiz edilir.

1. Endpoint’leri kaynak maliyeti ve abuse riskine göre sınıflandırın.
2. Normal ve yoğun kullanıcı davranışını ölçün.
3. Backend’in sürdürülebilir ve burst kapasitesini yük testiyle belirleyin.
4. İlk limitleri normal kullanıcıyı engellemeyecek kadar toleranslı kurun.
5. Dry-run veya yalnızca gözlem modunda ihlalleri inceleyin.
6. 429 oranı ve destek taleplerine göre limitleri kademeli ayarlayın.
7. Ücretsiz, ücretli ve güvenilir partner seviyelerini ayrı yönetin.

Hangi metrikler izlenmelidir?

Toplam reddedilen istek sayısı tek başına yeterli değildir. Limit anahtarı, endpoint, tenant ve algoritma bazında kararlar görülebilmelidir. Yanlış limit gerçek kullanıcıyı etkilerken saldırı trafiği farklı anahtarlar altında saklanabilir.

• İzin verilen, geciktirilen ve reddedilen istek sayısı.
• Endpoint ve müşteri planı bazında 429 oranı.
• En çok limit aşan kullanıcı, API key veya IP grupları.
• Rate limiter karar gecikmesi ve veri deposu hata oranı.
• Redis anahtar sayısı, bellek kullanımı ve script süresi.
• Backend doygunluğu ile rate limit kararlarının korelasyonu.
• SMS, e-posta veya dış API maliyetindeki değişim.
• Normal kullanıcıların yanlış pozitif engellenme oranı.

En sık yapılan rate limiting hataları

1. Bütün endpoint’lere aynı limit değerini uygulamak.
2. Yalnızca IP adresine güvenmek.
3. Proxy başlıklarını doğrulamadan istemci IP’si kabul etmek.
4. Dağıtık sunucularda yerel bellek sayaçlarını ortak limit sanmak.
5. 429 yanıtında bekleme veya reset bilgisi vermemek.
6. İstemci retry’larını burst ve backoff açısından test etmemek.
7. Yalnızca istek sayısını ölçüp pahalı işlem maliyetini görmezden gelmek.
8. Limiter arızasında fail-open veya fail-closed kararını tanımlamamak.
9. Rate limiting’i kimlik doğrulama ve yetkilendirme yerine kullanmak.
10. Limitleri gerçek trafik ölçmeden aşırı katı veya gevşek belirlemek.

Uygulama öncesi rate limiting kontrol listesi

1. Korunacak risk kapasite, maliyet, brute-force veya iş akışı abuse’u mu?
2. Limit IP, kullanıcı, API key, tenant, endpoint veya kaynak bazında mı olacak?
3. Sürdürülebilir hız ve izin verilen burst ayrı belirlendi mi?
4. Fixed window, sliding window, token bucket veya leaky bucket seçimi gerekçeli mi?
5. Dağıtık sayaç işlemleri atomik mi?
6. 429 yanıtı ve Retry-After davranışı dokümante edildi mi?
7. İstemciler exponential backoff ve jitter kullanıyor mu?
8. Rate limiter arızasında endpoint bazlı fallback tanımlı mı?
9. Proxy arkasında gerçek IP güvenli biçimde çıkarılıyor mu?
10. Yanlış pozitifler, reddedilen trafik ve maliyet etkisi izleniyor mu?

Sonuç: Rate limiting bir sayı değil, kapasite politikasıdır

Rate limiting, API’yi aşırı kullanım, hatalı istemci, brute-force ve kontrolsüz maliyetten koruyan temel bir uygulama katmanı kontrolüdür. Başarılı tasarım yalnızca dakikalık istek sayısı belirlemez; kimliğin nasıl tanındığını, burst davranışını, işlem maliyetini, 429 cevabını ve dağıtık sayaçların nasıl tutulduğunu birlikte çözer.

Fixed window basit başlangıçlar için yeterli olabilir, sliding window daha adil zaman değerlendirmesi sağlar, token bucket kontrollü burst’lere izin verir ve leaky bucket backend’e giden akışı yumuşatır. Doğru yöntem, endpoint’in iş riski ve sistem kapasitesine göre seçilmeli; gerçek trafik altında ölçülerek kademeli biçimde ayarlanmalıdır.