Ödeme API'leri Neden Ayrı Bir Güvenlik Yaklaşımı Gerektirir?
Ödeme API'leri, bir işletmenin dijital vitrininden müşterinin banka hesabına uzanan zincirin en kritik halkasıdır. Bu API'ler yalnızca veri taşımaz; aynı zamanda para hareketini tetikler, kart bilgisi işler ve regülatif olarak hassas kabul edilen kişisel verileri dolaştırır. Bu nedenle sıradan bir REST servisinin güvenlik testinden çok daha fazlası gerekir. payments.tr olarak bağımsız bir bilgi platformu kimliğimizle, bu rehberde ödeme API'lerinin güvenlik test sürecini uçtan uca ele alıyoruz. Amacımız, geliştiriciler, KOBİ'ler ve fintech ekipleri için uygulanabilir, mevzuata uygun ve gerçekçi bir yol haritası sunmaktır.
Ödeme API'lerinin diğer API'lerden ayrıldığı temel nokta, kart verisi ve kimlik doğrulama katmanlarının iç içe geçmiş olmasıdır. Bir e-ticaret sitesinde sepet tutarını gösteren API ile ödeme başlatan API aynı ağ üzerinden çalışsa da, ikincisi PCI DSS kapsamına girer. Türkiye'de ise BDDK ve TCMB düzenlemeleri, ödeme hizmetleri ve elektronik para kuruluşları için ek yükümlülükler getirir. Bu rehber, hem teknik hem de mevzuat tarafını birlikte ele almayı hedefler.
Ödeme API Güvenliğinde Temel Tehdit Modeli
Güvenlik testine başlamadan önce, korunmaya çalışılan varlıkların ve olası saldırı yüzeylerinin netleştirilmesi gerekir. Ödeme API'lerinde tipik tehditler şu başlıklarda toplanır:
- Kimlik doğrulama zayıflıkları: Zayıf API anahtarı yönetimi, süresi geçmeyen token'lar, yetersiz OAuth akışları.
- Yetkilendirme hataları: Bir kullanıcının başka bir kullanıcının işlem geçmişine erişebilmesi (IDOR), rol tabanlı kontrol eksikliği.
- Enjeksiyon saldırıları: SQL injection, NoSQL injection, komut enjeksiyonu ve XML external entity (XXE).
- İş mantığı açıkları: Tutar manipülasyonu, negatif tutar gönderimi, yarış koşulu (race condition) ile çift çekim.
- Veri sızıntısı: Log'lara kart numarası yazılması, hata mesajlarında iç sistem bilgisi paylaşılması.
- Webhook güvenliği: İmzasız webhook kabulü, tekrar oynatma (replay) saldırıları.
- Rate limiting eksikliği: Kart deneme (carding) saldırılarına açık uç noktalar.
Bu tehditlerin çoğu, OWASP API Security Top 10 listesinde karşılık bulur. Ödeme API'leri için bu listeyi genişletmek ve kendi iş mantığınıza özgü senaryolar eklemek gerekir. Örneğin, bir sanal POS entegrasyonunda "iptal" ve "iade" uç noktalarının yetkilendirmesi, ödeme başlatma kadar kritik olabilir.
Ödeme API'leri İçin Güvenlik Test Katmanları
Etkili bir güvenlik testi tek seferlik bir iş değil, sürekli bir döngüdür. Aşağıdaki katmanları birbirinden bağımsız düşünmemek gerekir; her katman bir sonrakini besler.
1. Statik ve Dinamik Kod Analizi
Geliştirme sürecinde SAST (Statik Uygulama Güvenliği Testi) araçları, kaynak kodda güvensiz desenleri yakalar. DAST (Dinamik Uygulama Güvenliği Testi) ise çalışan uygulamaya dışarıdan saldırı simüle eder. Ödeme API'leri için DAST taramasında özellikle şu noktalara odaklanılmalıdır: parametre manipülasyonu, kimlik doğrulama atlatma denemeleri ve hız sınırı testleri. Otomatik araçlar tek başına yeterli değildir; iş mantığı açıkları genellikle manuel test gerektirir.
2. Kimlik Doğrulama ve Yetkilendirme Testleri
Ödeme API'lerinde en sık görülen açıklar bu katmanda ortaya çıkar. Test edilmesi gereken başlıca senaryolar:
- API anahtarı veya token olmadan uç noktalara erişim denemesi.
- Süresi geçmiş token ile işlem başlatma girişimi.
- Bir kullanıcının token'ı ile başka kullanıcının işlem detayını sorgulama (IDOR).
- Yetki yükseltme: Normal kullanıcının yönetici uç noktalarına erişimi.
- OAuth akışlarında
redirect_urimanipülasyonu ve CSRF koruması.
Bu testlerin sonuçları, yetkilendirme matrisinin ne kadar sağlam olduğunu gösterir. Özellikle çoklu satıcı (marketplace) yapılarında tenant izolasyonu mutlaka test edilmelidir.
3. Veri Bütünlüğü ve İş Mantığı Testleri
Bir ödeme API'sinin en kritik özelliği, tutarın ve para biriminin değiştirilemez olmasıdır. Test sırasında şu senaryolar denenmelidir:
- İstemci tarafında gönderilen tutarın sunucu tarafında doğrulanıp doğrulanmadığı.
- Negatif veya sıfır tutarlı işlem denemeleri.
- Aynı işlem kimliği ile tekrarlanan isteklerin (idempotency) nasıl karşılandığı.
- Para birimi değiştirilerek kur manipülasyonu yapılıp yapılamadığı.
- Eşzamanlı isteklerle çift çekim oluşturulup oluşturulamadığı.
Ödeme API'lerinde iş mantığı açıkları, teknik açıklardan daha sık görülür ve genellikle otomatik araçlarla tespit edilemez. Bu nedenle manuel senaryo testleri zorunludur.
4. Altyapı ve Ağ Güvenliği
API'nin çalıştığı sunucu, veritabanı ve ağ katmanı da test kapsamındadır. TLS yapılandırması, sertifika zinciri, cipher suite seçimi ve HSTS başlıkları kontrol edilmelidir. Ayrıca WAF kurallarının ödeme uç noktalarını gereğinden fazla engelleyip engellemediği, yanlış pozitif üretip üretmediği de değerlendirilmelidir. Sızma testi (penetrasyon testi) raporları, düzenli aralıklarla bağımsız bir göz tarafından hazırlanmalıdır.
Türkiye'de Mevzuat ve Uyum Gereksinimleri
Türkiye'de ödeme API'leri geliştiren kuruluşlar için uyum tek bir düzenleyicinin sorumluluğunda değildir. BDDK, ödeme hizmetleri ve elektronik para kuruluşlarının lisanslama, sermaye ve operasyonel gerekliliklerini belirler. TCMB ise ödeme sistemleri ve ödeme hizmetleri alanında düzenleyici çerçeveyi şekillendirir; ayrıca FAST ve TR Karekod gibi altyapıların işleyişine dair kurallar koyar. KVKK ise kişisel verilerin işlenmesi ve saklanması boyutunda devreye girer.
Bu nedenle bir ödeme API'sinin güvenlik testi yalnızca teknik değil, aynı zamanda uyum testidir. Örneğin, kart verisinin saklanıp saklanmadığı, log'larda maskelenip maskelenmediği ve veri saklama sürelerinin KVKK ile uyumlu olup olmadığı test edilmelidir. Aşağıdaki tablo, teknik test başlıklarını ilgili düzenleyici ve standartlarla eşleştirir.
| Test Başlığı | İlgili Standart / Düzenleyici | Test Sıklığı |
|---|---|---|
| Kart verisi işleme ve maskeleme | PCI DSS, BDDK | Her sürümde + yıllık denetim |
| Kimlik doğrulama ve token yönetimi | OWASP API Top 10, TCMB | Sprint bazlı |
