API Güvenliği Rehberi: Kimlik Doğrulama, Yetkilendirme ve Rate Limiting

Anasayfa - Blog

API Güvenliği Rehberi: Kimlik Doğrulama, Yetkilendirme ve Rate Limiting

API'ler mobil uygulamaları, web arayüzlerini, ödeme servislerini ve kurum içi sistemleri birbirine bağlar. Bu nedenle bir API açığı yalnızca teknik bir hata olarak kalmaz; müşteri verisine izinsiz erişim, işlem manipülasyonu, hizmet kesintisi ve doğrudan maliyet üretebilir. Sağlam bir API güvenliği yaklaşımı “giriş yapan kullanıcıya token ver” seviyesinin ötesine geçer. Her istekte kimlik, yetki, hedef nesne, iş kuralı, kaynak tüketimi ve güven sınırı ayrı ayrı değerlendirilmelidir.

OWASP API Security Top 10 çalışması, modern API'lerde yetkilendirmenin hâlâ en büyük zorluklardan biri olduğunu vurgular. Özellikle nesne düzeyinde yetki kontrolü, kimlik doğrulama akışları, sınırsız kaynak tüketimi ve üçüncü taraf API'lere gereğinden fazla güvenme sık görülen risklerdir. Bu rehber, güvenliği geliştirme sürecinin sonundaki bir kontrol listesi değil, mimarinin doğal parçası hâline getirmek için uygulanabilir bir yol haritası sunar.

1. Önce API envanterini ve güven sınırlarını çıkarın

Koruyamadığınız bir API'nin çoğu zaman önce varlığından haberdar değilsinizdir. Üretimde çalışan sürümler, mobil uygulamanın kullandığı eski uç noktalar, yönetim servisleri, webhook alıcıları ve yalnızca kurum içinde kullanıldığı varsayılan servisler tek envanterde toplanmalıdır. Her uç nokta için veri sahibi, kimlerin erişebileceği, hangi işlemleri yaptığı, kişisel veri içerip içermediği ve bağımlı olduğu dış servisler yazılmalıdır.

  • Üretim, test ve eski sürüm uç noktalarını ayrı etiketleyin.
  • Herkese açık, kullanıcıya özel, yönetici ve servisler arası erişimleri ayırın.
  • Her isteğin geçtiği CDN, yük dengeleyici, API gateway ve uygulama katmanını belgeleyin.
  • Kullanılmayan uç noktaları kapatın; yalnızca dokümantasyondan silmek yeterli değildir.
  • Şema değişiklikleri ve sürüm sonlandırma tarihleri için sahip belirleyin.

Bu çalışma tehdit modelini somutlaştırır. “API saldırıya uğrar mı?” gibi geniş bir soru yerine “bir müşteri başka müşterinin sipariş kimliğini değiştirerek veriye ulaşabilir mi?” veya “parola sıfırlama isteği sınırsız çağrıldığında SMS maliyeti doğar mı?” gibi test edilebilir senaryolar elde edilir.

2. Kimlik doğrulama ile yetkilendirmeyi karıştırmayın

Kimlik doğrulama, isteği yapanın kim olduğunu belirler. Yetkilendirme ise bu kimliğin talep ettiği işlemi belirli kaynak üzerinde yapıp yapamayacağını kontrol eder. Geçerli bir erişim token'ı, kullanıcının sistemdeki her kaynağa erişebileceği anlamına gelmez. En kritik API hatalarının önemli bölümü bu iki kontrolün aynı şey sanılmasından doğar.

Kimlik doğrulama akışında standart protokoller ve güvenilir kütüphaneler kullanılmalıdır. Parola sıfırlama, e-posta değiştirme ve çok faktörlü doğrulama kapatma gibi hassas işlemler yeniden kimlik doğrulama isteyebilir. Erişim token'ları kısa ömürlü olmalı; imza, issuer, audience ve süre alanları sunucuda doğrulanmalıdır. Token veya parola URL içinde taşınmamalıdır; çünkü URL'ler tarayıcı geçmişine, ara sunucu loglarına ve analiz sistemlerine sızabilir.

