API Testing

Kısa tanım

API testing; uygulamanın kullandığı veya arayüzün hiç kullanmadığı API yüzeyini çıkarma, her endpoint’in kabul ettiği metotları, parametreleri, veri biçimlerini, kimlik doğrulama ve yetkilendirme kurallarını inceleme sürecidir. Amaç yalnız endpoint bulmak değil, geçerli bir isteğin nasıl kurulduğunu ve güvenlik kontrollerinin her işlemde tutarlı uygulanıp uygulanmadığını anlamaktır.

Yetkili kullanım

Aşağıdaki aktif testleri yalnız PortSwigger Web Security Academy gibi bilerek zafiyetli laboratuvarlarda veya açıkça yetkilendirildiğin sistemlerde uygula. Metot fuzzing, endpoint keşfi ve toplu parametre denemeleri veri değiştirebilir veya çok sayıda kayıt oluşturabilir. Üretim benzeri ortamlarda düşük değerli test nesneleri ve düşük istek hızı kullan.

1. Zihinsel Model

Bir API yüzeyini şu bileşenlerle düşün:

flowchart LR
    A[Dokümantasyon ve trafik] --> B[Endpoint envanteri]
    B --> C[Metot ve content type]
    C --> D[Parametre ve nesne alanları]
    D --> E[Kimlik doğrulama ve yetkilendirme]
    E --> F[İş mantığı ve sürüm farkları]
    F --> G[Kanıtı doğrula ve kaydet]

2. API Recon

Recon sırasında her endpoint için en az şunları öğren:

• Zorunlu ve isteğe bağlı girdiler.
• Path, query, header, cookie ve body parametreleri.
• Desteklenen HTTP metotları.
• Kabul edilen medya biçimleri ve Content-Type değerleri.
• Kimlik doğrulama mekanizması ve token kapsamı.
• Nesne ve işlev düzeyindeki yetkilendirme davranışı.
• Rate limit’in hangi anahtara göre uygulandığı.
• API sürümü, hata biçimi ve önemli yan etkiler.

Basit örnek:

GET /api/books HTTP/1.1
Host: example.com

Buradaki endpoint /api/books’tur. /api/books/mystery ise aynı kaynağın farklı bir alt koleksiyonu veya filtresi olabilir. Yalnız URL’yi bilmek yetmez; geçerli istek kurabilmek için metot, parametre, kimlik doğrulama ve veri biçimi de belirlenmelidir.

Endpoint envanteri şablonu

3. API Dokümantasyonunu Bulma

Dokümantasyon iki biçimde görülebilir:

• İnsan tarafından okunabilir: Açıklamalar, örnekler ve kullanım senaryoları içerir.
• Makine tarafından okunabilir: OpenAPI gibi JSON/YAML tabanlı şemalardır; araçlarla parse edilebilir.

Dokümantasyon herkese açıksa recon’a buradan başla. Açıkça bağlantılanmamışsa uygulama trafiğini ve yaygın yolları incele:

/api
/swagger/index.html
/openapi.json

Bir resource endpoint’i bulunduğunda üst dizinlere doğru ilerle:

/api/swagger/v1/users/123
→ /api/swagger/v1
→ /api/swagger
→ /api

Tip

Dokümantasyon ile gerçek trafiği birlikte değerlendir. Dokümantasyon eski olabilir; JavaScript dosyaları ve çalışan uygulama, dokümante edilmemiş veya artık kullanılmıyor görünen endpoint’leri açığa çıkarabilir.

Makine tarafından okunabilir şema bulunduğunda:

• Endpoint, parametre, şema, örnek ve güvenlik tanımlarını çıkar.
• Burp Scanner ile JSON/YAML/OpenAPI içeriğini crawl ve audit et.
• OpenAPI Parser BApp ile şemayı Burp içine aktar.
• Gerekirse Postman veya SoapUI ile belgelenmiş istekleri yeniden üret.

4. Endpoint Keşfi

Uygulama trafiği

1. Uygulamayı Burp’ın tarayıcısıyla normal kullanıcı gibi dolaş.
2. Proxy HTTP history ve site map içinden /api/ benzeri yolları ayır.
3. XHR/fetch çağrılarını, form gönderimlerini ve arka plan isteklerini incele.
4. Her isteğin auth bilgisi, kaynak kimliği, parametreleri ve yan etkisini kaydet.

