Web Uygulama Güvenliği Tek Seferlik Hizmet

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.

9 teknik alan 7 adımlı süreç 6 teslimat
Örnek bulgu türleri
KritikNesne düzeyinde kırık yetki (BOLA) ile başka
YüksekMass assignment ile ayrıcalık yükseltme (örn
OrtaRate limiting eksikliği ve GraphQL introspec
Neden ihtiyacınız var?

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
Neden önemli?

Bu sorunu görmezden gelmenin riski

API mantığı doğrudan açıktırArayüz katmanı olmadan iş kuralları çıplaktır. Sunucu tarafı yetki kontrolü eksikse, istemci kısıtlamaları hiçbir koruma sağlamaz.
BOLA en yaygın kritik risktirNesne düzeyinde kırık yetki, API ihlallerinin başında gelir. Her uç noktada kaynak sahipliğinin sunucuda doğrulanması şarttır.
Otomatik araçlar yetersiz kalırYetki ve veri modeli mantığı bağlam gerektirir; bunu ancak uygulamanın nasıl çalıştığını anlayan manuel test yakalar.
GraphQL yeni yüzeyler getirirIntrospection, iç içe sorgu derinliği ve alan düzeyi yetki, REST'te olmayan riskler doğurur; ayrı bir bakış gerektirir.
Token güvenliği kritiktirJWT doğrulama hataları ve gevşek OAuth2 akışları, tek bir zafiyetle geniş erişim kaybına yol açabilir.
Ekosistem güveni oluşurPartner ve müşteriler API'nizi entegre ederken güvenlik kanıtı ister; değerlendirme bu güveni somutlaştırır.
Kapsam

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
Teknik kapsam

Ele aldığımız teknik alanlar

OWASP API Security Top 10 kategorilerinin sistematik kontrolüBOLA/IDOR ve işlev düzeyi kırık yetki tespitiMass assignment ve aşırı veri maruziyeti analiziJWT doğrulama zayıflıkları (imza, alg karışıklığı, süre)OAuth2 akış ve kapsam (scope) yapılandırma kontrolüRate limiting, kaba kuvvet ve numaralandırma korumasıGraphQL introspection, sorgu derinliği ve karmaşıklık riskleriEnjeksiyon (SQLi dahil) ve girdi doğrulama yüzeyiCVSS temelli önceliklendirme ve kavram kanıtı üretimi
Metodoloji

Nasıl çalışırız?

Kapsam ve yetkilendirmeAPI uç noktalarını, kimlik doğrulama mekanizmasını, rolleri ve test penceresini belgeler; yazılı yetkilendirme ile kuralları netleştiririz. Belge/şema (OpenAPI/GraphQL schema) varsa dahil ederiz.
Uç nokta haritalamaTüm uç noktaları, parametreleri, veri modelini ve roller arası erişim matrisini çıkarırız; API'ye özgü test bunu gerektirir.
Yetkilendirme testiHer uç noktada nesne, işlev ve alan düzeyi yetki kontrollerini farklı roller ve kullanıcılar arasında test ederiz.
Veri ve girdi analiziMass assignment, aşırı maruziyet ve enjeksiyon yüzeyini inceler; beklenmeyen alanları ve dönen veriyi doğrularız.
Token ve dayanıklılıkJWT/OAuth2 güvenliğini ve rate limiting ile GraphQL karmaşıklık sınırlarını test ederiz.
Doğrulama ve raporlamaBulguları kavram kanıtıyla doğrular, CVSS ile önceliklendirir ve net giderme adımlarıyla raporlarız.
Yeniden testGiderme sonrası düzeltmelerin etkinliğini bağımsız olarak doğrularız.
Örnek bulgular

Tipik olarak neler tespit ederiz?

Aşağıdakiler illüstratif örneklerdir; gerçek müşteri verisi değildir.

Kritik

Nesne düzeyinde kırık yetki (BOLA) ile başka kullanıcı kayıtlarına erişim (örnek bulgu)

Etki

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.

Öneri

Her 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.

Yüksek

Mass assignment ile ayrıcalık yükseltme (örnek bulgu)

Etki

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.

Öneri

Güncellenebilir alanları açık bir izin listesiyle (allow-list) sınırlayın; hassas alanları istemci girdisiyle asla eşlemeyin.

Orta

Rate limiting eksikliği ve GraphQL introspection açıklığı (örnek bulgu)

Etki

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.

Öneri

Hassas uç noktalara rate limiting uygulayın; üretimde introspection'ı kapatın ve sorgu derinlik/karmaşıklık sınırları getirin.

Sonuç

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
Ne zaman?

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
Karşılaştırma

API Güvenlik Değerlendirmesi mi, Genel Uygulama Değerlendirmesi mi?

API Güvenlik DeğerlendirmesiWeb Uygulama Güvenlik Değerlendirmesi
Ana hedefREST/GraphQL uç noktaları ve API mantığıUygulamanın tamamı (arayüz + API + akışlar)
ÇerçeveOWASP API Security Top 10OWASP Top 10 + iş mantığı
Öne çıkan risklerBOLA, mass assignment, aşırı maruziyetKırık erişim, oturum, girdi, iş mantığı
İdeal durumAPI ağırlıklı/headless ürünlerUçtan uca bütüncül güvence ihtiyacı
SSS

Sıkça Sorulan Sorular

REST ve GraphQL'i birlikte mi test ediyorsunuz?
Evet. Her ikisini de kapsayabiliriz. GraphQL için introspection, sorgu derinliği/karmaşıklığı ve alan düzeyi yetki gibi ek riskleri de ayrıca ele alırız.
OpenAPI/GraphQL şemasına ihtiyacınız var mı?
Şema varsa kapsamı hızlandırır ve tamlığı artırır. Şema olmasa da uç noktaları haritalayarak test edebiliriz; ancak dokümantasyon paylaşmanız kapsamı iyileştirir.
BOLA nedir ve neden bu kadar önemli?
BOLA (Broken Object Level Authorization), bir kullanıcının başka kullanıcının nesnesine yetkisiz erişmesidir. API ihlallerinin en yaygın nedenidir çünkü sunucu tarafı sahiplik doğrulaması sıkça atlanır.
Testler üretim verisine zarar verir mi?
Tahribatsız çalışırız ve yıkıcı işlemlerden kaçınırız. Yazma işlemleri gerektiğinde önceden mutabık kalır, mümkünse test verisi/hesapları kullanır ve staging ortamını tercih ederiz.
JWT güvenliğini de kapsıyor mu?
Evet. İmza doğrulama, algoritma karışıklığı, süre ve iptal (revocation) gibi JWT konularını ve OAuth2 akış/kapsam yapılandırmasını değerlendiririz.
Rate limiting olmaması gerçekten sorun mu?
Evet. Hız sınırı eksikliği numaralandırma, kaba kuvvet ve kaynak tüketimini kolaylaştırır; özellikle kimlik doğrulama ve hassas uç noktalarda ciddi bir risktir.
Bu bir sızma testi mi?
API güvenlik değerlendirmesi kavram kanıtı düzeyinde doğrulama yapar. Daha derin, zincirleme istismar senaryoları isteniyorsa bunu yazılı yetkiye bağlı bir API sızma testi kapsamında sunarız.
Sonuçları nasıl gidereceğiz?
Rapor, her bulgu için sunucu tarafı yetki, allow-list ve yapılandırma odaklı net adımlar içerir. Giderme sonrası yeniden testle düzeltmeleri doğrularız.
Sonraki adım

İlgili hizmetler, araçlar ve rehberler

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.