Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler. Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez. Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Fintech (Finansal Teknoloji) Uygulamalarında API Güvenliği: Neden Sadece Kalkanlar (WAF) Yeterli Değil?

Günümüzde bankacılık, kripto cüzdanları, açık bankacılık (open banking) veya dijital ödeme altyapılarında kullanıcı verisini veya para akışını taşıyan ana damar API (Uygulama Geliştirme Arayüzü) mimarisidir. Şirketler bu damarı güvende tutmak için on binlerce dolar harcayarak WAF (Web Application Firewall) satın alırlar. Ancak asıl tehlike dışarıdan gelen kaba kuvvet (brute-force) saldırılarında değil, API’in "iş mantığının" içine gizlenmiş zafiyetlerdedir.

Temel Değerlendirme: Fintech uygulamalarındaki her işlem (para transferi, bakiye sorgulama) bir API üzerinden geçer. API altyapısını güvence altına almak sadece teknik bir tercih değil; yasal zorunluluk (KVKK/BDDK/GDPR) ve müşteri güveninin temelidir. Geleneksel güvenlik duvarları (WAF) sisteme gelen trafik anormalliklerini engeller fakat "kullanıcı yetkisini kötüye kullanan" tasarımsal onay zinciri açıklarını göremez. Finansal uygulamaların API mimarileri, iş mantığını kavrayabilen periyodik manuel sızma testleri veya Yapay Zeka destekli ajanlar (Agentic Security) ile içeriden dışarıya test edilmelidir.

1. Fintech Sektöründe API'ler Neden 1 Numaralı Hedef?

Geleneksel web sitelerinde bir hacker, sisteme sızmak için ekrandaki formları doldurarak sistemi kandırmaya çalışır. Ancak API'ler doğrudan sunucunun veri tabanıyla konuşur. Yani bir saldırgan arayüzü (frontend) tamamen atlayarak API uç noktalarına (endpoints) komut gönderdiğinde, önündeki filtrelenmemiş tüm bakiye ve müşteri verisine erişebilir.

Finansal verilerin karaborsadaki (Dark Web) değerinin çok yüksek olması, siber suçluların rotasını doğrudan "arka kapılara" yani API'lere çevirmiştir.

2. FinTech API'lerinde Görülen En Yıkıcı 3 Zafiyet (OWASP API Top 10)

Bankacılık ve startup ödeme altyapılarına yaptığımız sızma testlerinde sıklıkla şu üç kritik hatayla karşılaşıyoruz:

A. Obje Seviyesinde Yetkilendirme Hatası (BOLA / IDOR)

Gerçek Hayat Örneği: Hesabınıza giriş yaptınız ve hesap detaylarınızı çekmek için sistem arka planda şu API isteğini yaptı: GET /api/v1/bank/hesaplar/1005. Saldırgan, URL'deki 1005 sayısını 1006 olarak değiştirerek enter'a basar. Sistemin yetki kontrolü zayıfsa, başka bir müşterinin bakiye ve IBAN bilgilerini ekrana döker. (WAF bu isteği asla engellemez çünkü istek sıradan ve geçerli bir protokolle yapılmıştır.)

B. Oturum ve Kimlik Doğrulama Eksikleri (Broken Authentication)

Token (JWT) oluşturma mantığındaki hatalar nedeniyle çalınan veya süresi bitmeyen bir yetki belgesiyle işlem yapmaya devam edilmesi.

C. Hız Sınırlandırmasının (Rate Limiting) Olmaması

Gerçek Hayat Örneği: Bir kullanıcının para transferi yaparken SMS ile gelen OTP şifresini girmesi gerekir. API tarafında bir deneme limiti yoksa, saldırgan 3 dakika içinde saniyede binlerce istek yollayarak 6 haneli OTP kodlarını sırayla dener ve işlemi onaylatır.

3. Güvenlik Duvarı (WAF) API Güvenliğinde Neden Kör Kalıyor?

Birçok kurum güvenlik için bulut tabanlı bir WAF kurduğunda %100 güvende hissetme yanılgısına düşer. WAF, "zararlı karakterleri" (örneğin SQL komutları barındıran metinler) veya "olağandışı bölgeden gelen trafikleri" (DDoS) engeller.

Fakat yukarıdaki BOLA (IDOR) örneğini hatırlayın. Gelen istek, tamamen yasal bir "GET" işlemidir. Formatta hiçbir anormallik yoktur. Sorun isteğin kendisinde değil, "X kullanıcısının Y verisine erişim senaryosundadır." Bu tarz iş mantığı zafiyetleri yalnızca sistemin nasıl çalıştığını kavrayabilen manuel sızma testleri ile veya otonom yapay zeka araçlarıyla bulunabilir.

4. Eresus Security ve Ajan Tabanlı (Agentic) Çözüm Mimarisi

Finansal altyapılar saniyede binlerce istek alırken (ve her gün binlerce satır yeni kod yazılırken) güvenliği sadece "yılda bir kez yapılan pentestlere" bağlamak ciddi bir operasyonel defodur.

