API Güvenlik Testi: Kapsam Matrisi, BOLA ve Gerçek Sayılar

API güvenlik testi, daha uzun bir kelime listesiyle çalıştırılan bir tarama değildir. Kimin, hangi nesne üzerinde, hangi işlemi yapabileceğine dair iddiaların, sayılabilir bir envanter üzerinde tek tek sınanmasıdır. API ihlallerine yol açan hatalar nadiren egzotiktir: nesne kimliğini alıp sahipliğini kontrol etmeden o nesneyi döndüren bir uç nokta, imzası veya hedef kitlesi hiç doğrulanmamış bir token, tüm kiracıların satırlarını döndüren bir liste uç noktası, hesap başına sınırı olmayan altı haneli bir tek kullanımlık kod ve işlem sınırı olmayan bir durum değişikliği. Bunların hepsi iki hesapla ve bir betikle test edilebilir. Çoğu projede eksik olan şey araç değil, aritmetiktir: kaç doğrulama çalıştırıldı, kaç uç noktaya karşı, kaç rolle ve test başlamadan önce envanterde gerçekte ne vardı.

Test, arkasındaki envanter kadar iyidir

Hiç kimsede olmayan sayıyla başlayın. Akamai'nin 2026 API Güvenlik Etki Araştırması, on ülkeden 1.840 güvenlik yöneticisi ve uygulayıcısıyla yapıldı ve katılımcıların yüzde 87'sinin son on iki ayda en az bir API kaynaklı güvenlik olayı yaşadığını ortaya koydu; bu oran 2022'de yüzde 76'ydı. Aynı araştırma, katılımcıların yüzde 77'sinin eksiksiz bir API envanterine sahip olduğunu iddia ettiğini, ancak bunların yalnızca yüzde 23'ünün hangi API'lerin hassas veri döndürdüğünü bildiğini gösteriyor - ve bu oran dört yıldır yükselmek yerine düşüyor. Keşif çalışmaları da aynı yönü işaret ediyor: Cloudflare'in makine öğrenmesi tabanlı uç nokta keşfi, kurumların kendi katalogladığından yaklaşık yüzde 31 daha fazla API uç noktası buldu.

Bu fark, her API testinin ilk bulgusudur ve tek bir istek gönderilmeden önce ölçülebilir. Yalnızca OpenAPI belgesinde yazanları test ederseniz, birinin belgelemeyi hatırladığı yüzeyi test edersiniz; bu da normalde en dikkatli geliştirilen kısımdır.

Dört listeyi tek bir tabloda birleştirin; her satır bir uç nokta ve yöntem olsun: rota, kimlik doğrulama şeması, nesne kimliğinin yol, sorgu veya gövdede geçip geçmediği, döndürdüğü verinin sınıfı, herkese açık olup olmadığı ve sahibi olan ekip. Test bu tabloya göre ölçülür. Aynı zamanda müşterinin sonradan soracağı sorunun tek dürüst cevabı da budur: API'm test edildi mi, yoksa bir örneği mi test edildi?

Asıl bulgu yetkilendirmede, ve hiçbir tarayıcı onu bulamaz

Nesne düzeyinde bozuk yetkilendirme (BOLA), OWASP API Güvenlik İlk 10 listesi oluşturulduğundan beri ilk sırada ve bunun yapısal bir nedeni var: API sizin kim olduğunuzu doğrular, ardından bu nesnenin size ait olup olmadığını kontrol etmeyi atlar. Bir tarayıcının bunu bulması imkânsızdır; çünkü bulmak için iki geçerli kimlik ve her biri için geçerli bir nesne kimliği gerekir. Tarayıcı 401 veya 403 görür ve yoluna devam eder; savunmasız uç nokta ise yalnızca gerçek bir kullanıcı, kendisine ait olmayan gerçek bir nesneyi istediğinde 200 döner.

Testin kendisi eski ve sıkıcıdır, ve işe yarar. Aynı rolde iki hesap oluşturun. A hesabıyla bir nesne oluşturun ve yanıttan kimliğini alın. B hesabıyla o kimliği isteyin. Doğru kurulmuş bir API 403, varlığı açıklamak istemiyorsa 404 döner. Savunmasız olan 200 ve A'nın verisini döndürür. Bu bölümün geri kalanı, aynı testin insanların tekrarlamayı unuttuğu yerlerde tekrarlanmasıdır.

