Technical Tutorials

Modern uygulama güvenliği manzarasında, Erişilebilirlik, Gizlilik ve Bütünlük kadar kritik öneme sahiptir. Geliştiriciler genellikle kimlik doğrulama ve yetkilendirmeye yoğunlaşırken, altyapılarının fiziksel kapasitesini sıkça göz ardı ederler. En etkili, ancak sıklıkla yeterince kullanılmayan savunma mekanizmalarından biri hız sınırlama (rate limiting) dir. Orta ve ileri düzey geliştiriciler için hız sınırlamayı nasıl uygulayacaklarını anlamak, yalnızca kötüye kullanımı önlemekle ilgili değildir; aynı zamanda hizmetinizin uzun ömürlülüğünü ve kararlılığını sağlamakla da ilgilidir.

Neden Hız Sınırlama Önemlidir?

Hız sınırlama, bir kullanıcı veya istemcinin belirli bir zaman dilimi içinde bir sunucuya yapabileceği istek sayısını kontrol etme sürecidir. Bu kontroller olmadan, uygulamanız çeşitli tehditlere karşı savunmasız hale gelir:

Kaba Kuvvet Saldırıları: Saldırganlar, saniyede binlerce giriş denemesi yaparak kimlik bilgilerini tahmin etmeye çalışır.
Hizmet Reddi (DoS): Kötü niyetli aktörler veya hatta iyi niyetli botlar, API'nize trafiği boğarak sunucu kaynaklarını tüketebilir ve meşru kullanıcılar için kesintilere neden olabilir.
Kaynak Tüketimi: Pahalı veritabanı sorguları veya yoğun hesaplamalar tekrar tekrar tetiklenebilir; bu da yüksek gecikmeye veya çökmelere yol açar.

Hız sınırlama uygulamak, arka uçunuzu korurken geçerli kullanıcılar için tutarlı bir deneyim sunarak "adil kullanım" politikaları tanımlamanıza olanak tanır.

Doğru Algoritmanın Seçimi

Hız sınırlama için her şeye uygun tek bir algoritma yoktur. Seçim, trafik desenlerinize ve patlamalara (burstiness) olan toleransınıza bağlıdır. En yaygın üç algoritma şunlardır:

Sabit Pencere Sayacı: Uygulanması en basit olanıdır. Sabit bir zaman aralığındaki (örneğin, dakika başına 100 istek) istekleri sayar. Ancak, "sınır problemi"nden muzdariptir; bu, bir kullanıcının bir pencerenin sonunda ve bir sonraki pencerenin başında istekleri zamanlayarak limiti iki katına çıkarmasına neden olabilir.
Kayan Pencere Günlüğü: Daha doğrudur, çünkü her istekin zaman damgasını takip eder. Hızı kayan bir pencere üzerinden hesaplar. Daha hassas olsa da, her bireysel istek zaman damgasını depoladığı için önemli miktarda bellek tüketir.
Jeton Havuzu: Bu, API ağ geçitleri için endüstri standardı olarak sıklıkla kabul edilir. Maksimum kapasiteye kadar kısa süreli trafik patlamalarına izin verirken ortalama bir aktarım hızı sınırını korur. Son derece verimlidir ve patlamaları zarifçe yönetir.

Uygulama Örneği: Node.js'de Kayan Pencere

Birçok uygulama için, Redis'te depolanan kayan pencere günlüğünü kullanan hibrit bir yaklaşım, doğruluk ve performans arasında iyi bir denge sunar. Aşağıda, Node.js'de bir hız sınırlayıcı middleware'in kavramsal bir uygulaması yer almaktadır.

const redis = require('redis');
const client = redis.createClient();

async function rateLimiter(req, res, next) {
  const userId = req.headers['x-user-id'] || 'anonymous';
  const windowMs = 60 * 1000; // 1 dakika
  const maxRequests = 100;
  
  const key = `rate_limit:${userId}:${Math.floor(Date.now() / windowMs)}`;
  
  // Bu pencere için sayacı artır
  const requests = await client.incr(key);
  
  // Penceredeki ilk istekte yalnızca süresi dolma süresini ayarla
  if (requests === 1) {
    await client.expire(key, Math.ceil(windowMs / 1000));
  }
  
  if (requests > maxRequests) {
    return res.status(429).json({
      error: 'Çok Fazla İstek',
      retryAfter: Math.ceil(windowMs / 1000)
    });
  }
  
  // Şeffaflık için mevcut sayıyı istemciye başlıklar üzerinden ilet
  res.setHeader('X-RateLimit-Limit', maxRequests);
  res.setHeader('X-RateLimit-Remaining', maxRequests - requests);
  
  next();
}

module.exports = rateLimiter;

Üretim İçin En İyi Uygulamalar

Kodu uygulamak savaşın sadece yarısıdır. Hız sınırlamanızın üretim ortamında etkili olmasını sağlamak için şu en iyi uygulamaları göz önünde bulundurun:

Doğru HTTP Durum Kodlarını Döndürün: Her zaman 429 Çok Fazla İstek durum kodunu döndürün. Hız sınırlama için 403 (Yasak) veya 503 (Hizmet Kullanılamıyor) kullanmayın; bu, istemcileri ve izleme araçlarını kafa karıştırır.
Retry-After Başlıklarını Dahil Edin: Kod örneğinde gösterildiği gibi, istemciye yeniden denemeden önce ne kadar beklemesi gerektiğini bildirin. Bu, API tüketicileri için geliştirici deneyimini iyileştirir.
İzleyin ve Ayarlayın: Hız sınırlamalar statik değildir. Meşru kullanıcıların hızlarının kısıtlanıp kısıtlanmadığını görmek için loglarınızı analiz edin ve buna göre sınırları ayarlayın. Tersine, sofistike dağıtık saldırıları işaret eden desenleri izleyin.
Dağıtık Mimariyi Düşünün: Birden fazla sunucu örneği çalıştırıyorsanız, hız sınırlama mantığının yerel bellekte depolanmak yerine (örneğin Redis veya Kong/Envoy gibi özel bir ağ geçidi aracılığıyla) merkezi olduğundan emin olun. Yerel bellek hız sınırlayıcıları, küme ortamında etkisizdir.

Sonuç

Hız sınırlama, sağlam bir uygulama güvenlik stratejisinin temel bir bileşenidir. Kötüye kullanıma karşı savunmanın ilk hattı olarak hareket eder ve yük altında hizmet kararlılığını korumaya yardımcı olur. Kullanım durumunuz için doğru algoritmayı seçerek ve Redis gibi dağıtık sistemler kullanarak onu verimli bir şekilde uygulayarak, kullanıcı deneyiminden ödün vermeden altyapınızı koruyabilirsiniz. Unutmayın, güvenlik tek seferlik bir yapılandırma değildir; savunmalarınızı izleme, ayarlama ve iyileştirme sürecidir.