Rate Limiting Nedir? API Güvenliği Nasıl Sağlanır? (2026)

Rate limiting nedir? Rate limiting (istek sınırlandırma), bir API’ye veya web sitesine belirli bir zaman aralığında yapılabilecek istek sayısını sınırlayarak sunucuyu aşırı yükten, kötüye kullanımdan ve otomatik saldırılardan koruyan bir teknik. 2026 itibarıyla hem küçük WordPress siteleri hem de büyük ölçekli API servisleri için rate limiting, temel bir güvenlik ve kararlılık önlemi haline geldi; özellikle otomatik botların ve veri kazıma araçlarının yaygınlaşmasıyla birlikte, sınırlandırma mekanizması olmayan sistemler çok daha hızlı biçimde aşırı yüke maruz kalabiliyor. Bu rehberde rate limiting’in nasıl çalıştığını, en yaygın algoritmaları, WordPress ve Laravel üzerinde nasıl uygulanacağını, sunucu seviyesinde Nginx ile nasıl yapılandırılacağını ve bu süreçte sık yapılan hataları örnek kod parçalarıyla ele alıyoruz.

Rate Limiting Nedir, Neden Gereklidir?

Bir web sitesi veya API, gelen her isteği sınırsız biçimde işlemeye çalışırsa, hem kötü niyetli botlar hem de hatalı yapılandırılmış istemciler sunucuyu kısa sürede tüketebilir. Rate limiting, “bu IP adresi veya bu kullanıcı, şu zaman aralığında en fazla şu kadar istek yapabilir” kuralını uygulayarak bu riski azaltır. Sınırı aşan istekler genellikle HTTP 429 (Too Many Requests) durum koduyla reddedilir.

Rate Limiting Hangi Sorunları Çözer?

Rate limiting uygulamasının pratikte çözdüğü başlıca sorunlar şunlardır: kaba kuvvet (brute-force) giriş denemelerinin engellenmesi, otomatik kazıma (scraping) botlarının yavaşlatılması, API maliyetlerinin öngörülebilir kalması ve sunucu kaynaklarının adil biçimde paylaşılması. Bu konuda daha geniş bir bakış açısı için DDoS saldırıları ve korunma yöntemleri rehberimize de göz atabilirsiniz; rate limiting, DDoS savunmasının yalnızca bir katmanını oluşturur.

Rate Limiting Uygulanmazsa Ne Olur?

Rate limiting olmayan bir API veya web sitesinde, tek bir kötü niyetli aktör veya hatalı yapılandırılmış bir istemci, sunucu kaynaklarının tamamını tüketebilir. Bu durum yalnızca o isteği gönderen kullanıcıyı değil, aynı sunucuyu paylaşan tüm ziyaretçileri etkiler; sitenin yavaşlaması, zaman aşımı hataları veya tamamen erişilemez hale gelmesiyle sonuçlanabilir. Özellikle üçüncü taraf API’lere bağımlı sistemlerde, kontrolsüz istek trafiği hem kendi sunucunuzu hem de bağlı olduğunuz servisin faturalandırma limitlerini olumsuz etkileyebilir; bazı API sağlayıcıları, aşırı istek gönderen hesapları geçici veya kalıcı olarak engelleyebiliyor.

Rate Limiting Algoritmaları Nasıl Çalışır?

Rate limiting’i uygulamanın birden fazla yolu var ve her algoritmanın kendine özgü avantaj ve dezavantajları bulunuyor.

Fixed Window (Sabit Pencere)

Sabit pencerede her aralık kendi sayacını tutar. Bir dakikanın son saniyesinde 60, sonraki dakikanın ilk saniyesinde 60 istek kabul edilirse, her pencerenin kuralına uyulduğu halde iki saniyede 120 istek oluşabilir. Sorun, pencere başına sınırın aşılması değil, sınır geçişindeki kısa süreli yığılmadır.

Sliding Window (Kayan Pencere)

Kayan pencerenin farklı uygulamaları vardır. Sliding window log, son süre içindeki istek zamanlarını tutar; sliding window counter ise bitişik pencerelerin sayaçlarını ağırlıklandırarak yaklaşık bir sonuç üretir. Bellek kullanımı ve doğruluk bu iki yöntemde aynı değildir.

Token Bucket (Jeton Kovası)

Bu modelde her istemciye belirli bir hızda dolan bir “jeton kovası” tanımlanır; her istek bir jeton tüketir, kova boşsa istek reddedilir. Token bucket, kısa süreli ani yoğunluklara (burst) belirli ölçüde izin verirken uzun vadeli ortalama hızı sınırlar; bu esneklik onu API’ler için en sık tercih edilen yöntemlerden biri yapıyor.

