kullanici1
Mart 18, 2026

Uygulamaların “ekranı” değişebilir; fakat arka plandaki API’ler genellikle aynı kalır ve iş süreçlerinin asıl taşıyıcısı olur. Mobil uygulamalar, web arayüzleri, mikroservisler, üçüncü parti entegrasyonlar ve otomasyon sistemleri çoğu zaman API’ler üzerinden konuşur. Bu da API’leri, saldırgan açısından değerli bir hedef hâline getirir: kimlik doğrulama hataları, yetkilendirme boşlukları, zayıf giriş doğrulama ve yanlış yapılandırmalar doğrudan veri sızıntısı veya hesap ele geçirme ile sonuçlanabilir.
API güvenliği tek bir teknolojiye indirgenemez; çünkü REST, SOAP ve GraphQL farklı tasarım varsayımları ve risk profilleri taşır. Sağlam bir yaklaşım, ortak temel kontrolleri kurarken her API stilinin kendine özgü saldırı yüzeyini ayrıca yönetmeyi gerektirir.
API güvenliği; kimlik doğrulama, yetkilendirme, veri bütünlüğü, gizlilik, kullanılabilirlik ve denetlenebilirlik hedeflerini API katmanında sağlama disiplinidir. Burada amaç, yalnızca “endpoint’i korumak” değil; veri akışlarını, iş kurallarını ve erişim sınırlarını uçtan uca güvenli kılmaktır.
API’ler çoğu zaman kullanıcı arayüzünden daha az görünür olduğu için hatalar sessizce büyüyebilir. Bu nedenle güvenlik; tasarım aşamasından başlayarak (secure-by-design), geliştirme/test süreçlerine ve üretim gözlemlemesine kadar devam eden bir döngü olarak ele alınmalıdır.
Üç yaklaşımın ortak riskleri olsa da güvenlik pratikleri farklı alanlarda yoğunlaşır:
1) REST API Güvenliği:
REST, genellikle JSON ve HTTP metodları üzerinden çalışır. En büyük riskler yetkilendirme hataları (özellikle nesne seviyesinde erişim kontrolü), aşırı veri ifşası, zayıf rate limit ve hatalı input doğrulama etrafında toplanır. Ayrıca versiyonlama ve backward-compatibility nedeniyle eski endpoint’lerin unutulması sık rastlanan bir problemdir.
2) SOAP API Güvenliği:
SOAP, XML tabanlıdır ve kurumsal entegrasyonlarda yaygındır. Güvenlikte iki ana alan öne çıkar: XML parsing riskleri (ör. XXE benzeri parser problemleri) ve mesaj seviyesinde güvenlik (WS-Security) karmaşıklığı. SOAP’ta yalnızca TLS yeterli olmayabilir; mesaj imzalama/şifreleme gibi mekanizmaların doğru uygulanması kritik hâle gelir.
3) GraphQL API Güvenliği:
GraphQL, tek endpoint üzerinden esnek sorgular sunar. Bu esneklik, aşırı sorgu karmaşıklığı (DoS), yetkisiz alan erişimi, şema keşfi (introspection) ve “over-fetching”/“under-fetching” kontrolü gibi konuları öne çıkarır. Ayrıca resolver katmanında yetkilendirme yapılmadığında, tek bir query ile çok geniş veri alanına erişim doğabilir.
API güvenliğinde tekrar eden hata sınıfları, teknoloji fark etmeksizin benzer şekilde görülür:
1) Nesne Seviyesi Yetkilendirme Hataları (IDOR/BOLA):
Kullanıcı, kendine ait olmayan kaynak ID’sini vererek başka bir kullanıcının verisine erişebilir. Özellikle REST’te sık görülür; GraphQL’de de resolver bazlı yetkilendirme eksikliğinde ortaya çıkar.
2) Fonksiyon Seviyesi Yetki Sorunları:
‘Admin’ işlemleri veya kritik eylemler, rol kontrolü zayıfsa normal kullanıcı tarafından tetiklenebilir.
3) Zayıf Kimlik Doğrulama ve Token Yönetimi:
JWT yanlış doğrulanması, uzun ömürlü token’lar, refresh token koruması eksikliği veya MFA olmayan kritik işlemler risk yaratır.
4) Rate Limit ve Kaynak Tüketimi:
Brute force, credential stuffing veya GraphQL’de pahalı sorgularla servis kalitesi düşürülebilir.
5) Veri Doğrulama Eksikleri:
Şema doğrulaması yoksa, beklenmeyen tip/alanlarla iş mantığı bozulabilir veya enjeksiyon zemin bulabilir.
6) Hatalı Hata Mesajları ve Loglama:
Detaylı stack trace veya iç yapı bilgisi sızdıran hata mesajları, saldırganın keşfini hızlandırır.
API stilinden bağımsız olarak aşağıdaki kontroller, çoğu ortamda “olmazsa olmaz” kabul edilebilir:
Stile göre eklemlenebilecek bazı pratik önlemler şunlardır:
Bu önlemler, temel kontrollerle birleştiğinde API yüzeyini daha öngörülebilir ve yönetilebilir hâle getirir.
API güvenliği sürdürülebilir bir program olarak ele alınmalıdır:
Bu yaklaşım, REST/SOAP/GraphQL fark etmeksizin API’lerin güvenliğini ölçülebilir şekilde yükseltir ve saldırı yüzeyini daraltır.