Çok kiracılı bir üründe kiracı kimliği doğrulanmış tokendan gelmeli, istekten asla okunmamalıdır. Yalnızca tek kiracı içinde nesne kimliği değiştiren bir test, kiracılar arası okuma açıkken geçer; bu yüzden iki hesap farklı kullanıcı olduğu kadar farklı kiracıda da olmalıdır. İlgili tuzak kimlik biçimidir: rastgele UUID'ler numaralandırmayı yavaşlatır ama kontrolün yerini almaz, çünkü başka bir uç nokta, dışa aktarma, e-posta veya günlük tarafından açığa çıkarılan bir kimlik de aynı şekilde tekrar oynatılabilir.

Düzeltmenin nasıl göründüğü rapor için önemlidir. Her işleyicinin geçmek zorunda olduğu tek bir paylaşılan katmana konan yetkilendirme kontrolü bir hata sınıfını kapatır. Başarısız olan işleyiciye eklenen kontrol bir uç noktayı kapatır ve bir sonraki sürümün aynı deseni yeniden keşfetmesini bekler. Hangisini önerdiğinizi yazın; bulgunun gelecek yılki testte tekrar etmesinin nedeni bu farktır.

Kapsam matrisi: "her uç noktayı test et" cümlesini bir sayıya çevirmek

Her kontrol listesi aynı şeyi söyler ve orada durur: her nesne kapsamlı uç noktayı iki hesapla test et. Kimse bu cümleyi işe çevirmez; bu yüzden aynı API üzerinde iki çalışma, gerçekte yapılan iş bakımından on kat farklı olabilir. Bunun yerine aritmetiği yapın.

Nesne referansı alan uç noktaları sayın; yol, sorgu, gövde veya başlık fark etmez. Buna E diyelim. Test edebileceğiniz kimlikleri sayın: iki farklı kiracıda iki sıradan kullanıcı, ikinci role sahip bir kullanıcı, bir yönetici ve kimlik doğrulamamış çağıran. Buna R diyelim. Yetkilendirme yüzeyi E çarpı R'dir ve her hücre iki istektir: çağıranın kendi nesnesi başarılı olmalı, yabancı nesnenin kimliği başarısız olmalıdır. Nesne kimliği alan 70 uç noktası olan 120 uç noktalı bir API, dört kimlikle test edildiğinde 280 doğrulama ve 560 istek demektir.

Bu sayı üç işi görür. İşi ve dolayısıyla fiyatı boyutlandırır, müşteriye başka bir tedarikçinin teklifiyle karşılaştırabileceği bir payda verir ve yeniden teste bir taban çizgisi sağlar: aynı betik tekrar çalıştığında geçen veya kalan 280 satır üretir. Payda söyleyemeyen bir tedarikçiden betiği isteyin; kapsam odur.

Örnekleme meşrudur, ama rastgele değil bilinçli olmalıdır. Boyuttan bağımsız olarak her örnekte bulunmayı hak eden üç sınıf vardır: en yeni uç noktalar (en az gözden geçirilmiş), en eski uç noktalar (en az bakım görmüş) ve yönetim ile iş ortağına bakan uç noktalar (en az kullanıcı ve dolayısıyla en az hata bildirimi). Olgun bir API üzerinde rastgele örnek, çoğunlukla başkasının zaten bulduğu hataları yeniden test eder.

403 mü 404 mü kararı, koruduğundan fazlasını sızdırır

Yabancı bir nesne için 403 ile 404 arasındaki seçim çoğu rehberde zevk meselesi gibi ele alınır. Ölçülebilir sonucu olan bir ürün kararıdır ve testi ucuzdur: A'ya ait var olan bir nesnenin kimliğini ve hiç var olmayan bir kimliği alın, ikisini de B olarak isteyin. Durum kodunu, yanıt gövdesini, hata metnini, başlıkları ve gecikmeyi karşılaştırın.