API anahtarları çoğunlukla uygulama ya da servis istemcisini tanımlar; kullanıcı kimlik doğrulaması yerine kullanılmamalıdır. Servisler arası iletişimde de “iç ağ güvenlidir” varsayımı yerine karşılıklı kimlik doğrulama, kısa ömürlü kimlik bilgileri ve en az yetki ilkesi uygulanmalıdır.

3. Nesne ve işlev düzeyinde yetki kontrolü kurun

Bir istek /siparisler/8421 kaynağını çağırdığında yalnızca kullanıcının giriş yapmış olması kontrol edilirse, başka bir sipariş numarası denenerek yetkisiz veriye erişilebilir. Nesne düzeyinde yetkilendirme her istekte, sunucu tarafında ve sorguya en yakın noktada yapılmalıdır. “Bu kayıt var mı?” sorusundan önce “bu kullanıcı bu kaydın sahibi mi veya gerekli role sahip mi?” sorusu yanıtlanmalıdır.

// Zayıf yaklaşım
SELECT * FROM orders WHERE id = :id;

// Daha güvenli yaklaşım
SELECT * FROM orders
WHERE id = :id AND customer_id = :authenticated_customer_id;

Bu örnek tek başına tüm yetki modelini çözmez; ancak erişim kapsamını veri sorgusuna kadar taşır. Yönetici işlemleri için yalnızca arayüzde düğmeyi gizlemek yeterli değildir. İşlev düzeyinde yetki kontrolü API katmanında zorunlu olmalı, roller ve izinler merkezi bir politika üzerinden yönetilmelidir. Çok kiracılı sistemlerde tenant kimliği istemciden gelen değere körü körüne güvenilerek değil, doğrulanmış oturum bağlamından üretilmelidir.

4. Fazla veri döndürmeyin ve alan bazlı yetki uygulayın

API'nin veritabanı modelini olduğu gibi JSON'a çevirmesi, istemcinin kullanmadığı hassas alanların da dışarı çıkmasına yol açabilir. Yanıt şemaları açık biçimde tanımlanmalı ve izin verilen alanlar beyaz listeyle seçilmelidir. Kullanıcı profilini güncelleyen bir uç nokta, istemciden gelen tüm alanları modele doğrudan bağlamamalıdır. Aksi hâlde rol, bakiye, doğrulama durumu veya kurum kimliği gibi alanlar istenmeden değiştirilebilir.

İstek ve yanıt DTO'ları kullanmak, şema doğrulaması yapmak ve alan bazlı yetkilendirme uygulamak bu riski azaltır. Hata yanıtları da iç tablo adlarını, dosya yollarını, SQL mesajlarını veya token ayrıntılarını göstermemelidir. İstemciye yeterli fakat sınırlı bilgi verilirken ayrıntılı hata bağlamı güvenli sunucu loglarında tutulmalıdır.

5. Rate limiting yalnızca istek sayacı değildir

Rate limiting, bir istemcinin belirli sürede kaç istek yapabileceğini sınırlar; fakat güvenli tasarım bununla bitmez. Kimlik doğrulama, tek kullanımlık kod gönderimi, parola sıfırlama, rapor üretme, dosya işleme ve dış API çağırma gibi maliyetli operasyonların her biri farklı sınırlara ihtiyaç duyar. IP bazlı tek limit, NAT arkasındaki gerçek kullanıcıları etkileyebilir ve dağıtık saldırıları durdurmayabilir. Bu nedenle kullanıcı, API anahtarı, cihaz, tenant ve uç nokta gibi birden fazla anahtar birlikte değerlendirilebilir.

  • Genel trafik için sürdürülebilir bir temel kota belirleyin.
  • Giriş ve parola sıfırlama uç noktalarında daha sıkı deneme sınırı uygulayın.
  • Dosya boyutu, sayfalama limiti, sorgu karmaşıklığı ve eş zamanlı işlem sayısını sınırlayın.
  • Üçüncü taraf servislerde harcama limiti ve fatura alarmı kurun.
  • Limit aşıldığında tutarlı 429 yanıtı ve uygun yeniden deneme bilgisi sağlayın.