Leaky Bucket (Sızdıran Kova)

Leaky bucket, gelen istekleri bir kuyruğa alıp sabit bir hızda işleyerek çıktığı bir modele dayanır; kuyruk dolduğunda yeni istekler reddedilir. Bu yöntem çıkışta çok düzenli, sabit bir hız garantisi sunar, bu da onu arka uç sistemlerin aşırı yüklenmesini önlemek için elverişli kılar.

Algoritma Karşılaştırma Tablosu

WordPress’te Rate Limiting: Giriş Denemelerini Sınırlama

WordPress giriş uçlarında, hesap ve IP bazlı denemeleri birlikte değerlendiren bir WAF veya güncellenen giriş koruma eklentisi kullanın. Transient değerini okuyup bir artırarak geri yazan basit PHP parçaları atomik değildir: eşzamanlı isteklerde sayım kaybolabilir. Her hatada süreyi yenilemek de sabit pencere sayılmaz; kullanıcı adını değiştirmek tek anahtarlı korumayı aşabilir.

WordPress giriş korumasını doğrulama

1. Önce deneme sitesinde bir hesap ve farklı IP senaryolarıyla eşiği kontrol edin.
2. Ortak IP kullanan meşru kullanıcıların topluca kilitlenmediğini doğrulayın.
3. CDN varsa gerçek istemci IP adresini yalnızca güvenilir proxy zincirinden alın.
4. Kilit süresinin dolmasını, başarılı giriş sonrasını ve XML-RPC gibi diğer kimlik doğrulama yollarını ayrıca test edin.

API Tarafında Rate Limiting: Laravel Throttle Middleware

Laravel gibi modern PHP çatıları, rate limiting’i yerleşik middleware üzerinden sunuyor. Bu, kendi algoritmanızı sıfırdan yazmak yerine hazır ve test edilmiş bir çözümü hızlıca devreye almanızı sağlıyor.

Kod Örneği: Route Bazlı Throttle Tanımlama

use Illuminate\Support\Facades\Route;
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function ($request) {
    return Limit::perMinute(60)->by($request->user() ? 'user:'.$request->user()->id : 'ip:'.$request->ip());
});

Route::middleware(['throttle:api'])->group(function () {
    Route::get('/urunler', [UrunController::class, 'index']);
});

RateLimiter::for tanımını servis sağlayıcısının boot() metoduna, Route tanımını uygun rota dosyasına koyun; UrunController için kendi sınıfınızı içe aktarın. Kullanıcı kimliğine göre sınırlamak istiyorsanız kimlik doğrulama middleware katmanı önce çalışmalıdır. Birden çok uygulama sunucusunda ortak sayaç deposu kullanın. Laravel throttle sınır aşıldığında 429 yanıtı üretir. Laravel rate limiting belgesi.

Sunucu Seviyesinde Rate Limiting: Nginx Örneği

Uygulama koduna dokunmadan, sunucu seviyesinde de rate limiting uygulanabilir. Bu yaklaşım özellikle kod tabanına erişiminiz olmayan veya birden fazla uygulamayı aynı sunucuda barındırdığınız durumlarda pratik bir çözüm sunar.

Kod Örneği: Nginx limit_req_zone Yapılandırması

