Fintech'te bir API endpoint'inin güvenliği, sadece bir auth katmanından ibaret değil. Regülasyon (PSD2, BDDK, KVKK), fraud ve ölçek — hepsi birbiriyle konuşuyor ve birinde verilen yanlış karar diğerlerini de etkiliyor. Aşağıdaki notlar, regülasyonlu sektörlerde yürüttüğümüz projelerden damıtıldı; teorik bir liste değil, denetimlerden ve gerçek incident'lardan çıkan dersler.
OAuth 2.1 ve PKCE
Mobil uygulamalarda implicit flow tarihe karıştı; PKCE ile authorization code flow artık zorunlu standart. Bunu tamamlayan üç pratik: access token ömrünü kısa tutun (5–15 dakika), refresh token rotasyonu uygulayın (çalınan token bir kez kullanıldığında oturum ailesi iptal edilir) ve token'ları mobilde mutlaka Keychain/Keystore gibi donanım destekli güvenli depoda saklayın. Token'ı doğru üretmek yetmiyor; yaşam döngüsünü de yönetmek gerekiyor.
mTLS Server-to-Server
Kritik server-to-server endpoint'lerde karşılıklı TLS kullanıyoruz: iki taraf da sertifikayla kimliğini kanıtlamadan bağlantı kurulamıyor. Sertifika yönetimi acılı, doğru — ama bu acı, otomasyonsuz yönetmeye çalışmaktan kaynaklanıyor. cert-manager veya Vault ile sertifika üretimi ve rotasyonu otomatikleştirilmeden mTLS sürdürülebilir değil. Sahada gördüğümüz en yaygın kesinti sebeplerinden biri hâlâ süresi dolan sertifikalar; izleme ve otomatik yenileme pazarlık konusu olmamalı.
Rate Limiting + Anomaly Detection
Savunmayı iki katman halinde kuruyoruz. Birinci katman deterministik: token bucket tabanlı rate limiting; IP, kullanıcı ve endpoint bazında ayrı eşiklerle. Bu katman kaba kuvvet denemelerini, credential stuffing'i ve scraping'i ucuz ve öngörülebilir şekilde keser.
İkinci katman olasılıksal: ML tabanlı anomali tespiti, normal kullanım desenlerini öğrenir ve limitlerin altında kalmasına rağmen şüpheli olan trafiği işaretler — örneğin gece 03:00'te düşük hızda ama sistematik ilerleyen sıralı hesap doğrulama denemeleri. Birinci katman saldırının gürültülü olanını, ikinci katman sofistike olanını yakalar; ikisi birbirinin yerine geçmez, birbirini tamamlar.
Audit Loglar
Her PII erişimi loglanmalı: kim, neye, ne zaman ve hangi gerekçeyle erişti. Regülasyon gereği bu kayıtları WORM (write-once, read-many) storage'da 7 yıl saklıyoruz — yani loglar sonradan değiştirilemiyor, bu da onları denetimde delil niteliğine taşıyor. Sık atlanan bir detay: audit logun kendisi bir sızıntı kaynağı olmasın. Log içeriğinde PII maskelenmeli; aksi halde "güvenlik kaydı" diye tuttuğunuz şey, en az korunan kopya haline gelir.
Tokenizasyon
Hassas verileri (kart numarası, TCKN) hiçbir zaman kendi veritabanınızda tutmayın; tokenize edin. Veri, ayrı bir ağ segmentinde yaşayan vault servisinde durur, uygulamalarınız yalnızca anlamsız token'ları taşır. Bunun güvenlik kadar önemli bir ticari getirisi var: PCI DSS kapsamınız daralır, denetim maliyeti ve süresi ciddi ölçüde düşer. DB'niz sızsa bile saldırganın eline işe yarar veri geçmez.
Kapanış
Fintech'te API güvenliği tek seferlik bir proje değil, işletilen bir süreç: düzenli pentest takvimi, bağımlılık taraması ve her yeni endpoint için tasarım aşamasında güvenlik incelemesi. Regülasyonlu bir üründe API güvenlik mimarinizi gözden geçirmek isterseniz, Avva Mobile'ın saha tecrübesi olan ekibiyle konuşabilirsiniz.
