API Güvenlik Değerlendirmesi
API'ler modern uygulamaların iş mantığını doğrudan dışa açar; bu da onları saldırganların birincil hedefi yapar. REST ve GraphQL API'lerinizi OWASP API Security Top 10 çerçevesinde değerlendirir; nesne düzeyi yetkilendirme (BOLA), mass assignment, aşırı veri maruziyeti, rate limiting eksikliği ve token güvenliği gibi API'ye özgü riskleri kanıtla ortaya koyarız. Testler yalnızca yazılı yetkilendirme, tanımlı kapsam ve anlaşılan pencere içinde yürütülür.
Bu hizmet hangi sorunu çözer?
Web arayüzünün güvenli olması API'nin güvenli olduğu anlamına gelmez. Arayüz belirli işlemleri gizler veya kısıtlar; ancak API doğrudan çağrıldığında bu kısıtlamaların çoğu istemci tarafında kalmışsa anlamsızlaşır. API'lerin en yıkıcı zafiyetleri klasik web açıklarından farklıdır: nesne düzeyinde kırık yetki (BOLA) ile bir kullanıcının başka kullanıcının kayıtlarına erişmesi, mass assignment ile beklenmeyen alanların (örneğin “rol” veya “bakiye”) güncellenmesi, aşırı veri maruziyetiyle uç noktanın gereğinden fazla veri döndürmesi, ya da rate limiting eksikliğiyle numaralandırma ve kaba kuvvet saldırılarının kolaylaşması. GraphQL'de introspection'ın açık kalması, derin/iç içe sorgularla kaynak tüketimi ve alan düzeyi yetki eksikliği ek yüzeyler ekler. Bu riskler otomatik tarayıcıların büyük ölçüde kaçırdığı, uygulamanın veri modelini ve yetki mantığını anlamayı gerektiren kategorilerdir. API güvenlik değerlendirmesi tam da bu API'ye özgü mantığı hedefler.
- BOLA/IDOR ile başka kullanıcıların verilerine yetkisiz erişim
- Mass assignment yoluyla ayrıcalık yükseltme veya hassas alan değişikliği
- Aşırı veri maruziyetiyle gereksiz hassas verinin istemciye sızması
- Rate limiting eksikliğiyle numaralandırma, kaba kuvvet ve kaynak tüketimi
- Zayıf token/JWT doğrulaması ve gevşek OAuth2 akışlarıyla oturum ele geçirme
Bu sorunu görmezden gelmenin riski
Neyi değerlendirir ve düzeltiriz?
Yetkilendirme
- Nesne düzeyi yetki (BOLA): kaynak sahipliği doğrulaması
- İşlev düzeyi yetki: rol bazlı uç nokta erişimi
- Alan/özellik düzeyi yetki (özellikle GraphQL)
Veri ve girdi
- Mass assignment ve beklenmeyen alan güncellemeleri
- Aşırı veri maruziyeti ve hassas alan filtreleme
- Girdi doğrulama, enjeksiyon ve tip zorlama yüzeyi
Kimlik ve token
- JWT üretimi, imza doğrulaması ve süre yönetimi
- OAuth2 akış yapılandırması ve kapsam (scope) kontrolü
- API anahtarı yönetimi ve gizli bilgi ifşası
Dayanıklılık
- Rate limiting ve kaba kuvvet/numaralandırma koruması
- GraphQL sorgu derinliği ve karmaşıklık sınırları
- Hata yönetimi, ifşa ve tüketim (DoS) yüzeyi
Ele aldığımız teknik alanlar
Nasıl çalışırız?
Tipik olarak neler tespit ederiz?
Aşağıdakiler illüstratif örneklerdir; gerçek müşteri verisi değildir.
Nesne düzeyinde kırık yetki (BOLA) ile başka kullanıcı kayıtlarına erişim (örnek bulgu)
Bir GET uç noktası, istekteki kaynak kimliğinin oturum sahibine ait olup olmadığını doğrulamıyordu; kimlik değiştirilerek diğer kullanıcıların verileri okunabiliyordu.
ÖneriHer uç noktada kaynak sahipliğini sunucu tarafında doğrulayın; yetki kontrolünü merkezi bir katmanda zorunlu kılın ve testlerle her rol için kanıtlayın.
Mass assignment ile ayrıcalık yükseltme (örnek bulgu)
Kullanıcı profili güncelleme uç noktası, istekte gönderilen tüm alanları körlemesine kabul ediyordu; “rol” alanı gönderilerek standart kullanıcı yönetici olabiliyordu.
ÖneriGüncellenebilir alanları açık bir izin listesiyle (allow-list) sınırlayın; hassas alanları istemci girdisiyle asla eşlemeyin.
Rate limiting eksikliği ve GraphQL introspection açıklığı (örnek bulgu)
Kimlik doğrulama uç noktasında hız sınırı yoktu ve GraphQL introspection üretimde açıktı; bu, numaralandırma ve şema keşfini kolaylaştırıyordu.
ÖneriHassas uç noktalara rate limiting uygulayın; üretimde introspection'ı kapatın ve sorgu derinlik/karmaşıklık sınırları getirin.
Ne teslim alırsınız, kimler için?
Ne teslim alırsınız?
- Uç nokta envanteri ve roller arası erişim matrisi
- API'ye özgü bulgu kataloğu (kanıt + etki + CVSS)
- BOLA/mass assignment/aşırı maruziyet gibi kritik kategoriler için ayrı vurgular
- Token ve OAuth2/JWT güvenlik değerlendirmesi
- Önceliklendirilmiş giderme yol haritası
- Aktarım görüşmesi ve giderme sonrası yeniden test
Kimler için?
- Public/partner API sunan SaaS ve platform şirketleri
- Mobil ve SPA uygulamaların backend API ekipleri
- GraphQL API işleten ürün ekipleri
- API tüketicilerine güvenlik güvencesi vermesi gereken kurumlar
Bu hizmeti ne zaman düşünmelisiniz?
- Yeni bir API sürümü veya büyük uç nokta değişikliği öncesi
- Partner/müşteri entegrasyonundan önce güvence gerektiğinde
- GraphQL'e geçiş veya mikroservis ayrıştırması sonrası
- API üzerinden şüpheli erişim veya suistimal fark edildiğinde
API Güvenlik Değerlendirmesi mi, Genel Uygulama Değerlendirmesi mi?
| API Güvenlik Değerlendirmesi | Web Uygulama Güvenlik Değerlendirmesi | |
|---|---|---|
| Ana hedef | REST/GraphQL uç noktaları ve API mantığı | Uygulamanın tamamı (arayüz + API + akışlar) |
| Çerçeve | OWASP API Security Top 10 | OWASP Top 10 + iş mantığı |
| Öne çıkan riskler | BOLA, mass assignment, aşırı maruziyet | Kırık erişim, oturum, girdi, iş mantığı |
| İdeal durum | API ağırlıklı/headless ürünler | Uçtan uca bütüncül güvence ihtiyacı |
Sıkça Sorulan Sorular
REST ve GraphQL'i birlikte mi test ediyorsunuz?
OpenAPI/GraphQL şemasına ihtiyacınız var mı?
BOLA nedir ve neden bu kadar önemli?
Testler üretim verisine zarar verir mi?
JWT güvenliğini de kapsıyor mu?
Rate limiting olmaması gerçekten sorun mu?
Bu bir sızma testi mi?
Sonuçları nasıl gidereceğiz?
İlgili hizmetler, araçlar ve rehberler
Web Uygulama GüvenliğiYetkilendirme Testi
Web Uygulama GüvenliğiKimlik Doğrulama Güvenlik Testi
Web Uygulama GüvenliğiSızma Testi (Pentest)
Web Uygulama Güvenliği
API Güvenlik Değerlendirmesi için başlayalım
Kapsamı netleştirelim, önceliklerinizi belirleyelim ve size özel, şeffaf bir güvenlik yol haritası çıkaralım — abartılı vaat değil, ölçülebilir risk azaltma.