JavaScript dosyaları

Front-end’in henüz tetiklemediğin endpoint’leri JavaScript içinde bulunabilir. Manuel aramanın yanında Burp crawl ve daha kapsamlı çıkarım için JS Link Finder BApp kullanılabilir.

Aranabilecek işaretler:

/api/
fetch(
axios.
XMLHttpRequest
baseURL
swagger
openapi
v1 / v2 / internal

Gizli endpoint’ler

Bilinen bir yolu isimlendirme kalıbı olarak kullan:

PUT /api/user/update HTTP/1.1

Intruder payload konumunu işlev adına yerleştir:

/api/user/§update§

Wordlist’e genel API terimlerinin yanında uygulamaya özgü kelimeler de ekle: add, delete, remove, archive, export, admin, ürün veya iş alanı terimleri gibi. Sonuçları yalnız statü koduyla değil; gövde uzunluğu, içerik ve yönlendirme farklarıyla karşılaştır.

5. Endpoint ile Etkileşim

Önce normal isteği Repeater’a gönder ve değişiklik yapmadan yeniden yollayarak kararlı bir baseline elde et. Sonra her seferinde tek değişkeni değiştir.

HTTP metotları

Bir path birden fazla işlev taşıyabilir:

GET /api/tasks HTTP/1.1
POST /api/tasks HTTP/1.1
DELETE /api/tasks/1 HTTP/1.1

Pratik sıra:

1. Normal metodu ve yanıtı kaydet.
2. OPTIONS ile sunucunun bildirdiği metotları kontrol et.
3. Burp Intruder’ın HTTP verbs listesini kullanarak olası metotları kontrollü biçimde dene.
4. Allow header’ı, statü kodu, hata gövdesi ve gerçekleşen yan etkiyi birlikte değerlendir.
5. PATCH, PUT, POST ve DELETE testlerinde kritik olmayan kendi test nesneni kullan.

Danger

Metot değişikliği yalnız keşif değildir; kayıt oluşturabilir, güncelleyebilir veya silebilir. Hedef olarak düşük önemde ve sana ait bir test nesnesi seç.

Content type

Bir endpoint farklı parser’larda farklı davranabilir. Content-Type header’ını değiştirirken body’yi de yeni biçime uygun dönüştür:

Content-Type: application/json

{"name":"test"}

Content-Type: application/xml

<user><name>test</name></user>

Farklı content type denemeleri:

• Ayrıntılı parser hataları üretebilir.
• Yalnız bir parser’da uygulanan savunmayı atlatabilir.
• JSON yolunda olmayan fakat XML yolunda bulunan injection sınıflarını açığa çıkarabilir.

Burp Content Type Converter BApp, JSON ve XML arasında dönüşümü hızlandırabilir.

Hata mesajlarını okuma

Hata mesajı şu bilgileri sızdırabilir:

• Doğru parametre veya alan adı.
• Beklenen veri tipi.
• Kabul edilen Content-Type.
• Geçerli route ve API sürümü.
• Dahili endpoint yapısı.

Bir hata mesajını zafiyet kanıtı sayma. Onu hipotez üretmek için kullan; geçerli ve geçersiz kontrol istekleriyle davranışı doğrula.

6. Gizli Parametreleri Bulma

Kaynaklar:

• GET yanıtlarında bulunan fakat güncelleme isteğinde görünmeyen alanlar.
• JavaScript içindeki model veya property adları.
• OpenAPI şemaları ve örnek yanıtlar.
• Burp Intruder parametre wordlist’leri.
• Param Miner BApp.
• Burp Content Discovery.

Test yaklaşımı:

1. Normal isteği ve yanıtı kaydet.
2. Aday parametreyi zararsız/geçerli bir değerle ekle.
3. Aynı parametreyi kasıtlı olarak yanlış tipte bir değerle gönder.
4. Statü, hata metni, yanıt gövdesi ve durum değişikliğini karşılaştır.
5. Parametrenin gerçekten işlendiğini bağımsız bir GET isteği veya arayüz davranışıyla doğrula.

7. Mass Assignment

Mass assignment veya auto-binding, framework’ün istek alanlarını doğrudan dahili nesne alanlarına bağlamasıdır. Güncelleme için tasarlanmamış bir nesne alanı da istemeden kullanıcı kontrollü hâle gelebilir.

Tespit

İzin verilen güncelleme isteğini, aynı nesnenin GET yanıtıyla karşılaştır:

PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "username": "wiener",
  "email": "wiener@example.com"
}