Limitler iş ihtiyacına göre ayarlanmalıdır. Çok düşük limit gerçek kullanıcıyı engeller; çok yüksek limit ise saldırıyı yalnızca biraz yavaşlatır. Üretim metrikleri izlenerek uç nokta bazında normal davranış dağılımı çıkarılmalı ve anomali eşikleri düzenli güncellenmelidir.

6. Girdi doğrulama, SSRF ve üçüncü taraf API güveni

Her parametre tür, uzunluk, biçim, aralık ve izin verilen değer bakımından sunucuda doğrulanmalıdır. İstemci tarafındaki kontrol kullanıcı deneyimi sağlar; güvenlik kontrolü değildir. URL alan servislerde yalnızca şema kontrolü yapmak SSRF riskini çözmez. Hedef alan adı, IP aralığı, yönlendirmeler ve DNS çözümleme davranışı sınırlandırılmalıdır. Özel ağlara, bulut metadata adreslerine ve yönetim uç noktalarına erişim engellenmelidir.

Dış API'den gelen veri de kullanıcı girdisi gibi doğrulanmalıdır. Tanınmış bir sağlayıcıdan geliyor olması yanıtın güvenli olduğunu garanti etmez. TLS doğrulaması kapatılmamalı, zaman aşımı konulmalı, yönlendirmeler sınırlanmalı, yanıt boyutu kontrol edilmeli ve beklenmeyen şema değişiklikleri güvenli şekilde reddedilmelidir. Webhook imzaları ham istek gövdesi üzerinden doğrulanmalı ve tekrar oynatma saldırılarına karşı zaman damgası ya da tekil olay kimliği kullanılmalıdır.

7. Loglama ve izleme: olayı görebilmek güvenliğin parçasıdır

Güvenli log, her şeyi kaydetmek demek değildir. Parola, tam token, kart verisi ve gereksiz kişisel bilgi loglara yazılmamalıdır. Buna karşılık kimlik doğrulama başarısızlıkları, yetki reddi, yönetici işlemleri, limit aşımı, şema doğrulama hataları ve kritik veri değişiklikleri ilişkilendirilebilir bir istek kimliğiyle kaydedilmelidir.

İzleme sistemi yalnızca sunucunun çalışıp çalışmadığını değil, güvenlik davranışını da ölçmelidir. Aynı kullanıcının kısa sürede çok sayıda nesne kimliği denemesi, olağan dışı veri indirme hacmi, başarısız webhook doğrulamaları veya yeni bir ülkeden yönetici işlemi alarm üretebilir. Alarmın sahibi ve müdahale adımı önceden tanımlı değilse gürültü oluşur. Her kritik alarm için “kim bakacak, hangi veriyi kontrol edecek, hangi erişimi geçici durdurabilir?” soruları cevaplanmalıdır.

8. Güvenlik testlerini teslimat sürecine yerleştirin

API güvenliği yılda bir yapılan penetrasyon testine bırakılamaz. Birim testlerinde yetki politikaları, entegrasyon testlerinde kimlik ve tenant sınırları, sözleşme testlerinde istek-yanıt şemaları kontrol edilmelidir. Negatif testler özellikle önemlidir: kullanıcı kendi kaynağına erişebiliyor mu sorusunun yanında, başka kullanıcı kaynağına erişemiyor mu sorusu da otomatik doğrulanmalıdır.

  • Her nesne uç noktası için yatay ve dikey yetki negatif testleri yazın.
  • Token süresi, imzası, audience ve issuer hatalarını test edin.
  • Beklenmeyen alan, aşırı büyük gövde ve sınır dışı sayfalama değerlerini deneyin.
  • Rate limit'in toplu istek, paralel istek ve farklı kimlik senaryolarında çalıştığını doğrulayın.
  • Bağımlılık ve gizli bilgi taramasını CI/CD sürecine ekleyin.

