API Güvenliği : Görünmeyen Tehditler

Api kullanımı ve api güvenliği dijital dönüşümün hızla yaygınlaştığı teknoloji çağında kurumların iş süreçlerinin merkezinde yer almaktadır. Mobil uygulamalar, mikroservis mimarileri, IoT cihazları, bulut servisleri ve üçüncü taraf entegrasyonlar, API’ler üzerinden veri alışverişi yaparak iş dünyasının hızla gelişmesini sağlar. API kullanımının bu denli yaygınlaşması, aynı zamanda ciddi api güvenliğ sorunlarını da beraberinde getirir.

Siber saldırganlar, bir kurumun resmi olarak dokümante ettiği API uç noktalarını hedef alabileceği gibi, çoğu zaman fark edilmeyen ve korunmayan Shadow API, Zombie API ve Orphan API türlerini keşfederek saldırılarını buradan gerçekleştirir. API’ler genellikle kurumun güvenlik politikalarının dışında kalır, izlenmez ve güncellenmez. Dolayısıyla görünmeyen ancak yüksek risk taşıyan bir saldırı yüzeyi oluştururlar.

Shadow API

Shadow API, kurumların resmi envanterinde bulunmayan, belgelenmemiş ve çoğunlukla geliştirme sürecinden production ortamına yanlışlıkla taşınan API uç noktalarıdır. Geliştiriciler yeni bir özelliği test etmek için geçici bir API açabilir, ancak API’nin daha sonra kapatılması unutulabilir. Güvenlik ekiplerinin radarına girmeyen uç noktalar, saldırganlar için adeta açık bir kapı niteliğindedir.

Shadow API’lerin en tehlikeli yanı, merkezi güvenlik katmanlarının dışında kalmalarıdır.  API Gateway üzerinde tanımlı olmayan bir uç nokta, kimlik doğrulama ve rate limiting gibi kontrollerden geçmez. Aynı şekilde WAF tarafından da izlenmediği için saldırılara karşı savunmasız kalır.

Örnek Senaryo:
Bir e-ticaret platformu, yeni bir kampanya modülünü test etmek için “/api/discounts-test” isimli bir endpoint oluşturur. Testler tamamlandıktan sonra API kapatılması gerekirken production ortamında aktif kalır. Saldırgan endpoint’i keşfederek ürünlere kendi istediği oranda indirim uygular ve sistemi manipüle eder.

Zombie API

Zombie API, kullanım dışı bırakıldığı sanılan ancak hala aktif olan eski API sürümleridir. Özellikle versiyonlama süreçlerinde yapılan hatalar nedeniyle ortaya çıkar. Bir uygulama yeni sürüme geçse de, backward compatibility sağlamak için eski sürüm bir süre açık tutulabilir. Ancak süreç doğru yönetilmezse, eski API sürümleri yıllarca açık kalabilir.

Zombie API’ler, genellikle güncellenmedikleri için bilinen güvenlik açıklarını barındırır. Modern API sürümlerinde uygulanan JWT tabanlı kimlik doğrulama mekanizması v2’de yer alırken, v1 hala basit token doğrulama ile çalışıyor olabilir. Bu durum saldırganlara daha kolay bir erişim imkânı sunar.

Örnek Senaryo:
Bir bankacılık uygulaması, müşteri işlemleri için /api/v1/transactions endpoint’ini kullanırken, yeni güvenlik özellikleriyle geliştirilmiş /api/v2/transactions devreye alınır. Ancak v1 kapatılmaz. V1 sürümünde SQL Injection açığı olduğunu keşfeden bir saldırgan, müşteri hesaplarına erişim sağlar ve para transferleri gerçekleştirir. Bu durum bankanın sadece maddi değil, itibari kayıplar yaşamasına da yol açar.

Orphan API

Orphan API, bağlı olduğu sistem veya uygulama artık kullanılmıyor olmasına rağmen hala aktif durumda olan API endpointlerdir. Çoğunlukla kurumların IT altyapısında yapılan değişiklikler, eski yazılımların terk edilmesi veya birleşme/devralma süreçleri sonucunda ortaya çıkar.

Orphan API’lerin en büyük sorunu, genellikle sahipliklerinin olmamasıdır. Bu tür durumlarda API’lerden sorumlu bir ekip bulunmaz, güncellemeleri yapılmaz ve izlenmezler. Bu da saldırganlar için kolay bir hedef oluşturmalarına neden olur.

