Hızlı cevap: OWASP API Security Top 10, API'lere özgü en kritik güvenlik risklerini önceliklendiren referans listesidir. Web uygulama listesinden ayrı bir liste vardır çünkü API'ler farklı bir saldırı yüzeyi taşır: kullanıcı arayüzü yerine doğrudan veri ve işlem uçlarını sunarlar. Listenin en tepesinde nesne ve fonksiyon düzeyinde bozuk yetkilendirme bulunur; yani bir kullanıcının başka kullanıcının verisine ya da yetkisiz bir işleme erişebilmesi. Diğer öne çıkan riskler kimlik doğrulama zayıflıkları, aşırı veri ifşası, kaynak tüketimi ve iş mantığı akışlarının kötüye kullanımıdır. Kök çözüm, yetkiyi her istekte nesne ve fonksiyon düzeyinde sunucuda zorlamak, kimlik doğrulamayı sağlamlaştırmak ve API'yi arayüz gibi değil, doğrudan erişilen bir veri katmanı gibi korumaktır.

Modern uygulamalar birbirine API'lerle konuşur. Mobil uygulamalar, tek sayfa web uygulamaları ve entegrasyonlar hep API çağırır. Bu, API'yi kurumun en açık ve en değerli saldırı yüzeyi yapar. OWASP API Security Top 10, bu yüzeyi korumak için ortak bir öncelik listesi sunar. Bu yazı, listenin mantığını ve öne çıkan riskleri anlatır.

API neden ayrı bir liste gerektirir

Klasik web uygulamasında saldırgan bir arayüzle etkileşir; API'de ise doğrudan veri ve işlem uçlarıyla konuşur. Arayüzün gizlediği detaylar API'de açıktadır. Ayrıca API'ler çoğu zaman çok sayıda uç nokta sunar ve her biri ayrı ayrı yetkilendirilmelidir. Bu yüzden web uygulama riskleri API'ye birebir taşınmaz; API'nin kendi öncelik listesi vardır.

Öne çıkan API riskleri

Risk Ne yapıyor Sonuç
Nesne düzeyi bozuk yetki Başka kullanıcının nesnesine erişim Veri ifşası, IDOR
Fonksiyon düzeyi bozuk yetki Yetkisiz işleve erişim Yetki yükseltme
Kimlik doğrulama zayıflığı Zayıf ya da atlatılabilir kimlik Hesap ele geçirme
Aşırı veri ifşası İhtiyaçtan fazla alan döndürme Hassas veri sızıntısı
Kaynak tüketimi Sınırsız istek ve sorgu Hizmet dışı bırakma

Nesne düzeyinde bozuk yetkilendirme, listenin en tepesindeki risktir ve pratikte en sık görülen API açığıdır. Bir kullanıcı, kendi verisi için tasarlanmış bir uca başka kimlik vererek onun verisine ulaşır.

Kimlik doğrulama ve token

API'lerde kimlik doğrulama çoğu zaman token ile yapılır. Token zayıf üretilir, doğrulanmadan kabul edilir ya da sızarsa, tüm yetki saldırgana geçer. Bu, JWT güvenliği ile doğrudan ilişkilidir: token imzası doğrulanmalı, süresi ve kapsamı denetlenmelidir. Sızan bir token, sızan API anahtarları kadar tehlikelidir.

Aşırı veri ifşası ve kaynak tüketimi

API'ler sık yapılan iki hatayla veri sızdırır ve tüketilir. Aşırı veri ifşası, uç noktanın ihtiyaçtan fazla alan döndürmesi ve arayüzün bunları göstermese bile verinin yanıtda bulunmasıdır. Kaynak tüketimi ise sınırsız istek, sayfalama ve sorgu ile API'yi yormaktır; bu, GraphQL güvenliğindeki DoS riskiyle aynı mantığa dayanır. İkisi de sunucu tarafında sınır ve alan denetimi ile çözülür.

Doğru savunma

1. Nesne ve fonksiyon düzeyinde yetki

Yetki, her istekte hem erişilen nesne hem çağrılan fonksiyon için sunucuda zorlanmalıdır. Kullanıcı yalnızca kendi verisine ve yetkili olduğu işleve ulaşabilmelidir.

2. Kimlik doğrulamayı sağlamlaştırma

Token güçlü üretilmeli, imzası ve kapsamı her istekte doğrulanmalı, süresi sınırlı olmalıdır. Zayıf kimlik doğrulama, tüm API'yi açar.

3. Alan ve veri sınırı

Uç noktalar yalnızca gereken alanları döndürmeli, hassas veri yanıttan çıkarılmalıdır. Arayüzün göstermemesi güvenlik sağlamaz.

4. Hız ve kaynak sınırı

İstek, sayfalama ve sorgu için sınır konmalı, sınırsız kaynak tüketimi engellenmelidir.

KAOS ile API güvenlik testi

DSET'in yerel yapay zekâ güvenlik motoru KAOS, API'lerinizi OWASP API Security Top 10 riskleri açısından kanıt temelli test eder. Nesne ve fonksiyon düzeyinde yetki boşluklarını dener, kimlik doğrulama zayıflıklarını ölçer ve bir yetki atlatmanın gerçekten başka kullanıcının verisini döndürüp döndürmediğini kontrollü biçimde doğrular. Yalnızca gerçekten istismar edilebilir bulguyu, yanlış pozitif gürültüsü olmadan raporlar. Böylece API güvenliğinizin gerçek durumunu, öncelik sırasıyla görürsünüz.

Sık sorulan sorular

API'ler için neden ayrı bir OWASP listesi var? Çünkü API'ler farklı bir saldırı yüzeyi taşır. Arayüz yerine doğrudan veri ve işlem uçlarını sunar ve her uç ayrı yetkilendirme gerektirir. Web uygulama riskleri API'ye birebir uymaz, bu yüzden API'nin kendi öncelik listesi vardır.

En sık görülen API açığı hangisidir? Nesne düzeyinde bozuk yetkilendirme, pratikte en sık görülen ve listenin en tepesindeki risktir. Bir kullanıcı, kendi verisi için tasarlanmış bir uca başka bir kimlik vererek başka kullanıcının verisine ulaşır.

Arayüzde göstermediğim veri yanıtda dönerse sorun mu? Evet. Aşırı veri ifşası, arayüz göstermese bile verinin yanıtda bulunmasıdır. Saldırgan API yanıtını doğrudan okuduğu için, hassas veri arayüzde gizli olsa da sızabilir. Çözüm, veriyi sunucu tarafında yanıttan çıkarmaktır.

Kaynaklar

API'lerinizi OWASP API Security Top 10 riskleri açısından çalışan bir kanıtla test ettirmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan API sızma testi ve güvenli kod denetimi sağlıyoruz.