<

API Güvenliği: JWT, Rate Limiting ve Sahada Gördüğümüz Hatalar

Mobil uygulamalar, admin paneller, üçüncü parti entegrasyonlar... Hepsi API'lerin üzerinde duruyor ve saldırganlar da bunu biliyor. Web arayüzünüz sağlam olabilir ama API'niz açıksa kapıyı camdan yapmışsınız demektir. Devraldığımız projelerde yaptığımız güvenlik incelemelerinden süzülen en kritik başlıkları derledik: token mimarisinden yetkilendirmeye, rate limiting'den webhook güvenliğine kadar, her biri sahada karşılığı olan somut önlemler.

JWT: doğru araç, yanlış kullanım

JWT kendisi güvenli bir standart; sorun uygulama detaylarında. Sahada en sık gördüklerimiz:

  • Süresiz veya aylarca geçerli access token'lar. Doğrusu: kısa ömürlü access token (15-60 dakika) + yenileme için refresh token, refresh token rotasyonuyla birlikte.
  • Token'ın içine hassas veri gömmek. JWT şifreli değil, sadece imzalıdır; payload'ı herkes okuyabilir. İçine telefon, adres, yetki detayı yazmayın.
  • İmza algoritmasını istemciden kabul etmek. "alg: none" saldırısı hâlâ gerçek; sunucu tarafında algoritmayı sabitleyin.
  • Çıkış yapınca token'ın geçerli kalması. Kritik sistemlerde kısa ömür + sunucu tarafı iptal listesi şart.

Yetkilendirme: kimlik doğrulamanın öteki yarısı

OWASP'ın API güvenliği listesinin tepesindeki madde yıllardır değişmiyor: nesne seviyesinde yetki kontrolü kırıklığı (BOLA). Kullanıcı giriş yapmış olabilir; ama /api/orders/8412 çağrısında o siparişin gerçekten o kullanıcıya ait olup olmadığını her seferinde kontrol ediyor musunuz? Bizim kod incelemelerinde ilk baktığımız yer burasıdır ve ne yazık ki çoğu projede ilk bulguyu burada veririz. Kural basit: her endpoint'te, her kayıt için sahiplik kontrolü; "frontend zaten göstermiyor" bir güvenlik önlemi değildir.

Rate limiting: unutulan sigorta

Limitsiz bir login endpoint'i, brute force için açık davettir. Limitsiz bir SMS gönderim endpoint'i, bir gecede binlerce liralık fatura demektir; bunu yaşayan müşteriden devraldık, biliyoruz. Önerimiz katmanlı limit: IP bazlı genel limit, kullanıcı bazlı endpoint limiti ve maliyetli işlemler (SMS, e-posta, rapor üretimi) için ayrı sıkı kotalar. Laravel tarafında throttle middleware'i, önünde de Cloudflare veya nginx limitleri ile katmanlı bir yapı kurmak yarım günlük iştir; getirisi paha biçilmezdir.

Makineler arası iletişim: webhook'lar ve servis hesapları

API güvenliği sadece mobil uygulamayla sunucu arasında değil; ödeme sağlayıcısından gelen webhook'lar, kargo entegrasyonları, üçüncü parti servis hesapları da aynı disiplini ister. Webhook endpoint'lerinde imza doğrulaması (sağlayıcının verdiği secret ile HMAC kontrolü) atlanırsa, sahte "ödeme alındı" bildirimiyle sipariş onaylatmak mümkün hale gelir; bu senaryo teorik değil, sektörde defalarca yaşandı. Servis hesaplarında ise en az yetki prensibi geçerli: rapor çeken bir entegrasyonun silme yetkisi olmamalı, her entegrasyonun kendi anahtarı bulunmalı ki bir sızıntıda sadece o anahtar iptal edilsin. Anahtarların koda değil ortam değişkenlerine konması, belirli aralıklarla döndürülmesi ve kullanılmayanların kapatılması da bu hijyenin parçası.

Küçük ama etkili diğer önlemler

  • Hata mesajlarını sadeleştirin: "kullanıcı bulunamadı" ile "şifre yanlış" ayrımı bile saldırgana bilgi verir.
  • API sürümleyin ve eski sürümleri gerçekten kapatın; unutulan v1, en zayıf halkanız olur.
  • Tüm istek/yanıt trafiğini merkezi loglayın; saldırıyı tespit edemediğiniz sürece savunamazsınız.

Rich Design olarak 2010'dan beri backend ve API geliştiriyoruz; mevcut API'leriniz için güvenlik denetimi, JWT mimarisi kurulumu ve rate limiting tasarımını uçtan uca üstleniyoruz. API'nizin röntgenini çekmek için iletişime geçin.

📅 Yayınlanma:  ·  Yakup Zengin