Örnek Senaryo:
Bir şirketin yıllar önce kullandığı HR (İnsan Kaynakları) yazılımı devre dışı bırakılmıştır. Ancak  /hr/employee-data API’si hala erişime açıktır. Eski çalışanlara ait veriler bu endpoint üzerinde tutulmaya devam ettiği için saldırganlar, kurumun geçmiş personeline ait kişisel bilgilere kolaylıkla erişim sağlar.

Ortak Tehditler

Shadow, Zombie ve Orphan API’lerin ortak özellikleri :

• Envanter dışıdırlar → Güvenlik taramalarında ve testlerinde görünmezler.
• Güncellenmezler → Bilinen güvenlik açıklarıyla çalışmaya devam ederler.
• İzlenmezler → Merkezi loglama ve SIEM sistemleri bu API’leri kapsamaz.
• Saldırı yüzeyini genişletirler → Kurum farkında olmadan yeni giriş noktaları açar.

Siber saldırganlar genellikle bu API’leri keşfetmek için endpoint enumeration, fuzzing, Shodan taramaları ve pasif bilgi toplama tekniklerini kullanır.

API İş Akışı: Dıştan İçe

1. Kullanıcı / Client (Browser, Mobil Uygulama, 3rd Party API Consumer)
   Kullanıcı, uygulama üzerinden API isteği başlatır.

2. WAF (Web Application Firewall)
   İstek önce WAF üzerinden geçer. Burada SQL Injection, XSS, brute force gibi temel saldırılar engellenir. Aynı zamanda bot ve DDoS trafiği filtrelenir.

3. API Gateway
   API Gateway, kimlik doğrulama, rate limiting, routing ve logging gibi görevleri üstlenir. Burada JWT token kontrolü yapılır, istek ilgili mikroservise yönlendirilir.

4. Backend Services (Mikroservisler)
   İstek iş mantığını yürüten mikroservislere ulaşır. Örneğin, sipariş yönetimi, ödeme veya kullanıcı profili mikroservisleri.

5. Database / Data Layer
   Son aşamada veritabanına erişim yapılır, gerekli veri çekilir veya güncellenir.

Bu süreçte Shadow, Zombie veya Orphan API’lerin herhangi bir aşamaya dahil olması, zinciri zayıflatır. Örneğin, WAF ve API Gateway’den geçmeyen bir Shadow API doğrudan backend’e ulaşabilir. Bu da büyük bir api güvenliği riski doğurur.

Çözüm ve Önlemler

API Envanteri Yönetimi

• Tüm API’ler merkezi bir envanterde tutulmalıdır.
• Otomatik API discovery araçları  kullanılmalıdır.

API Gateway ve WAF Kullanımı

• Hiçbir API, gateway veya WAF dışında çalışmamalıdır.
• Rate limiting, authentication, authorization ve input validation zorunlu hale getirilmelidir.

Lifecycle Yönetimi

• API’ler yaşam döngüsü boyunca (tasarım, geliştirme, test, production, kullanım dışı bırakma) takip edilmelidir.
• Eski sürümler otomatik olarak kapatılmalı, yeni sürümlere geçiş süreçleri kontrollü yapılmalıdır.

Monitoring ve SIEM Entegrasyonu

• Tüm API çağrıları loglanmalı ve SIEM sistemine entegre edilmelidir.
• Anomaliler için makine öğrenmesi tabanlı analiz sistemleri kullanılmalıdır.

Sahiplik Atama

• Her API için sorumlu bir ekip veya kişi belirlenmelidir.
• Sahipliği olmayan API’ler otomatik olarak riskli kabul edilip kapatılmalıdır.

Kurumların modern API güvenliği stratejileri geliştirerek “Tüm API’leri keşfet, envantere al, sürekli izle ve yönet” prensibiyle hareket etmesi gerekir. OWASP API Security Top 10’da da belirtildiği gibi, API’lerin yalnızca geliştirilmesi değil, aynı zamanda yaşam döngüsü boyunca güvenliğinin sağlanması kritik bir gerekliliktir.

Api güvenliği sadece güvenlik ekiplerinin değil, aynı zamanda yazılım geliştirme, operasyon ve yönetişim ekiplerinin ortak sorumluluğu olmalıdır. Ancak bu şekilde görünmeyen API tehditleri bertaraf edilebilir ve dijital sistemler güvenli bir şekilde çalışmaya devam edebilir.

Faydalı olması dileği ile…