1
{
2
  "id": 123,
3
  "name": "John Doe",
4
  "email": "john@example.com",
5
  "isAdmin": false
6
}

GET yanıtındaki id ve isAdmin, güncelleme isteğinde görünmeyen aday alanlardır. Adayın işlendiğini önce güvenli kontrollerle ölç:

1
{"username":"wiener","email":"wiener@example.com","isAdmin":false}

1
{"username":"wiener","email":"wiener@example.com","isAdmin":"foo"}

Geçersiz tip farklı bir hata üretirken geçerli tip kabul ediliyorsa alanın binding işlemine girdiğine dair güçlü bir işaret oluşur. Yetkili labda etkisi, değer değiştirildikten sonra ayrı bir GET veya yeni yetkiye erişim ile doğrulanır.

Savunma

• Kullanıcının güncelleyebileceği alanları allowlist ile tanımla.
• isAdmin, role, ownerId, price, credit, discount gibi hassas alanları istemci modelinden ayır.
• DTO/view model kullan; veritabanı nesnesini doğrudan bind etme.
• Yetki kontrolünü alan bazında ve sunucu tarafında uygula.

8. Server-Side Parameter Pollution (SSPP)

SSPP, uygulamanın kullanıcı girdisini yeterli encoding olmadan sunucu tarafında yaptığı başka bir API isteğine eklemesidir. Saldırgan dahili isteğe parametre ekleyebilir, mevcut parametreyi geçersiz kılabilir veya path’i değiştirebilir.

Note

Bu konu bazen HTTP parameter pollution olarak da adlandırılır; WAF bypass bağlamındaki aynı isimle karıştırma. Server-side prototype pollution ile de aynı zafiyet sınıfı değildir.

8.1 Query string testi

Ön uç isteği:

GET /userSearch?name=peter&back=/home HTTP/1.1

Olası dahili istek:

GET /users/search?name=peter&publicProfile=true HTTP/1.1

Kontrollü test sırası:

# karakteri dış istekte mutlaka %23 olarak encode edilmelidir; aksi hâlde tarayıcı bunu fragment olarak yorumlar ve sunucuya göndermez.

Tekrarlanan parametrelerin işlenmesi teknolojiye göre değişebilir. PortSwigger’ın örneğinde PHP son değeri, Node.js/Express ilk değeri kullanabilir; ASP.NET ise değerleri birleştirebilir. Gerçek hedefte parser davranışını kontrollü karşılaştırmalarla belirle.

8.2 REST path testi

Ön uç:

GET /edit_profile.php?name=peter HTTP/1.1

Olası dahili istek:

GET /api/private/users/peter HTTP/1.1

Path traversal dizisiyle kullanıcının path içine yerleştirilip yerleştirilmediği sınanabilir:

GET /edit_profile.php?name=peter%2f..%2fadmin HTTP/1.1

Back-end path’i normalize ederse sonuç /api/private/users/admin olabilir. ./, ../, URL-encoded /, ? ve # denemelerinde her seferinde tek öğeyi değiştir; hata mesajları route sınırını ve normalizasyon davranışını gösterebilir.

8.3 Yapılandırılmış veri testi

Ön uç form verisi arka tarafta JSON içine güvenli encoding olmadan gömülüyorsa:

POST /myaccount HTTP/1.1
Content-Type: application/x-www-form-urlencoded

name=peter","access_level":"administrator

Olası dahili gövde:

1
{"name":"peter","access_level":"administrator"}

Aynı risk JSON veya XML girdilerinde ve cevap oluşturulurken de bulunabilir. Amaç rastgele sözdizimi bozmak değil; dış girdinin ikinci bir yapılandırılmış bağlama nasıl gömüldüğünü kontrollü hata ve davranış farklarıyla anlamaktır.

8.4 Otomasyon

• Burp Scanner, girdinin dönüştürülüp yeniden işlendiği şüpheli akışları işaretleyebilir.
• Backslash Powered Scanner BApp girdileri boring, interesting veya vulnerable biçiminde sınıflandırabilir.
• Otomatik bulgu tek başına kanıt değildir; interesting sonuçları manuel olarak tekrar üret ve etkisini doğrula.