9. Uygulanabilir API güvenliği kontrol listesi

  1. Güncel API ve veri envanteri var mı?
  2. Her uç noktada kimlik doğrulama gereksinimi açık mı?
  3. Nesne, işlev ve alan düzeyinde yetki sunucuda uygulanıyor mu?
  4. Token'ların tüm güvenlik alanları doğrulanıyor ve süreleri sınırlı mı?
  5. İstek gövdesi, sorgu parametreleri ve dosyalar şemaya göre doğrulanıyor mu?
  6. Uç nokta ve iş akışı bazlı kaynak limitleri mevcut mu?
  7. Dış API yanıtları, webhook'lar ve yönlendirmeler güvenilmeyen girdi sayılıyor mu?
  8. Hassas veri loglardan çıkarılmış, kritik olaylar izlenebilir mi?
  9. Negatif yetki testleri teslimat hattında otomatik çalışıyor mu?
  10. Eski sürümler ve kullanılmayan uç noktalar kapatılıyor mu?

API gateway güvenlik için yeterli midir?

API gateway; merkezi kimlik kontrolü, kota, trafik kaydı ve temel tehdit filtreleme için güçlü bir katmandır. Buna rağmen iş bağlamını tek başına bilemez. Gateway geçerli token'ı doğrulayabilir; ancak kullanıcının belirli siparişi görmeye yetkili olup olmadığını, fiyat alanını değiştirip değiştiremeyeceğini veya işlemin iş kuralına uyup uymadığını uygulama katmanı kontrol etmelidir. Güvenliği yalnızca gateway'e bırakmak, içerideki yetki hatalarını görünmez kılar.

En sağlıklı model sorumlulukları katmanlara ayırır: kenar katmanı trafik ve genel politika uygular; uygulama kimlik bağlamı ile nesne ve işlev yetkisini denetler; veri katmanı erişim kapsamını sınırlar; izleme sistemi katmanlar arası olayları ortak istek kimliğiyle birleştirir. Böylece tek bir kontrolün atlanması tüm korumayı ortadan kaldırmaz.

Sonuç

API güvenliği tek bir ürün, gateway ayarı veya token formatıyla tamamlanmaz. Güçlü sonuç; envanter, standart kimlik doğrulama, her istekte bağlama duyarlı yetkilendirme, sınırlı veri yüzeyi, kaynak kontrolü, güvenli entegrasyon, izlenebilirlik ve sürekli testin birlikte çalışmasıyla elde edilir. Önceliği internete açık ve hassas veri işleyen uç noktalara verin; ardından aynı politikaları servisler arası trafiğe ve eski sürümlere genişletin.

Web yazılım projenizde API tasarımı, güvenlik denetimi veya performanslı bir entegrasyon mimarisi planlıyorsanız web yazılım hizmetimizi inceleyebilir, mevcut yapının risklerini birlikte değerlendirmek için iletişime geçebilirsiniz.

Kaynaklar

İçerik editörlüğü ve destek

Bu içerik İlter Web Tasarım editör ekibi tarafından bilgilendirme amacıyla hazırlanmıştır. Projenize özel değerlendirme için ekibimizle iletişime geçebilirsiniz.

Uzmanla Görüşün

İlgili İçerikler

Yorum Yapabilirsiniz.

E-posta mailiniz gizli kalacaktır.*

İyi görünüyor!
Lütfen isminizi giriniz.
İyi görünüyor!
Lütfen geçerli bir e-posta adresi girin.
İyi görünüyor!
Lütfen yorumunuzu giriniz.