API güvenliği neden web güvenliğinden farklı? OWASP API Security Top 10 (2023)

Bir web uygulamasını korumak ile bir API'yi korumak aynı iş değildir. Klasik web güvenliği araçları çoğunlukla XSS ve SQL enjeksiyonu gibi imza tabanlı saldırıları arar; oysa API'lerdeki asıl zayıflık yetkilendirme mantığında saklıdır ve hiçbir imza bunu yakalamaz. API'ler bugün çoğu uygulamanın ana giriş kapısı, ama saldırganların da ilk uzandığı hedef. Bir sektör araştırmasına göre 2024'te kuruluşların %37'si en az bir API ihlali bildirdi; bir yıl önce bu oran %17'ydi. İşte bu fark yüzünden OWASP, web için hazırladığı listeden ayrı olarak bir de API Security Top 10 yayımlıyor. En güncel sürüm 2023'te güncellendi ve API'lere özgü on riski sıralıyor.

API neden ayrı bir saldırı yüzeyi

Klasik bir web sayfasında sunucu HTML'i üretir ve tarayıcıya hazır ekranı gönderir; kullanıcının görmemesi gereken veri çoğu zaman sayfaya hiç girmez. API ise tersini yapar: ham veriyi ve nesne kimliklerini doğrudan istemciye teslim eder. /api/faturalar/1043 gibi bir uç noktada 1043 sayısını 1044 yapmak bir saniyelik iştir. Sunucu her istekte "bu kullanıcı bu kaydı görebilir mi?" sorusunu sormazsa, başka birinin faturası ekrana düşer. Kötüsü, saldırgan bunu elle değil; makine hızıyla, saniyede binlerce kayıt için otomatik yapar.

Bir numaralı risk: BOLA

Listenin başındaki ve tartışmasız en yaygın açık, Broken Object Level Authorization (BOLA), yani nesne düzeyinde bozuk yetkilendirmedir. Bir API bir nesneyi kimliğiyle açığa çıkarıp o nesnenin gerçekten talep edene ait olup olmadığını kontrol etmediğinde ortaya çıkar. Sektör verileri BOLA'nın tüm API saldırılarının yaklaşık %40'ını oluşturduğunu gösteriyor. Çözüm kulağa basit gelir ama sürekli atlanır: yetki kontrolü istemcide, yani "butonu gizledim" mantığıyla değil, her istekte sunucu tarafında yapılmalıdır. Ön yüzde bir düğmeyi saklamak güvenlik değildir, çünkü API doğrudan çağrılabilir.

37 milyon hesap: T-Mobile örneği

Teori bir yana, sonuçlar somut. Ocak 2023'te T-Mobile, tek bir API üzerinden yaklaşık 37 milyon müşteri hesabının verisinin çalındığını açıkladı. Saldırgan bu API'yi 25 Kasım 2022 civarında kullanmaya başlamış, şirket ise durumu ancak 5 Ocak 2023'te fark edip erişimi bir gün sonra kesmişti. Yani açık, yaklaşık altı hafta boyunca fark edilmeden veri sızdırdı. İfşa olan bilgiler arasında isim, adres, e-posta, telefon, doğum tarihi ve hesap numarası vardı.

49 milyon kayıt: Dell örneği

Mayıs 2024'te Dell, bir iş ortağı portalının API'si kötüye kullanılarak yaklaşık 49 milyon müşteri kaydının kazındığını doğruladı. Saldırgan önce sahte şirket adlarıyla hesap açtı ve portala doğrulama olmadan iki gün içinde girdi (bozuk kimlik doğrulama). Ardından 7 haneli servis etiketleri üreten bir program yazdı ve hız sınırı olmadığı için üç hafta boyunca dakikada 5.000 istek göndererek kayıtları tek tek topladı. Burada iki açık üst üste bindi: zayıf kimlik doğrulama ve hız sınırının hiç olmaması.

Kimlik doğrulama, yetkilendirme ve fazla veri

BOLA'dan sonra listenin ikinci sırasında bozuk kimlik doğrulama (Broken Authentication) yer alır: token'ların yanlış üretilmesi, süresiz oturumlar, tahmin edilebilir kimlik akışları. Üçüncü sırada ise nesne özelliği düzeyinde bozuk yetkilendirme (BOPLA) vardır. Bu, iki eski sorunu birleştirir: gereğinden fazla veri döndürmek ve toplu atama (mass assignment). Diyelim ki API bir kullanıcı nesnesini olduğu gibi gönderiyor ve içinde isAdmin alanı da var; ön yüz onu göstermese bile ham JSON yanıtta durur. Ya da API gelen tüm alanları körlemesine kaydeder ve saldırgan isteğe "role":"admin" ekleyerek yetki yükseltir. Doğru yaklaşım, hangi alanların okunup yazılabileceğini açıkça beyaz listeye almaktır.