8.5 Savunma

• Dahili istekleri string birleştirme ile kurma; güvenli URL/JSON/XML builder kullan.
• Encoding gerektirmeyen karakterleri dar bir allowlist ile tanımla, geri kalan girdiyi bağlama uygun encode et.
• Girdinin beklenen format ve yapıya uyduğunu doğrula.
• Dahili API’de de bağımsız kimlik doğrulama ve yetkilendirme uygula.
• Ayrıntılı dahili route ve parser hatalarını kullanıcıya döndürme.

9. API Güvenlik Kontrol Listesi

Recon

• İnsan ve makine tarafından okunabilir dokümantasyon arandı.
• Base path’ler ve eski API sürümleri kontrol edildi.
• Tarayıcı trafiği, JavaScript dosyaları ve arka plan istekleri incelendi.
• Endpoint envanterine auth, metot, parametre, content type ve yan etki yazıldı.

Etkileşim

• Baseline istek ve yanıt kaydedildi.
• Desteklenen HTTP metotları düşük etkili nesnede denendi.
• Kabul edilen content type’lar uygun body dönüşümüyle karşılaştırıldı.
• Hata mesajlarından çıkan hipotezler pozitif ve negatif kontrollerle doğrulandı.
• Rate limit ve kimlik doğrulama davranışı kaydedildi.

Yetkilendirme ve iş mantığı

• Farklı kullanıcı/rol ile nesne düzeyi yetkilendirme kontrol edildi.
• Yönetim veya kritik işlevlerde işlev düzeyi yetkilendirme kontrol edildi.
• GET yanıtındaki alanlar yazma istekleriyle karşılaştırıldı.
• Mass assignment adayları geçerli/geçersiz tip karşılaştırmasıyla incelendi.
• Eski ve yeni API sürümlerinin aynı güvenlik kontrollerine sahip olduğu doğrulandı.

Server-side zincirler

• Query string içinde encode edilmiş #, & ve = davranışı incelendi.
• REST path normalizasyonu kontrollü olarak test edildi.
• Kullanıcı girdisinin JSON/XML gibi ikinci bir bağlama gömülüp gömülmediği incelendi.
• Otomatik bulgular manuel olarak tekrar üretildi.

10. Sık Yapılan Hatalar

• Yalnız dokümantasyona güvenip gerçek uygulama trafiğini incelememek.
• Yalnız GET ve POST denemek; aynı path’in PATCH veya DELETE davranışını kaçırmak.
• Header’ı değiştirip body’yi yeni Content-Type biçimine dönüştürmemek.
• Yalnız HTTP statü koduna bakmak; response body ve gerçek durum değişikliğini doğrulamamak.
• Ayrıntılı bir hatayı doğrudan zafiyet saymak.
• Mass assignment testinde sonucu ayrı bir GET/arayüz kontrolüyle doğrulamamak.
• # karakterini encode etmeden göndermek.
• Eski API sürümlerini ve kullanılmayan endpoint’leri kapsam dışı sanmak.
• Yetkisiz aktif testte kritik kayıtlar üzerinde metot fuzzing yapmak.

Akılda Kalacak Özet

Summary

• Önce endpoint’i değil, tüm sözleşmeyi çıkar: metot, parametre, veri biçimi, auth, yetki ve yan etki.
• Dokümantasyon, trafik ve JavaScript birbirini tamamlayan üç ana keşif kaynağıdır.
• Aynı path farklı HTTP metotlarında tamamen farklı ve daha kritik işlevlere sahip olabilir.
• GET yanıtında görünüp yazma isteğinde bulunmayan alanlar mass assignment için güçlü adaylardır.
• SSPP’de dış girdinin dahili query, REST path veya yapılandırılmış veri içine nasıl gömüldüğünü anlamaya çalış.
• Hata mesajı bir ipucudur; başarı kanıtı ayrı bir durum kontrolü veya beklenen işlevsel sonuçtur.
• Eski sürümler ve arayüzün kullanmadığı endpoint’ler de üretim saldırı yüzeyinin parçasıdır.

Kaynaklar

1. PortSwigger Web Security Academy — API testing↩︎↩︎↩︎↩︎↩︎↩︎
2. PortSwigger Web Security Academy — Server-side parameter pollution↩︎↩︎↩︎↩︎