Var olan nesne 403, olmayan nesne 404 döndürüyorsa API az önce yetkisiz bir çağırana varlığı doğrulamıştır. Sıralı kimliklerde bu, başarısız bir yetkilendirme kontrolünü bir numaralandırma kaynağına çevirir: saldırgan nesne uzayının boyutunu, büyüme hızını ve hangi kimliklerin canlı olduğunu öğrenir, tek biri için yetkili olmadan. Gerekçe "kendi nesnesini başka hesaptan yer imlerine eklemiş meşru kullanıcı için 403 daha iyi deneyim" ise çözüm kararı rota bazında verip belgelemektir, işleyici bazında ve tutarsız değil.

Yük göndermeden yapılabilecek token testleri

Kimlik doğrulama katmanı API olaylarının ikinci büyük payını üretir ve hataları sömürü aracıyla değil bir metin düzenleyiciyle ve tekrar oynatma ile test edilebilir. Wallarm'ın 2026'da açıklanmış API ihlalleri analizi bunların yüzde 52'sini bozuk kimlik doğrulamaya, yüzde 27'sini üçüncü taraf API'lerin güvensiz kullanımına bağladı ve katalogladığı API güvenlik açıklarının çoğunluğuna hiç kimlik doğrulamadan erişilebildiğini not etti. Bu oranları doğa yasası değil, hataların nerede kümelendiğinin tarifi olarak okuyun; işe yarayan kısım aşağıdaki listedir.

API anahtarları en çok verilen ve en az yönetilen kimlik bilgisi olduğu için kendi dört sorusunu hak eder: anahtar hangi kapsamı taşıyor, ne zaman sona eriyor, kim döndürebiliyor ve istemcide nerede saklanıyor? Mobil uygulamaya gömülü bir anahtar, belge ne derse desin genel bir anahtardır. Süresi olmayan ve anahtar başına hız sınırı bulunmayan bir anahtar kalıcı ve ölçülmeyen bir kimlik bilgisidir; rapor da bunu böyle anlatmalıdır.

Kütle atama: hiç kabul etmek istemediğiniz alan

Nesne düzeyinde bozuk yetkilendirmeyi üreten aynı eksik kontrol, kütle atamaya da yol açar: işleyici istek gövdesini modelin üzerine bağlar, böylece istemcinin gönderdiği her alan veritabanına yazılan bir alan olur. Test tek istektir. Kendi nesnenizi güncelleyen bir uç nokta alın, her seferinde bir ayrıcalıklı alan ekleyin ve yanıtı izleyin.

Kalıcı çözüm, uç nokta başına iki izin listesidir - role göre yazılabilir alanlar ve role göre okunabilir alanlar - ve bunlar modelden üretilmek yerine rota tanımının yanında tutulmalıdır. Çerçeve düzeyindeki "doldurulabilir" haritaları birinin sütun eklemesiyle kayar ve bu kayma, bir test onu sayana kadar görünmez.

İş mantığı: yükü değil aritmetiği test edin

Kontrol listesi odaklı test, numaralandırma biçimindedir: değiştirilecek kimlik ve bulanıklaştırılacak parametre arar. Para kaybettiren hatalar aritmetik biçimindedir ve test edenin neyin doğru kalması gerektiğini bilmesini gerektirir. Önce değişmezleri yazın; sonra her biri bir testtir.

Altı değişmez ticaret ve iş akışı API'lerinin çoğunu kapsar. Para korunur: satır toplamı genel toplama eşittir ve iadeler ödemeleri aşmaz. Miktarlar negatif değildir ve ürünün gerektirdiği yerde tam sayıdır. Bir indirim bir kez kullanılır, kurallar izin vermiyorsa üst üste binmez ve promosyonun hariç tuttuğu kategoriye uygulanmaz. Durum makinesi yalnızca ileri ve yalnızca izin verilen kenarlardan gider: ödeme öncesi hiçbir şey sevk edilmez, bir sipariş iki kez iade edilmez, iptal edilmiş bir sipariş eski bir isteğin tekrar oynatılmasıyla yeniden açılmaz. Kotalar ve lisans sayıları sunucuda uygulanır, düğmeyi gizleyen istemcide değil. Zaman pencereleri işlem anında uygulanır: dün sona ermiş bir deneme, deneme sırasında alınmış bir token tutularak bugün kullanılamaz.

