Fintech API Güvenliğinde İlk 10 Kontrol

Temel Değerlendirme

Fintech API güvenliği yalnızca injection, WAF veya rate limit kontrolü değildir. İlk bakılması gereken alanlar authorization, BOLA/IDOR, idempotency, transaction integrity, tenant isolation, provider güvenliği, audit log, fraud sinyalleri, secret yönetimi ve hata davranışıdır. Finansal sistemlerde küçük görünen bir API mantık hatası çift ödeme, yetkisiz transfer, müşteri verisi sızıntısı veya provider maliyet saldırısına dönüşebilir. Bu yüzden fintech API pentesti teknik endpoint testinden çok iş akışı güvenliği testidir.

Neden Fintech API'ler Farklıdır?

Fintech API'lerde her endpoint yalnızca veri döndürmez; para, kimlik, risk skoru, limit veya müşteri güveni üzerinde etki oluşturabilir.

Kritik farklar:

İşlemler geri alınması zor finansal etki doğurabilir.
Rate limit yalnızca availability değil fraud kontrolüdür.
Idempotency eksikliği tekrar eden ödeme veya transfer yaratabilir.
Provider entegrasyonları secret ve quota riski taşır.
Audit log regülasyon ve incident response için zorunludur.
Authorization hatası kişisel ve finansal veri sızıntısına dönüşebilir.

İlk 10 Kontrol

| # | Kontrol | Test sorusu | |---|---|---| | 1 | BOLA/IDOR | Kullanıcı başka müşterinin işlem, kart, hesap veya faturasına erişebiliyor mu? | | 2 | Transaction authorization | Kullanıcı bu finansal işlemi gerçekten yapmaya yetkili mi? | | 3 | Idempotency | Aynı istek tekrarlandığında çift işlem oluşuyor mu? | | 4 | Rate limit | Login, OTP, ödeme ve provider çağrılarında tenant/kullanıcı bazlı limit var mı? | | 5 | Transaction integrity | Tutar, para birimi, alıcı ve açıklama server-side doğrulanıyor mu? | | 6 | Audit log | Kim, ne zaman, hangi işlem için hangi sonucu aldı kaydediliyor mu? | | 7 | Provider security | SMS, ödeme, KYC veya banking provider secret'ları güvenli mi? | | 8 | Error handling | Hata mesajları hesap, limit veya fraud sinyali sızdırıyor mu? | | 9 | Webhook validation | Provider callback imzası ve replay kontrolü var mı? | | 10 | Fraud abuse | API davranışı bot, credential stuffing veya maliyet saldırısına açık mı? |

Pratik Örnek: Çift Transfer Riski

Bir para transfer endpointi düşünelim:

POST /api/transfers
{
  "toAccount": "TR...",
  "amount": 1000,
  "currency": "TRY"
}

Kullanıcı bağlantı hatası aldığında aynı isteği tekrar gönderirse ne olur? Eğer idempotency key yoksa sistem iki transfer oluşturabilir. Eğer idempotency var ama kullanıcı/tenant/amount bağlamına bağlı değilse saldırgan başka bir işlemle çakıştırabilir.

Güvenli tasarımda:

Idempotency key kullanıcı ve tenant bağlamına bağlıdır.
İşlem sonucu tekrar döndürülebilir ama yeni işlem oluşmaz.
Tutar ve alıcı server-side doğrulanır.
Audit log her denemeyi ilişkilendirir.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "WAF varsa fintech API güvendedir." | WAF iş mantığı, idempotency ve transaction authorization hatalarını çözmez. | | "OTP varsa işlem güvenlidir." | OTP doğru bağlama, süreye ve işlem detayına bağlı değilse bypass edilebilir. | | "Provider callback'i güvenilirdir." | İmza doğrulama ve replay protection yoksa sahte callback riski vardır. | | "Rate limit sadece DDoS içindir." | Fintech'te rate limit fraud, OTP abuse ve maliyet kontrolüdür. |

Test Edilmesi Gereken İş Akışları

Fintech API pentestinde sadece endpoint listesi değil, finansal akışlar test edilmelidir:

Kullanıcı kayıt ve KYC
Login, MFA ve session renewal
Hesap, kart veya wallet listeleme
Para transferi veya ödeme oluşturma
İade, iptal ve chargeback benzeri akışlar
OTP ve notification gönderimleri
Provider webhook/callback
Admin veya operasyon paneli işlemleri

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda fintech API güvenliği uzman test gerektirir:

Para transferi, ödeme, wallet veya kredi akışı var.
Çok kiracılı müşteri/merchant modeli kullanılıyor.
SMS, ödeme, banking, KYC veya fraud provider entegrasyonu var.
Compliance veya müşteri güvenlik değerlendirmesi yaklaşıyor.
API daha önce yalnızca scanner veya WAF ile kontrol edildi.

Test İçin Hazırlanması Gerekenler

Fintech API pentesti başlamadan önce şu bilgiler net olmalıdır:

Test kullanıcıları ve rolleri.
İşlem limitleri ve test bakiyeleri.
Ödeme, iade, transfer ve callback akışları.
Provider sandbox bilgileri.
Idempotency ve transaction ID davranışı.
Fraud veya risk motoru entegrasyonu.
Audit log erişimi.
Test sırasında gerçek para veya gerçek bildirim tetiklenip tetiklenmeyeceği.

Bu hazırlık yapılmazsa test ya fazla temkinli kalır ya da gerçek iş etkisini ölçmeden biter.

İçerik Yükseltme Önerisi

Bu yazının PDF karşılığı API Security Test Plan olmalıdır. Fintech ekipleri için endpoint listesinden çok transaction flow bazlı test matrisi sunar ve API Security Assessment kapsamına doğal geçiş sağlar.

Eresus Yaklaşımı

Eresus Security fintech API testlerinde authorization, idempotency, provider güvenliği, webhook doğrulama ve transaction integrity kontrollerini iş akışı üzerinden doğrular. Amacımız yalnızca endpoint açığı bulmak değil; finansal etki doğurabilecek saldırı yollarını kanıtlamaktır. Fintech API'niz için ilk kapsamı API Security Test Plan üzerinden birlikte çıkarabiliriz.

SSS

Fintech API pentesti normal API pentestten farklı mı?

Evet. Teknik kontroller aynıdır ama finansal iş akışı, idempotency, fraud ve provider davranışı daha derin test edilir.

WAF fintech API riskini azaltır mı?

Bazı teknik payloadları azaltır. Ancak iş mantığı, yetki ve transaction integrity problemleri için manuel test gerekir.

Provider webhook güvenliği nasıl test edilir?

İmza doğrulama, timestamp, replay protection, payload integrity ve beklenmeyen callback sırası test edilmelidir.