Eresus Security altyapısı, API dökümantasyonunuzu (Swagger/OpenAPI) okuyan, sistemin iş mantığını anlayan otonom Yapay Zeka Ajanları (LLM destekli analiz) kullanır. Eresus Security ajanları:

Sadece bilinen açık portları değil, API uç noktalarının birbiriyle nasıl zincirleme ilişki kurduğunu kavrar.
"Eğer ben normal bir kullanıcıysam ve A servisine yanlış bir token yollarsam B servisi nasıl tepki verir?" gibi kompleks senaryolar üretir.
Otomatik araçların yetersizliği ile insan test uzmanının yavaşlığını ortadan kaldırır.

Fintech API altyapınızın gerçekten güvenli olup olmadığından şüpheniz mi var? Eresus Security’nin otonom analiz platformuyla API'lerinizin dayanıklılığını test edin.

Temel Değerlendirme

Fintech (Finansal Teknoloji) Uygulamalarında API Güvenliği: Neden Sadece Kalkanlar (WAF) Yeterli Değil? konusu yalnızca teknik bir ayrıntı değildir; yanlış ele alındığında veri sızıntısı, yetki aşımı, operasyon kesintisi veya regülasyon riski doğurur. En doğru yaklaşım, varlıkları ve kullanıcı rollerini netleştirip gerçek saldırı yolunu kanıtla test etmek, ardından düzeltmeyi ölçülebilir retest kriterine bağlamaktır.

Neden Kritik?

Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler.
Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez.
Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Pratik Senaryo

Bir ekip sistemi güvenli kabul eder çünkü login çalışır, pipeline yeşildir veya model beklenen cevabı üretir. Ancak saldırgan aynı akışta farklı kullanıcı, farklı tenant, farklı dosya veya farklı token ile deneme yaptığında tasarımın sakladığı gerçek risk ortaya çıkar. Bu yüzden testler mutlu yol yerine kötüye kullanım senaryolarıyla yazılmalıdır.

Yanlış Bilinenler

“Araç taradı, kritik yok” güvenlik onayı değildir.
“İç sistem, saldırgan erişemez” varsayımı modern saldırı zincirlerinde zayıftır.
“Bu sadece teknik borç” denilen konu çoğu zaman müşteri verisi veya production erişimiyle birleşir.

Karar Tablosu

| Durum | Risk seviyesi | Önerilen aksiyon | | --- | --- | --- | | Demo veya izole test ortamı | Düşük-Orta | Mimari kararları ve veri akışını belgeleyin | | Staging production verisine yakın | Orta-Yüksek | Yetki, log ve abuse testlerini ekleyin | | Production veya müşteri verisi | Yüksek | Profesyonel assessment, remediation ve retest planlayın |

Kontrol Listesi

Her sorgu tenant ve ownership kontrolü içeriyor mu?
Session/JWT sadece kimlik mi taşıyor, yetkiyi nerede doğruluyor?
Queue job kullanıcı bağlamını koruyor mu?
Hata mesajları sistem içini açığa çıkarıyor mu?
Pahalı endpointler kullanıcı ve tenant bazında sınırlı mı?

Ne Zaman Profesyonel Destek Gerekir?

API çok kiracılı çalışıyorsa, finansal işlem yapıyorsa, queue/event akışları içeriyorsa veya müşteri verisine dokunuyorsa profesyonel backend security review gerekir.

Eresus Yaklaşımı

Eresus Security bulguları yalnızca başlık olarak raporlamaz. Her bulgu için tekrar üretilebilir kanıt, iş etkisi, önerilen düzeltme, sorumlu ekip ve retest koşulu yazılır.

Eresus Security, backend/API mimarilerinde tenant isolation, authorization, session, observability, queue güvenliği ve abuse senaryolarını iş etkisiyle birlikte test eder. İsa Can liderliğinde teknik review ve remediation planı çıkarabiliriz.

Uygulama Planı

1. Kapsamı Netleştir

Etkilenen varlıkları, kullanıcı rollerini ve veri sınıflarını çıkarın.
Normal kullanıcı akışıyla saldırgan akışını ayrı ayrı yazın.
Hariç tutulan sistemleri ve test sınırlarını açıkça belirtin.

2. Kanıt Üret

Bulguyu tek ekran görüntüsüne değil, tekrar üretilebilir adımlara bağlayın.
Etkiyi teknik hata ve iş sonucu olarak ayrı açıklayın.
Log, request ID, test hesabı ve zaman bilgisini not edin.

3. Retest Kriterini Belirle

Düzeltmenin ne zaman tamam sayılacağını önceden yazın.
Aynı sınıf hatanın başka endpoint veya akışlarda olup olmadığını kontrol edin.
Bulguyu kapatmadan önce negatif test senaryosunu yeniden çalıştırın.

Sık Sorulan Sorular