İki örnek bu sınıfın neden hiçbir tarayıcı raporunda görünmediğini gösterir. Negatif tutarı kabul eden bir iade uç noktası, iadeyi bir tahsilata veya tersini çevirir; hangisi olduğu doğrulamanın işaretin hangi tarafına yazıldığına bağlıdır. Siparişi geçersiz kılarken stoğu yine de düşen bir sıfır miktarı, defterle depo arasında kalıcı bir uyumsuzluk yaratır - hata yok, uyarı yok, sadece üç hafta sonra tutmayı bırakan bir sayı. İkisi de enjeksiyon gibi görünmez; ikisi de işin beklediği aritmetiği bilen bir testçi tarafından bulunur.

Tekrarlanabilirlik de buraya aittir. Aynı ödeme veya kullanım isteğini aynı idempotency anahtarıyla iki kez gönderin ve tek etki bekleyin; anahtarsız iki kez gönderdiğinizde API kopyayı çalıştırmak yerine reddetmelidir. Zaman aşımında yeniden deneyen bir istemci normal davranıştır ve idempotency olmayan bir API bu normal davranışı çift tahsilata çevirir.

Hız sınırları, anahtar uzayı aritmetiği ve sınırı olması gereken uç noktalar

"Hız sınırı uygulayın" cümlesi çoğu API rehberindeki en az uygulanabilir cümledir. Sınırlar iki farklı şeyi bağlar - tahmin edilebilir sırlar ve pahalı iş - ve bunlara ihtiyaç duyan uç noktalar aynı değildir. Birinci sınıf için soyut saniye başına istek tartışması yapmak yerine aritmetiği hesaplayın.

IP başına anahtarlama, saldırganla ilgisi olmayan bir nedenle başarısız olur. Mobil operatörler binlerce aboneyi tek bir taşıyıcı düzeyi NAT adresi arkasına koyar; kurumsal ağlar da aynısını bir vekil üzerinden yapar. Saldırıyı bağlayan bir sınır aynı zamanda meşru kullanıcıların anlamlı bir bölümünü yoğun saatte bloke eder, böylece ekipler sınırı hiçbir şeyi bağlamayana kadar yükseltir. Çalışan anahtarlar tokendaki kimlik, işlem yapılan hesap ve API anahtarıdır; IP, kimlik doğrulaması olmayan uç noktalar için tamamlayıcı bir işarettir, birincil kontrol değil.

Her kimlik bilgisi ve her pahalı uç nokta için beş şeyi test edin. Kimlik için bir sınır var mı. Giriş, tek kullanımlık kod, parola sıfırlama ve davet kabulünde hesap için daha sıkı ikinci bir sınır var mı. Sınır başarıları değil başarısızlıkları sayıyor mu. Aşıldığında yeniden deneme ipucuyla 429 dönüyor mu, yeniden deneme fırtınasını büyüten bir 500 değil mi. Ve pahalı uç noktalar - arama, rapor üretimi, görsel dönüştürme, toplu dışa aktarma - istek yerine maliyete göre sınırlanıyor mu; çünkü 400 sütunlu bir dışa aktarmaya yapılan tek istek bir aramayla karşılaştırılamaz.

GraphQL, webhook ve dosya yükleme: kontrol listesinin unuttuğu yüzeyler

GraphQL testin mantığını değil biçimini değiştirir. Üretimde introspection genellikle kapalıdır ve bu kimseyi durdurmaz: hata mesajlarındaki alan önerileri ("şunu mu demek istediniz") şemayı tek tahminde numaralandırır ve istemci paketi genellikle ürünün gerçekte kullandığı işlemleri içerir. Test aynı yetkilendirme testidir, ama dikkatli olunmazsa yanlış katmana uygulanır - nesne düzeyindeki kontrol çözümleyicide veya veri katmanında olmalıdır, çünkü kiracı üyeliğini kontrol eden bir üst alan alttaki iç içe seçimi korumaz.

Toplu işleme (batching), GraphQL'in hız sınırlarını aşma biçimidir ve adıyla anılmayı hak eder. Tek bir HTTP isteği, her biri ayrı bir çözümleyici çağrısı olarak çalışan yüzlerce takma adlı işlem taşıyabilir. HTTP isteklerini sayan bir sınır bir görür; veritabanı beş yüz görür. Test, yüzlerce takma adlı giriş denemesi veya nesne araması içeren bir istektir ve sonuç ya tek bir hız sınırı yanıtıdır ya da yanıt demeti. Önlem, ayrıştırılmış sorgudan hesaplanan maliyet sınırları, kalıcı sorgular veya işlem izin listesi ve azami sorgu derinliğidir - uç noktanın önündeki istek sayacı değil.