OWASP API Security Top 10 (2023)

Liste, API'lere özgü on riski kapsar:

1. API1 Broken Object Level Authorization (BOLA): nesne sahipliğinin doğrulanmaması.
2. API2 Broken Authentication: kimlik doğrulama mekanizmasının hatalı kurulması.
3. API3 Broken Object Property Level Authorization: fazla veri ifşası ve toplu atama.
4. API4 Unrestricted Resource Consumption: hız sınırı ve kota eksikliği (DoS ve maliyet).
5. API5 Broken Function Level Authorization: rol ve fonksiyon düzeyinde yetki hataları.
6. API6 Unrestricted Access to Sensitive Business Flows: kritik iş akışlarının otomasyonla kötüye kullanımı.
7. API7 Server Side Request Forgery (SSRF): doğrulanmayan URI ile sunucuyu kullanma.
8. API8 Security Misconfiguration: hatalı ve eksik yapılandırma.
9. API9 Improper Inventory Management: unutulmuş ve belgelenmemiş uç noktalar.
10. API10 Unsafe Consumption of APIs: üçüncü taraf API'lere körü körüne güven.

Hız sınırı ve iş akışı istismarı

Dördüncü risk (Unrestricted Resource Consumption) tam da Dell'de görülen şeydir: hız sınırı ve kota koymazsanız, tek bir uç nokta hem hizmet dışı bırakma (DoS) hem de fatura şişirme aracına dönüşür. Altıncı risk daha sinsidir: uç nokta teknik olarak "doğru" çalışır, ama bir bot onu kötüye kullanır. Bilet alma, kupon uygulama, toplu hesap açma gibi meşru akışların otomasyonla sömürülmesi buna örnektir. Eylül 2022'de Optus'ta kimlik doğrulaması olmayan, internete açık bir API yaklaşık 9,8 milyon müşterinin verisini ifşa etti; şirket olayın maliyeti için 140 milyon Avustralya doları ayırdı.

Görünmeyen API'ler: envanter sorunu

En sık göz ardı edilen risklerden biri dokuzuncu sıradaki envanter yönetimidir. Çoğu kurum kaç API'si olduğunu tam bilmez. Eski bir v1 sürümü hâlâ açıktır, bir test ortamı internete bakar, bir departmanın aceleyle yayına aldığı uç nokta hiçbir yerde belgeli değildir. Bilmediğiniz bir API'yi koruyamazsınız; saldırganlar ise onu sizden önce bulur. Bu yüzden ilk adım çoğu zaman teknik bile değildir: envanter çıkarmak, yani tüm uç noktaları, sürümleri ve ortamları listelemektir.

Ne yapmalı

API güvenliğinin özü birkaç ilkeye iner. Her istekte, her nesne için yetkiyi sunucu tarafında doğrulayın; istemcinin gönderdiği kimliğe değil, oturumun sahibine güvenin. Kimlik doğrulamayı standart bir protokolle kurun (OAuth 2.0, kısa ömürlü token'lar). Hangi alanların okunup yazılacağını şema ile açıkça sınırlayın. Her uç noktaya hız sınırı ve kota koyun. Tüm API'lerinizin güncel bir envanterini tutun ve onları bir API ağ geçidi arkasına alın. Son olarak API'leri ayrıca test edin: web taramaları BOLA gibi mantık açıklarını göremez, bu yüzden API'ye özgü sızma testi gerekir. Bir WAF ya da API ağ geçidi yardımcı olur ama mantıktaki hatayı düzeltmez.

Kısacası API güvenliği, web güvenliğinin bir alt kümesi değil, kendi başına bir disiplindir ve çoğu ihlal karmaşık bir sıfır gün değil, atlanmış bir yetki kontrolüdür. Wedevit olarak API'lerinizi OWASP API Security Top 10'a göre gözden geçiriyor, yetkilendirme ve hız sınırı katmanını kuruyor ve bunu API-first entegrasyon tasarımınızla birlikte ele alıyoruz.