2023 yılında T-Mobile, bir API açığı üzerinden 37 milyon müşterisinin verisini çaldırdı. Saldırgan herhangi bir kimlik bilgisine ihtiyaç duymadı; sadece başkasına ait hesap bilgilerine ulaşmasını sağlayan bir nesne referans hatasını kullandı. Bu, OWASP API Top 10 listesinde birinci sıradaki açıktı. Liste teorik değildir; her madde gerçek ihlallerin ortak paydasından türetilmiştir.
API1 — Bozuk Nesne Düzeyi Yetkilendirme (BOLA)
Liste başı açık çok basittir: GET /api/orders/1234 çağrısı sipariş numarası 1234 olan kaydı döndürür. Peki 1235’i deneseydik? Sunucu yalnızca “bu token geçerli mi” diye bakıyor ama “bu kullanıcı bu kaydı okuma yetkisine sahip mi” diye bakmıyorsa her numara denenebilir. Otomatik bir script ile binlerce kayıt dakikalar içinde elde edilir. Çözüm nesne seviyesinde sahiplik kontrolüdür: her kayıt talebinde oturum açan kullanıcının ID’si, kaydın sahibiyle veritabanı sorgusunda karşılaştırılmalıdır. UI’da “gösterme” yeterli değildir.
API2 — Bozuk Kimlik Doğrulama
JWT token’ların süresi dolmuyorsa veya imzalama anahtarı zayıfsa, ele geçirilen bir token sonsuza kadar geçerli kalır. Sık karşılaşılan ve felakete yol açan bir hata: algorithm: none kabul eden kütüphane konfigürasyonları. Saldırgan token başlığında algoritmayı “none” olarak değiştirir, imzayı tamamen siler; uygulama bu token’ı geçerli sayar. JWT kütüphanesinin yapılandırmasında yalnızca HS256 veya RS256 gibi belirli algoritmalar kabul edilmeli, “none” açıkça reddedilmelidir.
API3 — Aşırı Veri İfşası
Kullanıcı profil sayfası için GET /api/users/me çağrısı yapılıyor. Uygulama UI’da yalnızca adı ve e-postayı gösteriyor ama API yanıtında doğum tarihi, TC kimlik numarası ve şifrelenmiş kart bilgisi de yer alıyor. “Uygulama zaten göstermiyor” mantığı yanlıştır: API yanıtı tarayıcı DevTools’dan, Burp Suite’ten veya mobil uygulamanın trafik analizinden herkes tarafından okunabilir. API yanıtı yalnızca gerçekten kullanılan alanları döndürmelidir; “belki ilerleyen sürümde lazım olur” gerekçesiyle ekstra alan göndermek ciddi bir risktir.
API4 — Kaynak Tüketimi Sınırsızlığı
Rate limiting olmayan bir API, bir botla saniyede binlerce istek alabilir; bu hem performansı çökertir hem de brute force saldırılarına kapı açar. Yanıt boyutu da sınırsız bırakılmamalıdır. limit parametresi kabul eden bir endpoint’te limit=999999 gönderildiğinde veritabanı milyonlarca satır döndürmeye çalışabilir ve sunucu belleği tükenir. Maksimum sayfalama boyutu (örneğin 100) ve istekte bulunma hızı limiti (örneğin kimlik doğrulamalı kullanıcı için dakikada 60 istek) API gateway katmanında zorunlu tutulmalıdır.
API5 — İşlev Düzeyinde Bozuk Yetkilendirme
Kullanıcı rolü “okuma” iken DELETE /api/products/55 isteği gönderilmesine izin veren API’lar bu kategoriye girer. UI’da silme butonu görünmüyor olabilir ama endpoint açıktır. Her HTTP metodu için ayrı yetki kontrolü zorunludur; GET ile erişebilmek PUT veya DELETE yetkisi vermez. RBAC (Role-Based Access Control) yalnızca frontend menülerine değil, her endpoint ve her HTTP metoduna ayrı ayrı uygulanmalıdır.
API8 — Güvenlik Yapılandırma Hataları
Pratikte en sık karşılaşılan yapılandırma sorunları şunlardır:
- CORS politikasında
Access-Control-Allow-Origin: *— herhangi bir origin’den çapraz kaynak isteği kabul edilir; kötü niyetli bir siteden API’ya erişim kapısı açılır. - HTTP üzerinden API erişimi açık bırakılmış — TLS zorunlu kılınmamış, trafik dinlenebilir.
- Hata mesajlarında stack trace veya veritabanı sorgusu görünüyor — saldırgana altyapı haritası ve teknoloji yığını sunulmuş olur.
- Swagger/OpenAPI arayüzü production’da herkese açık — tüm endpoint listesi, parametre yapısı ve örnek değerler dışarıya verilmiş demektir.
API Güvenliğini Test Etmek İçin Araçlar
OWASP ZAP, API Scanner modüyle yukarıdaki açıkların büyük bölümünü otomatik olarak tespit edebilir ve ücretsizdir. Burp Suite Professional daha kapsamlı manuel testler ve özel payload denemeleri için kullanılır. CI/CD pipeline’a entegre edilebilen bir araç arıyorsanız nuclei, API güvenlik şablonlarıyla tarama yapabilir ve her commit sonrası otomatik çalıştırılabilir. En kısa yol: staging ortamında bu araçlardan biriyle tarama başlatmak ve çıktıyı geliştirici ekibiyle birlikte incelemektir. Bulguların büyük çoğunluğu kod karmaşıklığından değil, gözden kaçan birkaç yapılandırma satırından kaynaklanır.
API Gateway ile Merkezi Güvenlik Katmanı
Her mikroservis ekibinin kendi rate limiting, kimlik doğrulama ve loglama katmanını uygulamasını beklemek tutarsız sonuçlar verir. API Gateway (AWS API Gateway, Kong, Apigee veya açık kaynak Traefik) bu sorumlulukları merkezi olarak üstlenir. Token doğrulama, IP bazlı engelleme, istek başlık denetimi ve yanıt şeması doğrulaması gateway katmanında bir kez yapılandırılır; tüm API’lara tutarlı biçimde uygulanır. Bu yapı aynı zamanda saldırı loglarını tek noktada toplar; bir güvenlik olayında trafik analizi çok daha kolay hale gelir.
OWASP API Top 10 listesi bir kontrol maddesi değil, gerçek saldırı senaryolarının derlemesidir. Her başlık, bir şirketi milyonlarca dolara mal olan gerçek bir olayı temsil eder. Listeden başlamak, test ortamında bir açık bulmak ve düzeltmek — bu döngüyü bir kez tamamlayan ekip, API güvenliğini nasıl düşüneceğini öğrenmiş olur.