Yarış koşulları ve iki istek testi

Kontrol et-sonra-yap dizisi sıralı çalıştığında doğru, paralel çalıştığında yanlıştır; bu yüzden kod incelemesinden, birim testlerinden ve işleyiciyi baştan sona okuyan bir güvenlik incelemesinden geçer. Test, durum değiştiren bir uç noktaya aynı anda gönderilen iki aynı istektir: hediye kartı kullanma, bakiye çekme, bir sınıftaki son kontenjanı alma, tek seferlik teslim yuvasını kapma. Bir istek başarılı olmalı, diğeri reddedilmelidir; iki başarı bakiye iki kez harcandı demektir.

Bunun kod incelemesi yerine API testine ait olmasının nedeni, hatanın tek bir işleyicide görünmemesidir: eksik olan bir işlem sınırı veya benzersiz kısıttır. Çözüm de aynıdır - ikinci isteğin karşılayamayacağı bir veritabanı kısıtı veya koşullu güncelleme, artı istekte bir idempotency anahtarı - ve uygulama düzeyinde bir kilit değil, çünkü o kilit tek örnekte çalışır ve ikinci örnekte çalışmaz. Müşteri süreç içi bir mutex'in neden yetmediğini sorduğunda cevap dağıtım şemasıdır.

Üretimi bozmadan yıkıcı testler yürütmek

Çoğu API testi, test edilen sistem için risk yerine kontrol listesine göre sıralanır; bir silme testinin öğleden sonra dörtte gerçek bir müşterinin kaydına denk gelmesinin nedeni budur. İşi etki alanına göre sıralayın ve bu sıralamayı kapsam belgesinin parçası yapın.

Rehberlerin çoğunda eksik olan diğer disiplin kanıtın kendisiyle ilgilidir. Bir test, kişisel veri içeren bir kayda erişimi kanıtlıyorsa isteği, durum kodunu, etkilenen kayıt sayısını ve alan adlarını kaydedin; bulgunun tekrar üretilebilmesi için bir örnek değeri özetleyin; sonra gövdeyi silin. Bir bulguyu kanıtlamak için müşteri faturasının ekran görüntüsünü almak, güvenlik testini veri koruma olayına çevirmenin yoludur ve arkasından denetim geldiğinde bir avukatın soracağı ilk soru budur. Türkiye'de KVKK, Avrupa'da GDPR aynı ilkeyi ister: asgari tut, yalnızca kanıt için gerekeni sakla.

Otomasyonun kanıtlayabildiği ve kanıtlayamadığı

Dürüst ayrım, araç listesinden daha önemlidir; çünkü olgun bir programda en sık görülen hata, hattın API'yi kapsadığına inanan müşteridir. Otomatik kontroller dört şeyde gerçekten iyidir: taşıma ve başlık yapılandırması, bilinen güvenlik duyurularına karşı bağımlılık sürümleri, spesifikasyon uygunluğu (hiç güvenlik şeması bildirmeyen uç noktaları veya yetkilendirme başlığını gölgeleyen parametreleri yakalayan bir denetleyici) ve 500'leri bulguya çeviren şema bulanıklaştırma. Bu dördünün hiçbiri ihlallerin olduğu yer değildir.

Nesne yetkilendirmesini bulamazlar, çünkü tarayıcının geçerli kimliği ve ikinci bir kimliği yoktur. İş mantığını bulamazlar, çünkü değişmez işin kendisinde, şemada değildir. Zincirlenmiş akışları bulamazlar; tek tek zararsız üç uç nokta birleşerek ayrıcalık yükseltmesine dönüşebilir. Yarış koşulunu bulamazlar ve tek bir meşru görünen toplu istek olarak gelen hız sınırı aşımını da bulamazlar.

