API güvenlik testiyle REST ve GraphQL uçlarında yetkilendirme, belirteç, veri sızıntısı, iş akışı ve kaynak tüketimi açıklarını gerçekçi senaryolarla belirliyoruz.
Son güncelleme: 13.10.2026
Mobil uygulamaların ve tek sayfalı arayüzlerin arkasındaki API, çoğu zaman arayüzden daha fazlasına izin verir. Testte her ucu, arayüzün göndermeyeceği isteklerle sınarız.
Özellikle bir kullanıcının başka bir kullanıcının verisine erişip erişemediğine bakarız; API açıklarının büyük bölümü burada çıkar.
API güvenlik testi, uygulamaların birbiriyle veri ve işlem paylaştığı REST, GraphQL veya benzeri servis uçlarını gerçekçi saldırı senaryolarıyla değerlendiren kontrollü bir güvenlik çalışmasıdır. Mobil uygulama, tek sayfalı web arayüzü, iş ortağı entegrasyonu ve mikroservis mimarisi çoğu zaman aynı API katmanına güvenir. Bu katmandaki tek bir yetkilendirme hatası, arayüzde görünmeyen verilere veya kritik işlevlere doğrudan erişim sağlayabilir.
Testin amacı yalnızca hangi uçların cevap verdiğini görmek değildir. Her kullanıcının hangi nesneye, alana ve işleve erişebildiği; belirteçlerin nasıl üretildiği; istek sınırlarının nasıl uygulandığı ve API'nin beklenmeyen girdiler karşısında nasıl davrandığı incelenir. Çalışma sistem sahibinin yazılı izniyle, önceden belirlenen ortam ve güvenli test kuralları içinde yürütülür.
OWASP API Security Top 10, API'lere özgü temel riskleri nesne düzeyi yetkilendirme, kimlik doğrulama, nesne özellikleri, kaynak tüketimi, işlev yetkilendirmesi, hassas iş akışları, SSRF, yanlış yapılandırma, envanter ve üçüncü taraf API kullanımı başlıklarında toplar. API güvenlik testi kapsamını uygulamanın işlevleri ve tehdit modeliyle birlikte bu referans üzerinden şekillendiririz.
Bir web veya mobil arayüz, kullanıcıya yalnızca izin verilen düğmeleri ve alanları gösterir. Fakat saldırgan arayüzü kullanmak zorunda değildir; HTTP isteklerini doğrudan oluşturabilir, parametreleri değiştirebilir ve uygulamanın hiç göndermediği alanları API'ye ekleyebilir. Arayüzde bir yönetici düğmesinin gizlenmesi, arka uçta yetkilendirme kontrolü yoksa koruma sağlamaz.
API'ler ayrıca çok sayıda istemciye hizmet verir. Eski mobil sürümler, iş ortağı entegrasyonları, dahili servisler ve belgelenmemiş uçlar aynı anda aktif kalabilir. Bu çeşitlilik; sürüm yönetimi, erişim anahtarı, veri minimizasyonu ve envanter konularını klasik sayfa testinden daha önemli hale getirir.
Bu nedenle API katmanı, yalnızca web uygulamasının bir parçası olarak yüzeysel biçimde değil, uç ve kullanıcı rolü bazında ayrıca incelenmelidir. Ön yüz ile birlikte geniş kapsamlı bir değerlendirme gerekiyorsa web uygulama sızma testi ile API testi aynı çalışma içinde planlanabilir.
Bir istek içindeki kullanıcı, sipariş, dosya veya hesap kimliği değiştirilerek başka bir kullanıcıya ait kayda erişilip erişilemediği kontrol edilir. Bu risk genellikle BOLA ya da IDOR adlarıyla anılır. Geçerli bir oturumun bulunması yeterli olmamalı; API her istekte kullanıcının talep ettiği nesne üzerinde yetkili olduğunu sunucu tarafında doğrulamalıdır.
Örneğin /orders/125 isteğini gönderebilen bir kullanıcı, numarayı 126 yaptığında başka müşterinin siparişini görmemelidir. Benzer kontroller okuma, güncelleme, silme ve dosya indirme işlemleri için ayrı ayrı yapılır. Tahmin edilemez kimlikler riski azaltabilir ancak yetkilendirme kontrolünün yerine geçmez.
API anahtarları, oturum belirteçleri, JWT yapıları, OAuth akışları ve parola sıfırlama uçları değerlendirilir. Belirteç süresi, iptal mekanizması, imza doğrulaması, alıcı ve veren kontrolleri gibi ayrıntılar incelenir. Süresi dolmuş veya çıkış sonrası iptal edilmiş bir belirtecin kullanılmaya devam edip etmediği sınanır.
Kaba kuvvet denemelerine karşı koruma yalnızca giriş ucunda değil, tek kullanımlık kod, parola yenileme ve hesap doğrulama gibi alternatif akışlarda da aranır. Hata mesajlarının kullanıcı veya hesap varlığını gereksiz yere ifşa edip etmediği kontrol edilir.
Bir kullanıcının kaydı görmeye yetkili olması, kaydın bütün alanlarını okuyabileceği veya değiştirebileceği anlamına gelmez. API yanıtında kişisel veri, iç sistem alanı, maliyet bilgisi veya yönetim bayrağı gibi gereksiz özelliklerin dönüp dönmediği araştırılır.
İstek gövdesine arayüzün göndermediği role, is_admin, status veya indirim oranı gibi alanlar eklenerek toplu atama riskleri test edilir. Sunucu kabul ettiği ve döndürdüğü özellikleri açık biçimde sınırlandırmalıdır.
Normal bir kullanıcının yönetici, destek ekibi veya sistem hesabına ait uçları çalıştırıp çalıştıramadığı kontrol edilir. Yalnızca URL yapısına, HTTP metoduna veya istemci tarafında gizlenen menüye güvenilmemelidir. Aynı işlevin farklı sürümlerde ya da alternatif uçlarda daha zayıf korunup korunmadığı da değerlendirilir.
API isteğinin CPU, bellek, depolama, ağ veya ücretli üçüncü taraf servisi ne kadar tüketebildiği incelenir. Büyük sayfa boyutları, sınırsız dosya yükleme, GraphQL sorgu derinliği, toplu işlemler ve paralel istekler kontrollü biçimde değerlendirilir.
Hız sınırı bütün uçlara aynı sayıyı uygulamak değildir. Giriş denemesi, SMS gönderimi, rapor oluşturma ve genel veri okuma uçlarının iş etkisi farklıdır. Kullanıcı, anahtar, cihaz ve IP gibi uygun bağlamlarda sınırlama yapılmalı; pahalı işlemler için harcama ve kullanım alarmları da düşünülmelidir.
Rezervasyon, kupon, davet, bilet satın alma, yorum oluşturma ve parola sıfırlama gibi iş akışları otomasyonla kötüye kullanılabilir. Her istek teknik olarak geçerli olsa bile binlerce kez tekrarlanması stok tüketimi, spam, sahte hesap veya mali kayıp oluşturabilir.
Test sırasında iş akışının adımları, tekrar kullanımı, sıra değişikliği ve otomasyona karşı kontrolleri incelenir. Koruma mekanizması seçilirken gerçek kullanıcı deneyimi ile iş riski birlikte değerlendirilir.
URL alan, dış kaynaktan dosya getiren veya webhook gönderen uçlarda sunucu taraflı istek sahteciliği (SSRF) senaryoları araştırılır. Hata ayrıntıları, CORS politikası, TLS kullanımı, güvenlik başlıkları ve gereksiz HTTP metotları gibi yapılandırmalar kontrol edilir.
Eski sürümler, test ortamları, unutulmuş alt alan adları ve belgede bulunmayan uçlar envanter riskini artırır. Desteklenmeyen bir API sürümü güncel sürümden daha zayıf doğrulama kullanabilir. Bu nedenle test, yalnızca paylaşılan belgeyle sınırlı kalmaz; izin verilen kapsam içinde istemci trafiği ve keşfedilebilir uçlar da incelenir.
Uygulamanın başka servislerden aldığı veriye otomatik olarak güvenip güvenmediği değerlendirilir. Üçüncü taraf yanıtları da kullanıcı girdisi gibi doğrulanmalı, zaman aşımı ve hata durumları güvenli yönetilmeli, yönlendirmeler ve dosyalar kontrol edilmelidir. Entegrasyon anahtarlarının istemciye veya günlük kayıtlarına sızmaması gerekir.
REST API'lerde kaynak adresleri, HTTP metotları, parametreler ve sürüm yolları uç bazında incelenir. Aynı kaynağın listeleme, görüntüleme, güncelleme ve silme işlemleri farklı yetkilendirme hataları barındırabilir. İçerik türü değiştirildiğinde veya beklenmeyen alanlar eklendiğinde doğrulamanın atlanıp atlanmadığı da sınanır.
GraphQL tek bir uç üzerinden çok sayıda sorgu ve mutasyon çalıştırabilir. Bu nedenle alan düzeyi yetkilendirme, sorgu derinliği, alias ve batching kullanımı, iç gözlem ayarları ve hata yanıtları önem kazanır. Şema görünürlüğünün kapatılması tek başına güvenlik sağlamaz; her resolver ilgili kullanıcı ve nesne için yetkilendirme yapmalıdır.
Her iki yaklaşımda da yalnızca başarılı yanıtlar değil; 4xx ve 5xx hata davranışları, gereksiz veri, önbellek, tekrar oynatma ve eş zamanlı istek senaryoları değerlendirilir.
Alan adları, API sürümleri, REST veya GraphQL uçları, kullanıcı rolleri ve üçüncü taraf entegrasyonlar belirlenir. Üretim ortamında uygulanmayacak yüksek yük senaryoları, hız sınırları ve acil iletişim yöntemi yazılı hale getirilir. Test verisi ile gerçek kullanıcı verisinin ayrılması planlanır.
OpenAPI/Swagger belgesi, Postman koleksiyonu, GraphQL şeması veya örnek istekler incelenir. Mobil ya da web istemcisinin ürettiği trafik gözlemlenerek belgede olmayan uçlar ve parametreler belirlenir. Her rol için erişilebilen işlevlerin matrisi çıkarılır.
Şema ve uçlar araçlarla taranır; ardından bulunan sonuçlar elle doğrulanır. Yetkilendirme testleri için nesne kimlikleri ve roller karşılaştırılır. İş akışları, belirteç yaşam döngüsü, girdi doğrulama, kaynak tüketimi ve entegrasyon güvenliği uygulamanın yapısına uygun senaryolarla sınanır.
Her doğrulanmış bulgu için etkilenen uç, gerekli rol, örnek istek ve yanıt, olası iş etkisi ve düzeltme önerisi hazırlanır. Hassas belirteçler ve kişisel veriler kanıtlarda maskelenir. Bulgular yalnızca genel şiddete göre değil, API'nin gerçek kullanım koşullarına göre önceliklendirilir.
Düzeltme tamamlandığında ilgili uçlar aynı ön koşullarla tekrar test edilir. Benzer uçlarda aynı kök nedenin devam edip etmediği kontrol edilir. Kapanan ve açık kalan bulgular doğrulama sonucu olarak rapora eklenir.
Yeni API canlıya çıkmadan önce, dış iş ortaklarına erişim verilmeden önce ve mobil uygulamanın önemli bir sürümü yayınlanırken test yapılması uygundur. Kimlik sağlayıcısı, yetki modeli, ödeme, dosya, webhook veya API gateway değişiklikleri sonrasında da kapsamlı kontrol gerekir.
API güvenliği tek seferlik bir faaliyet değildir. Yeni uçlar, eski sürümler ve entegrasyonlar saldırı yüzeyini sürekli değiştirir. NIST SP 800-228, API risklerinin geliştirme ve çalışma zamanı boyunca ele alınmasını, kontrollerin risk temelli ve aşamalı biçimde uygulanmasını önerir. Düzenli test; güvenli tasarım, kod incelemesi, merkezi günlükleme ve çalışma zamanı izleme ile birlikte düşünülmelidir.
Kaynak kod ve API uygulamasının birlikte incelenmesi gereken durumlarda kaynak kod güvenlik incelemesi, dışarıdan yapılan testi tamamlayarak veri akışlarının kök nedenini bulmayı kolaylaştırır.
Güncel API dokümantasyonu, örnek istek koleksiyonu ve her kullanıcı rolü için ayrı test hesabı çalışmayı hızlandırır. OAuth kullanılıyorsa istemci türleri, kapsamlar ve yönlendirme adresleri; GraphQL kullanılıyorsa şema ve örnek sorgular paylaşılmalıdır. Kritik iş akışları ve hassas veri alanları ayrıca belirtilmelidir.
Canlıya benzer bir test ortamı tercih edilir. Gerçek veri kullanılacaksa maskeleme, kayıt tutma ve kanıt paylaşım kuralları önceden belirlenmelidir. Hız ve kaynak tüketimi denemeleri için güvenli sınırlar kararlaştırılmalı, üçüncü taraf servislerde maliyet oluşturabilecek çağrılar açıkça işaretlenmelidir.
Etkili bir API güvenlik testi, yalnızca OpenAPI belgesini tarayıp hata listesi üretmez. Kullanıcıların, nesnelerin, veri alanlarının ve iş akışlarının birbirleriyle ilişkisini anlar; arayüzün göndermediği istekleri dener ve her bulgunun gerçek iş etkisini doğrular.
Betorbet Resmi Giriş aramasıyla ulaştığınız bu sayfa, BetOrBet Siber Güvenlik’in resmi API güvenlik testi hizmetidir. API türünüzü, kullanıcı rollerinizi ve hedeflediğiniz takvimi paylaşın; yazılı izin ve güvenli test sınırlarıyla uygun kapsamı birlikte oluşturalım.
Evet. Belgelerin yanında istemci uygulamasının trafiğini de inceleyerek belgede olmayan uçları kapsam içinde ararız.
API belgeleri ya da bir koleksiyon dosyası ve farklı yetki düzeylerinde en az iki test hesabı işimizi hızlandırır.
Tercihimiz canlıyla aynı yapılandırmaya sahip bir test ortamıdır. Canlıda çalışmamız gerekirse sınırları birlikte belirleriz.
Evet. Kapsam ve süre uygun olduğunda REST ve GraphQL uçlarını aynı çalışma içinde değerlendiririz. Her teknoloji için yetkilendirme, girdi doğrulama ve kaynak tüketimi senaryolarını ayrı uygularız.
Test planını güvenli sınırlar ve trafik limitleriyle hazırlarız. Yük veya maliyet oluşturabilecek senaryoları test ortamında ya da ayrıca onaylanan zaman aralığında kontrollü biçimde yürütürüz.
Diğer hizmetler
Web uygulama sızma testiyle yetkilendirme, oturum, enjeksiyon ve iş mantığı açıklarını gerçek saldırı senaryolarıyla belirliyor, düzeltme yolunu gösteriyoruz.
Kaynak kod güvenlik incelemesiyle veri akışı, yetkilendirme, gizli bilgi, kriptografi ve iş mantığı açıklarını satır referanslarıyla belirliyoruz.
Oltalama simülasyonuyla çalışanların şüpheli e-postaları fark etme ve bildirme davranışını güvenli, anonim ve kuruma özel senaryolarla ölçüyoruz.
Uygulamanızı ve beklentinizi birkaç cümleyle yazın; kapsamı birlikte netleştirelim.