http {
    limit_req_zone $binary_remote_addr zone=genel_limit:10m rate=10r/s;

    server {
        location /api/ {
            limit_req zone=genel_limit burst=20 nodelay;
            limit_req_status 429;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

Bu örnekteki 127.0.0.1:8080 adresini kendi uygulamanızın adresiyle değiştirin. Nginx limit_req varsayılan olarak 503 döndürür; burada 429 açıkça ayarlanmıştır. nodelay, izin verilen burst isteklerini bekletmeden geçirir; her isteği eşit aralıkla çalıştırma garantisi vermez. Retry-After başlığı bu yapılandırmayla otomatik eklenmez. Değişiklikten önce nginx -t ile yapılandırmayı doğrulayın. Nginx limit_req belgesi.

Rate Limiting Başlıkları ve İstemci Tarafı En İyi Uygulamalar

İyi tasarlanmış bir rate limiting sisteminin yalnızca isteği reddetmesi yeterli değildir; istemciye durumu net biçimde bildirmesi de en az o kadar önemlidir. Bu amaçla yaygın olarak kullanılan HTTP başlıkları şunlardır:

• X-RateLimit-Limit: İlgili zaman penceresinde izin verilen toplam istek sayısı.
• X-RateLimit-Remaining: Mevcut pencerede kalan istek hakkı.
• X-RateLimit-Reset: Limitin sıfırlanacağı zaman damgası.
• Retry-After: Bekleme süresini saniye veya HTTP tarih değeri olarak bildirebilir; istemci her iki biçimi de ele almalıdır. RFC 9110.

Bu başlıkları döndüren bir API, entegrasyon yapan geliştiricilerin kendi istemci kodlarında akıllı “geri çekilme” (backoff) mantığı kurmasına imkân tanır; bu da hem sizin sunucunuzun hem de karşı tarafın gereksiz yere tekrarlayan başarısız isteklerle uğraşmasını önler.

CDN ve Ağ Seviyesinde Rate Limiting: Cloudflare Örneği

Uygulama veya sunucu yapılandırmasına hiç dokunmadan rate limiting uygulamanın bir başka yolu, Cloudflare gibi bir CDN/WAF katmanı kullanmaktır. Bu servisler, trafiği kendi ağlarında, sizin sunucunuza ulaşmadan önce filtreleyebiliyor; bu da hem sunucu kaynaklarınızı korur hem de kötü niyetli trafiği kaynağa daha yakın bir noktada durdurmuş olur. Cloudflare’in ücretsiz planında bile temel oranlı sınırlama kuralları tanımlanabiliyor; kurumsal planlarda ise IP itibarına, coğrafi konuma veya istek imzasına göre çok daha ayrıntılı kurallar oluşturmak mümkün. Bu tür bir katmanı, uygulama seviyesindeki rate limiting’in yerine değil, onu tamamlayan ek bir güvenlik halkası olarak düşünmek en sağlıklı yaklaşım.

Adım Adım: Kendi Servisinize Rate Limiting Ekleme

1. Hangi uç noktaların (login, arama, ödeme, dosya yükleme gibi) en fazla kötüye kullanım riski taşıdığını belirleyin.
2. Her uç nokta için makul bir istek/dakika veya istek/saniye limiti belirleyin; gerçek kullanıcı trafiğinizi analiz ederek başlayın.
3. Uygulama seviyesinde (Laravel throttle, WordPress giriş koruma eklentisi) veya sunucu seviyesinde (Nginx, Cloudflare) uygun katmanı seçin.
4. 429 yanıtlarına `Retry-After` başlığı ekleyerek istemcilerin ne zaman tekrar deneyebileceğini bildirin.
5. Sınırı aşan istekleri loglayın ve düzenli olarak inceleyerek limitlerin çok sıkı veya çok gevşek olup olmadığını değerlendirin.
6. Meşru kullanıcıların yanlışlıkla engellenmediğinden emin olmak için üretime almadan önce gerçekçi trafik senaryolarıyla test edin.

Farklı Kimlik Doğrulama Yöntemlerine Göre Rate Limiting Stratejisi

Rate limiting kuralınızı kime göre uygulayacağınız, sisteminizin kimlik doğrulama modeline göre değişir. Anonim, kimlik doğrulaması olmayan trafik için genellikle IP adresi tek pratik seçenektir; ancak kimliği doğrulanmış kullanıcılar için kullanıcı ID’si veya API anahtarı bazlı sınırlama çok daha adil sonuçlar verir, çünkü aynı ofisten veya mobil operatör üzerinden bağlanan farklı kullanıcılar aynı IP’yi paylaşabilir.

API Anahtarı Bazlı Sınırlama

Herkese açık bir API sunuyorsanız, her istemciye özel bir API anahtarı vermek ve limitleri bu anahtar üzerinden takip etmek, hem güvenlik hem de faturalandırma açısından avantaj sağlar. Bu yaklaşım aynı zamanda farklı abonelik katmanlarına (ücretsiz, pro, kurumsal) farklı limitler tanımlamanıza da olanak tanır.

JWT / Oturum Bazlı Sınırlama

JWT içindeki kullanıcı kimliğine ancak token imzası, süresi ve gerekli issuer/audience kontrolleri doğrulandıktan sonra güvenin. Doğrulanmamış payload içindeki bir kimliği limit anahtarı yapmak, saldırganın sayaç değiştirmesine izin verir. CDN veya reverse proxy arkasında da X-Forwarded-For başlığına tüm kaynaklardan güvenmeyin; yalnızca tanımlı güvenilir proxy adreslerinden gelen bilgiyi kullanın.

Mikroservis Mimarisinde Merkezi Sınırlama

Birden fazla mikroservisten oluşan bir sistemde, rate limiting’i genellikle API Gateway katmanında merkezi olarak uygulamak, her servise ayrı ayrı mantık eklemekten daha tutarlı ve yönetilebilir bir sonuç verir; kritik servisler için ayrıca servis içi ek bir sınırlama katmanı da düşünülebilir. Bu yaklaşım, farklı programlama dilleriyle yazılmış servislerin tutarlı bir sınırlama politikasına uymasını da kolaylaştırır.

Rate Limiting’in Yan Etkileri ve Dengelenmesi Gereken Riskler

Rate limiting güçlü bir koruma sağlasa da, yanlış yapılandırıldığında kendi kullanıcılarınıza zarar verebilecek bir araç haline gelebilir. Örneğin çok düşük bir limit, yoğun kullanım dönemlerinde (kampanya, lansman günü gibi) meşru kullanıcıların hizmet dışı kalmasına neden olabilir. Bunun tersine, çok yüksek bir limit ise sistemi kötüye kullanıma karşı yeterince korumayabilir. Bu dengeyi bulmanın en güvenilir yolu, üretim ortamına almadan önce gerçekçi yük testleri yapmak ve canlıya aldıktan sonra da metrikleri (429 oranı, hangi uç noktalarda yoğunlaştığı) düzenli olarak izlemektir. Ayrıca statik bir limit yerine, güvenilir/kimliği doğrulanmış kullanıcılara daha yüksek, şüpheli veya anonim trafiğe daha düşük limit uygulayan katmanlı bir yaklaşım da tercih edilebilir.

Sık Yapılan Hatalar ve Çözümleri

1. Hata: Tüm Uç Noktalara Aynı Limiti Uygulamak

Giriş sayfası ile statik bir görsel isteğine aynı limiti uygulamak, ya güvenlik açığı bırakır ya da meşru kullanıcıları gereksiz yere engeller. Çözüm: Her uç noktanın risk seviyesine göre farklı limitler belirleyin.

2. Hata: Yalnızca IP Adresine Göre Sınırlama Yapmak

Paylaşımlı ağlarda (kurumsal ofis, üniversite kampüsü) birçok kullanıcı aynı IP adresini paylaşabilir; yalnızca IP bazlı sınırlama bu kullanıcıları toplu olarak cezalandırabilir. Çözüm: Mümkünse kimliği doğrulanmış kullanıcılarda kullanıcı ID’sini, anonim trafikte ise IP’yi tamamlayıcı bir kimlik (örneğin API anahtarı) ile birlikte değerlendirin.

3. Hata: 429 Yanıtında Bilgilendirici Başlık Vermemek

İstemciye ne zaman tekrar deneyebileceğini söylemeden isteği reddetmek, istemcinin gereksiz yere tekrar tekrar denemesine (ve sunucu yükünün artmasına) yol açabilir. Çözüm: `Retry-After` ve `X-RateLimit-*` başlıklarını yanıtlara ekleyin.

4. Hata: Limitleri Hiç Gözden Geçirmemek

Başlangıçta belirlenen limitler, kullanıcı sayısı veya kullanım şekli değiştikçe artık uygun olmayabilir. Çözüm: Rate limiting metriklerini (kaç isteğin reddedildiği, hangi uç noktalarda) düzenli olarak izleyin ve limitleri veriye dayalı biçimde güncelleyin.

5. Hata: Rate Limiting’i Tek Güvenlik Katmanı Sanmak

Rate limiting, kötüye kullanımı yavaşlatır ama tek başına yeterli bir güvenlik stratejisi değildir. Çözüm: Rate limiting’i WAF, güçlü kimlik doğrulama ve düzenli güvenlik denetimleriyle birlikte katmanlı bir savunmanın parçası olarak kullanın.

Rate Limiting’i Test Etme ve İzleme

Bir rate limiting kuralını canlıya almadan önce test etmek, üretimde sürpriz yaşama riskini en aza indiren yaklaşım. Basit bir yük testi aracı (örneğin `ab`, `hey` veya `k6`) ile hedef uç noktanıza kısa süreli yoğun istek göndererek limitin beklendiği gibi devreye girip girmediğini, doğru durum kodunu ve başlıkları döndürüp döndürmediğini doğrulayabilirsiniz. Test sürecinde şu senaryoları kontrol etmek faydalı olur: limitin tam eşikte doğru tetiklenip tetiklenmediği, farklı kullanıcı/IP kombinasyonlarının birbirini etkileyip etkilemediği ve limit sıfırlandıktan sonra isteklerin normale dönüp dönmediği.

Canlıya aldıktan sonra ise izleme kritik önem taşır. Sunucu veya uygulama loglarınızda 429 yanıtlarının oranını, hangi uç noktalarda yoğunlaştığını ve hangi IP/kullanıcı gruplarından geldiğini düzenli olarak takip etmek, hem kötüye kullanım girişimlerini erken tespit etmenizi hem de limitlerin çok sıkı olup olmadığını anlamanızı sağlar. Birçok ekip bu veriyi Grafana, Datadog gibi izleme panolarına aktararak zaman içindeki eğilimleri görselleştiriyor; ani bir 429 artışı, ya yeni bir saldırı dalgasının ya da meşru trafikte beklenmedik bir büyümenin işareti olabilir.

Rate Limiting Kimin İçin, Hangi Durumda Uygun?

Herkese açık bir API sunan, kullanıcı girişi barındıran veya üçüncü taraf entegrasyonlarla çalışan hemen hemen her proje için rate limiting artık isteğe bağlı bir özellik değil, temel bir gereksinim olarak değerlendiriliyor. Küçük, düşük trafikli kişisel bloglar için basit bir sabit pencere yaklaşımı genellikle yeterliyken; yüksek trafikli SaaS ürünleri ve ödeme işlemi içeren sistemlerde token bucket veya leaky bucket gibi daha esnek ve öngörülebilir algoritmalar tercih edilmeli. Kod tabanınıza doğrudan müdahale etmek istemiyorsanız, Nginx veya Cloudflare gibi sunucu/ağ seviyesi çözümler hızlı bir başlangıç noktası sunabilir.

Özetle, projenizin büyüklüğüne göre şu genel yol haritasını izleyebilirsiniz: tek geliştiricili küçük projelerde önce sunucu/CDN seviyesinde hazır bir çözümle başlayın; ekibiniz ve trafiğiniz büyüdükçe uygulama seviyesinde daha ayrıntılı, kullanıcı bazlı kurallara geçin; kurumsal ölçekte ise birden fazla katmanı (CDN, uygulama, veritabanı sorgu limiti) bir arada kullanan katmanlı bir savunma mimarisini hedefleyin.

Sıkça Sorulan Sorular

Rate limiting ile DDoS koruması aynı şey midir?

Hayır; rate limiting, tek bir istemcinin veya IP’nin aşırı istek göndermesini sınırlayan bir tekniktir, DDoS koruması ise genellikle çok sayıda kaynaktan gelen dağıtık saldırıları tespit edip engelleyen daha geniş kapsamlı bir savunma katmanıdır. Rate limiting, DDoS savunmasının bir bileşeni olabilir ama tek başına yeterli değildir.

Rate limiting hangi HTTP durum kodunu döndürür?

API istemcileri için 429 uygun yanıttır; ancak kullanılan sunucu veya WAF varsayılanı farklı olabilir. Örneğin Nginx limit_req varsayılanı 503 olduğundan 429 ayrıca yapılandırılır. Retry-After başlığının mevcut olduğunu ve doğru hesaplandığını test edin.

WordPress’te rate limiting için eklenti kullanmalı mıyım?

Basit senaryolarda kod tabanlı bir çözüm yeterli olabilir, ancak güvenlik eklentileri veya WAF çözümleri genellikle daha kapsamlı, test edilmiş ve düzenli güncellenen bir sınırlandırma mekanizması sunar; üretim siteleri için bu tür hazır çözümler önerilir.

Token bucket algoritmasını ne zaman tercih etmeliyim?

Kullanıcıların kısa süreli ani istek yoğunluklarına (burst) ihtiyaç duyduğu ama uzun vadeli ortalama hızın sınırlı kalması gereken API’lerde token bucket genellikle en dengeli seçenek olur.

Rate limiting kullanıcı deneyimini olumsuz etkiler mi?

Limitler çok sıkı belirlenirse meşru kullanıcılar da engellenebilir; bu nedenle limitleri gerçek kullanım verilerine dayanarak belirlemek ve düzenli olarak gözden geçirmek önemlidir.

Rate limiting ve throttling aynı şey mi?

Pratikte iki terim genellikle birbirinin yerine kullanılır; ancak bazı kaynaklarda “throttling” isteği tamamen reddetmek yerine yavaşlatmayı, “rate limiting” ise belirli bir eşiği aştığında isteği doğrudan reddetmeyi ifade eder. Günlük kullanımda ikisi de aynı temel amaca, aşırı isteği kontrol altına almaya hizmet eder.