Otomatikleştirilebilen şey, çoğu ekibin beklediğinden daha dar ve daha değerlidir: yetkilendirme matrisinin kendisi. Rol başına iki önceden oluşturulmuş hesapla çalışan, her dağıtımda hazırlık ortamına karşı koşan ve yabancı bir kimliğin 403 veya 404 döndürdüğünü, çağıranın kendi kimliğinin 200 döndürdüğünü doğrulayan bir betik. Kritik her uç nokta bir satır alır, betik hesaplar arası 200'de derlemeyi düşürür ve ekip aynı hatayı yeni işleyicilerde yeniden üretmeyi bırakır. Eğilim çizgisini değiştiren tek kontrol budur ve elle bulunan bir bulgunun kapalı kalmasını sağlayan yeniden test artefaktı da budur.

Raporlama: önem derecesi kategoriye değil erişilebilirliğe göre

Bir bulgunun önem derecesi, ilk on listesinin hangi satırına benzediğini değil saldırganın ne elde ettiğini anlatmalıdır. Dört eksen bunu tek bir puandan daha iyi yapar. Erişilebilirlik: genel internet, iç ağ veya kimlik doğrulama öncesi. Gereken yetki: yok, herhangi bir kimliği doğrulanmış kullanıcı, ayrıcalıklı kullanıcı. Veri sınıfı: kimlik bilgileri, ödeme verisi, kişisel veri veya telemetri. Etki yarıçapı: tek nesne, tek kiracı veya tüm platform.

Aynı hatayı bu eksenlerden iki kez geçirdiğinizde sonuç kendini gösterir. Ağ politikası ve ayrıcalıklı bir rolle korunan dahili bir uç noktada nesne düzeyinde yetkilendirme hatası orta düzey bir bulgudur. Başka bir müşterinin faturasını döndüren genel bir uç noktada aynı hata, bir betiğin dakikada bin kez tekrarlayabileceği bildirilebilir bir kişisel veri maruziyetidir; rapor bunu yüksek sesle söylemelidir, çünkü bir hatayı olaya çeviren şey hızdır.

Kapsam ve maliyet: gün sayısı neden uç nokta çarpı roldür

Yayımlanmış fiyat listeleri aynı biçimde buluşur, çünkü hepsi aynı aritmetiği fiyatlar. Budget Security'nin 2026 fiyat listesi on ile yirmi beş uç nokta için dört ile beş gün, karma rollere sahip kırk ile seksen uç nokta için altı ile dokuz gün, birden çok servise yayılmış yüz ve üzeri uç nokta için on ile on yedi gün öneriyor. Orta ölçekli bir API değerlendirmesi için yayımlanmış tedarikçi teklifleri kabaca 3.000 ile 28.000 arasında kümeleniyor ve birkaç firma kurumsal ölçekli her iş için 14.500 civarında bir taban veriyor. Bu sayıların hiçbiri hangi uç noktalar ve kaç kimlik olduğu bilinene kadar bir şey ifade etmez; bu yüzden kapsam matrisi teklifin ekinde değil ilk sayfasındadır.

Tahmini hareket ettiren altı değişken var ve müşteri genellikle hepsini etkileyebilir. Uç nokta başına desteklenen yöntem sayısı, çünkü oluştur, oku, güncelle ve sil bir kaynak dört testtir, bir değil. Rol modeli, çünkü beş rol matrisi çarpar ve rol hiyerarşisi üstüne yükseltme testleri ekler. Yüzeyin belgelenmiş olup olmadığı, çünkü keşif ilk doğrulamadan önce günler süren iştir. Müşterinin rol başına hesapları ve test verisini sağlayıp sağlamadığı, çünkü bunları kurmak tek başına işin beşte biri olabilir. Yük testinin kapsamda olup olmadığı, ki bu takvimi olduğu kadar yetkilendirme belgesini de değiştirir. Ve yeniden test koşulları, çünkü yeniden test edilmeyen düzeltme sonuç değil iddiadır.

Bu yüzden kapsam belgesine yazılması gerekenler gösterişsiz ve somuttur: uç nokta listesi ve sayısı, rol listesi, ortamlar, test verisinin sahibi, test penceresi, yük veya hizmet engelleme testine izin verilip verilmediği, rapor biçimi, yeniden test penceresi ve ürünün tükettiği iş ortağı ile tedarikçi API'lerinin kendi yazılı yetkilendirmesi olmadan kapsam dışı olduğunu belirten bir satır. Web ve mobil uygulamayı API ile birlikte kapsayan bir sızma testi genellikle tek çalışma olarak planlanır, çünkü aynı oturum ve aynı test hesapları ikisine de hizmet eder.

