API Güvenliği: Kimlik Doğrulama, Yetki ve Sınırlama
API'ler sisteminize açılan kapılardır. Kimlik doğrulama, yetkilendirme, sınırlama ve izleme ile bu kapıları nasıl güvenle açık tutacağınızı anlatıyorum.
İçindekiler
Bir mobil uygulamada sipariş numarasını bir artırarak başka bir müşterinin adresini görmek mümkünse, sorun uygulamada değil API’dedir. Web siteleri ve mobil uygulamalar artık verilerinin büyük kısmını API’ler üzerinden alıp gönderiyor; bu da API’leri saldırganlar için cazip bir hedef hâline getiriyor. API güvenliği, bu kapıların yalnızca doğru kişilere, doğru ölçüde ve kontrollü biçimde açılmasını sağlayan önlemlerin bütünüdür. Bu yazıda teknik olmayan bir okurun da takip edebileceği şekilde temel katmanları anlatacağım.
API güvenliği neden ayrı bir konu?
Klasik bir web sitesinde kullanıcı ekranda ne görüyorsa onunla sınırlıdır. API’lerde ise istekler doğrudan gönderilebilir; arayüzde gizlenmiş bir buton, API tarafında kontrol yoksa hiçbir koruma sağlamaz. Bu yüzden “uygulamada o ekran yok” demek güvenlik önlemi değildir. Her kural sunucu tarafında, API’nin kendisinde uygulanmalıdır.
OWASP gibi güvenlik toplulukları API’lere özgü riskleri ayrı bir liste hâlinde yayımlar. Bu listelerde öne çıkan risklerin çoğu karmaşık saldırılar değil, eksik yetki kontrolü, aşırı veri döndürme ve sınırsız istek gibi temel tasarım hatalarıdır.
Katman 1: Kimlik doğrulama
İlk soru şudur: Bu isteği gönderen kim? Kimlik doğrulama (authentication) bu soruya cevap verir. Yaygın yöntemler:
- API anahtarı: Sunucudan sunucuya, basit entegrasyonlarda kullanılır. Anahtar bir şifre gibi saklanmalı, mobil uygulama veya tarayıcı koduna gömülmemelidir.
- Token tabanlı doğrulama: Kullanıcı giriş yaptıktan sonra kısa ömürlü bir token alır ve sonraki isteklerde bunu gönderir. En yaygın biçimlerinden biri JWT’dir; ayrıntısını JWT nedir, token tabanlı kimlik doğrulama yazısında anlattım.
- OAuth 2.0: Bir uygulamanın, kullanıcının şifresini öğrenmeden başka bir servisteki verisine sınırlı erişim almasını sağlar. “Google ile giriş” bu altyapıyı kullanır. Konuyu OAuth nedir yazısında açtım.
Hangi yöntem seçilirse seçilsin, tüm trafik HTTPS üzerinden gitmelidir. Şifreli olmayan bir bağlantıda en güçlü token bile yolda okunabilir.
Katman 2: Yetkilendirme
Kimliğin doğrulanması yetmez; ikinci soru “bu kişi bu işlemi yapabilir mi?” sorusudur. Yetkilendirme (authorization) hataları, API’lerde en sık karşılaşılan ve en tehlikeli açıklardır.
Nesne düzeyinde yetki
Yazının başındaki örnek tam olarak budur: Kullanıcı giriş yapmıştır ama /orders/1205 yerine /orders/1206 isteyerek başkasının siparişini görebilmektedir. Her istekte, istenen kaydın gerçekten o kullanıcıya ait olup olmadığı kontrol edilmelidir.
İşlev düzeyinde yetki
Sıradan bir kullanıcının yönetici uç noktalarını (ürün silme, fiyat değiştirme, kullanıcı listesi) çağıramaması gerekir. Rol tabanlı yetki modelini yazılımda kullanıcı yetkilendirme yazısında ayrıntılı ele aldım.
Alan düzeyinde kontrol
API, ekranda gösterilmeyen alanları da döndürüyorsa (şifre özeti, iç notlar, başka müşterilerin bilgileri) bu bir veri sızıntısıdır. Cevaplar yalnızca gerekli alanları içermelidir. Benzer şekilde, güncelleme isteklerinde kullanıcının “rol: yönetici” gibi bir alanı kendisi gönderip yetkisini yükseltmesi engellenmelidir.
Katman 3: Sınırlama ve kötüye kullanımı önleme
Doğru kimlikle gelen bir istemci bile sistemi kötüye kullanabilir: giriş ekranında şifre denemesi yapabilir, ürün listesini saniyede yüzlerce kez çekebilir ya da yanlış yazılmış bir döngüyle sunucuyu kilitleyebilir. Bunu önlemek için:
- Kullanıcı, anahtar veya IP başına istek sınırı konur.
- Giriş ve şifre sıfırlama gibi hassas uç noktalara daha sıkı sınırlar uygulanır.
- Liste uç noktalarında sayfa başına en fazla kayıt sayısı belirlenir.
- Yüklenebilecek dosya boyutu ve istek gövdesi büyüklüğü sınırlanır.
İstek sınırlamanın nasıl çalıştığını API rate limit nedir, neden gerekir yazısında anlattım.
Katman 4: Girdi doğrulama ve gizli bilgilerin korunması
API’ye gelen hiçbir veriye güvenilmemelidir. Her alanın tipi, uzunluğu ve biçimi kontrol edilmeli; veritabanı sorguları parametreli yazılarak SQL enjeksiyonu gibi saldırılar engellenmelidir. Hata mesajları kullanıcıya yol gösterecek kadar açık, ama sunucunun iç yapısını (dosya yolları, sorgu metinleri) ele vermeyecek kadar sade olmalıdır.
Veritabanı şifreleri, ödeme kuruluşu anahtarları ve token imzalama sırları kodun içine yazılmaz; ortam değişkenlerinde ya da bir gizli bilgi yöneticisinde tutulur ve Git deposuna asla gönderilmez.
Katman 5: Kayıt tutma ve izleme
Hiçbir sistem kusursuz değildir; önemli olan bir sorunu fark edebilmek. Başarısız giriş denemeleri, yetki hataları ve olağandışı trafik artışları kayıt altına alınmalı, belirli eşikler aşıldığında uyarı üretilmelidir. Kayıtlarda kart bilgisi, şifre veya token gibi hassas veriler tutulmamalıdır; kişisel veriler söz konusuysa KVKK açısından da saklama süreleri düşünülmelidir. Kesin hukuki değerlendirme için bir uzmana danışmanızı öneririm.
API güvenliği kontrol listesi
| Kontrol | Soru |
|---|---|
| Şifreli iletişim | Tüm istekler HTTPS üzerinden mi? |
| Kimlik doğrulama | Her uç nokta kimlik istiyor mu, token’lar kısa ömürlü mü? |
| Nesne yetkisi | Kullanıcı yalnızca kendi kayıtlarına erişebiliyor mu? |
| Rol yetkisi | Yönetici işlemleri sıradan kullanıcıya kapalı mı? |
| Veri minimizasyonu | Cevaplar yalnızca gerekli alanları mı içeriyor? |
| Sınırlama | İstek, sayfa ve dosya boyutu limitleri var mı? |
| Gizli bilgiler | Anahtarlar kodun ve deponun dışında mı? |
| İzleme | Şüpheli hareketler kaydediliyor ve uyarı üretiyor mu? |
Bu işi nasıl birlikte yaparız?
Yeni bir API’yi güvenli kurmak ya da mevcut API’nizi gözden geçirmek için şu adımları izliyorum:
- Riskleri konuşma: API’nin hangi verileri taşıdığını, kimlerin eriştiğini ve en hassas işlemleri birlikte belirleriz.
- İnceleme ve teklif: Mevcut bir API varsa uç noktaları yukarıdaki kontrol listesine göre inceler, bulguları ve önerilen düzeltmeleri teklifle birlikte paylaşırım.
- Düzeltme ve test: Yetki kontrollerini, sınırlamaları ve doğrulamaları uygular, başka bir kullanıcının verisine erişme gibi senaryoları bizzat denerim.
- Teslim ve izleme: Kayıt ve uyarı düzenini kurar, sonrasında düzenli güncelleme ve kontrol için destek veririm.
API’nizi birlikte değerlendirmek için iletişim sayfasından bana ulaşabilirsiniz.
Sık sorulan sorular
HTTPS kullanmak API güvenliği için yeterli mi?
Hayır. HTTPS verinin yolda okunmasını engeller ama kimin hangi veriye erişebileceğini kontrol etmez. Kimlik doğrulama, yetkilendirme ve sınırlama ayrıca gerekir.
API anahtarını mobil uygulamaya koymak güvenli mi?
Uygulama paketleri çözümlenebildiği için uygulamaya gömülen anahtarlar gizli kabul edilmemelidir. Kullanıcı bazlı token’lar ve sunucu tarafında yetki kontrolü tercih edilmelidir.
Kimlik doğrulama ile yetkilendirme arasındaki fark nedir?
Kimlik doğrulama “sen kimsin?”, yetkilendirme “bunu yapmaya iznin var mı?” sorusunu cevaplar. İkisi birlikte uygulanmalıdır.
Mevcut API’mde açık olup olmadığını nasıl anlarım?
Uç noktaların yetki, veri döndürme ve sınırlama açısından tek tek incelenmesi gerekir. Kapsamlı ihtiyaçlarda profesyonel bir sızma testi de değerlendirilebilir.
Sonuç
API güvenliği tek bir ayarla değil, kimlik doğrulama, yetkilendirme, sınırlama, girdi doğrulama ve izleme katmanlarının birlikte çalışmasıyla sağlanır. Bu katmanlar tasarım aşamasında düşünüldüğünde hem daha az maliyetli hem daha sağlam olur. API’nizin güvenliğini birlikte gözden geçirmek isterseniz bana yazabilirsiniz.