Yasal sınır ve yetkilendirme belgesi

Bir API testindeki her istek, birinin sistemine yapılmış bir erişim isteğidir ve testi saldırıdan ayıran tek şey, ilk istek gönderilmeden önce imzalanmış bir belgedir. Bu belge sistemleri ve alan adlarını, kaynak adresleri, zaman penceresini, izin verilen teknikleri, hariç tutulan teknikleri, veri işleme kurallarını, acil durum iletişimini ve test sürerken kapsamı yazılı olarak genişletmeye yetkili kişiyi adlandırır. Test ortasında kapsam genişletilecekse genişletme önce kâğıt üzerinde olur; bir mühendisin sözlü "devam edin"i şirket adına yetkilendirme değildir.

Üç sınır, ayrımı net tutmak için açıkça yazılmalı. Kendi sistemlerinizi test etmek izin açısından sınırsız, değişiklik kontrolü açısından sınırlıdır. Müşterinin sistemlerini test etmek sözleşmeyle sınırlıdır ve sözleşme onların tedarikçilerine uzanmaz. Ürününüzün tükettiği bir API'yi - ödeme sağlayıcısı, harita servisi, kimlik servisi - test etmek, o hizmetle müşteri olma ilişkinizle yetkilendirilmez ve koşulları neredeyse her zaman yasaklar; geçerli alternatif, bozuk, gecikmeli ve düşmanca yanıtları döndüren bir taklit sunucu kurup entegrasyonunuzun bunları nasıl işlediğini test etmektir. Sahibi olmadığınız, keşfettiğiniz bir API ise ne kadar açık görünürse görünsün hiçbir zaman kapsamda değildir.

Son sınır, çalışmanın güvenlik raporu mu yoksa olay mı olarak biteceğini belirleyen sınırdır: etkiyi kanıtlamak veriyi almak değildir. Erişimi tek bir kayıt ve asgari alanla kanıtlayın, sayıyı kaydedin, durun. "Ölçeği göstermek için" müşteri tablosunu indiren bir API testi, yetkili testten yetkisiz veri işlemeye geçmiştir ve o noktada müşterinin avukatı kapsam belgesini sempatiyle okumaz.

İlk gün test planı ve düzeltme sırası

Aşağıdaki plan, ucuz ve verimi yüksek doğrulamaların veriye veya yüke dokunan her şeyden önce gelmesi için bilinçli olarak sıralanmıştır. Test hesapları hazır olan olgun bir API'de tek güne sığar ve çoğu projede en önemli bulguyu üretir: bir koleksiyon uç noktasında eksik nesne düzeyi kontrolü.

Düzeltme sırası neredeyse her raporda aynıdır ve bulguları yalnızca CVSS puanına göre sıralamak yerine bunu söylemek gerekir. Birincisi, her işleyicinin geçtiği tek bir paylaşılan katmanda nesne yetkilendirmesini uygulayın, çünkü bu vaka yerine sınıfı kapatır. İkincisi, tokenları algoritma sabitlenmiş, hedef kitle ve düzenleyici kontrol edilmiş biçimde sunucuda doğrulayın, çünkü yanlış servis tarafından kabul edilen token bir yanal hareket aracıdır. Üçüncüsü, her kimlik bilgisi uç noktasına başarısızlıkları sayan ve kilitlenme uygulayan hesap başına sınır koyun, çünkü anahtar uzayı aritmetiğini bağlayan tek kontrol budur. Dördüncüsü, yanıt projeksiyonlarını tanımlayın; modeller kimsenin istemediği alanları sızdırmayı bıraksın. Beşincisi, para veya stok hareket ettiren durum değişikliklerine veritabanı kısıtı ve idempotency anahtarı ekleyin. Altıncısı, 403 veya 404 politikasını bir kez yazın ve hata işleyicisinde uygulayın.

Bunların hiçbiri baştan yazmayı gerektirmez ve hepsi sonradan, sorunu bulan aynı betikle test edilebilir. Bir API testinin tutması gereken ölçüt de budur: bulguları yeniden çalıştırılabilen, kapsamı sayılabilen ve düzeltmeleri hatta bir doğrulama bırakan bir rapor.