Hızlı Cevap

API güvenliği, uygulama programlama arayüzlerini yetkisiz erişime, veri sızıntısına ve kötüye kullanıma karşı korumaktır. OWASP API Security Top 10 (2023), en kritik on riski listeler. En tehlikeli madde BOLA (bozuk nesne seviyesi yetkilendirme) olup, saldırgan kimlik numarasını değiştirerek başkasının verisine ulaşır. API sızma testi bu riskleri yetki dahilinde, kanıtla doğrular.

API Güvenliği Neden Web Güvenliğinden Farklı?

Geleneksel web uygulamalarında sunucu, HTML sayfaları üreterek istemciye gönderir ve iş mantığının büyük kısmı sunucu tarafında saklı kalır. API merkezli mimaride ise istemci (mobil uygulama, tek sayfa uygulaması, başka bir servis) doğrudan ham veriyle, çoğunlukla JSON formatında konuşur. Bu durum saldırı yüzeyini köklü biçimde değiştirir.

Bir API, iş mantığını ve veri modelini istemciye açıkça gösterir. Saldırgan ağ trafiğini izleyerek hangi uç noktaların var olduğunu, hangi parametrelerin kabul edildiğini ve verinin nasıl yapılandırıldığını görür. Tarayıcı tabanlı korumalar (aynı kaynak politikası, içerik güvenliği politikası) API çağrılarında çoğu zaman geçersizdir, çünkü istemci bir tarayıcı bile olmayabilir.

Daha da önemlisi, API'ler genellikle çok sayıda mikroservis arasında dağıtılır. Her servis kendi yetkilendirme kararını verir ve bu kararlar tutarsız olduğunda yetkilendirme zafiyetleri ortaya çıkar. Bu yüzden API testi, klasik web sitesi güvenlik testi ve WAF yaklaşımının ötesine geçer ve yetkilendirme mantığına, veri akışına ve servisler arası güven ilişkilerine odaklanır.

API Türleri ve Güvenlik Etkileri

Kurumsal ortamlarda üç ana API mimarisi hakimdir ve her birinin kendine özgü güvenlik özellikleri vardır:

Özellik REST GraphQL gRPC
Veri formatı Genellikle JSON JSON Protocol Buffers (ikili)
Uç nokta yapısı Kaynak başına çok uç nokta Tek uç nokta Servis/metot tabanlı
Sorgu esnekliği Sabit yanıt İstemci sorguyu belirler Sabit sözleşme
Tipik zafiyet BOLA, kütle atama İç içe sorgu DoS, introspection sızıntısı Yansıma ile keşif, zayıf TLS
Keşif kolaylığı Orta (dokümantasyon, fuzzing) Yüksek (introspection açıksa) Düşük (ikili, proto gerekir)
Hız sınırlama Uç nokta bazlı kolay Karmaşık (sorgu maliyeti) Akış bazlı zor

REST API'ler kaynak başına ayrı uç noktalar (örneğin /api/users/123) kullandığı için nesne seviyesi yetkilendirme hatalarına en açık olanlardır. GraphQL tek uç nokta üzerinden esnek sorgular sunar; bu güç, iç içe geçmiş sorgularla hizmet dışı bırakma ve introspection ile şema sızıntısı risklerini beraberinde getirir. gRPC ikili Protocol Buffers kullandığı için yüzeysel olarak daha gizli görünse de, sunucu yansıması (server reflection) açık bırakıldığında tüm servis sözleşmesi keşfedilebilir.

OWASP API Security Top 10 (2023) Maddeleri

OWASP API Security Top 10, API'lere özgü riskleri sıralayan endüstri standardı referanstır. Aşağıda her maddeyi nedir, örnek senaryo, nasıl test edilir ve nasıl korunur başlıklarıyla açıklıyoruz.

API1:2023 Bozuk Nesne Seviyesi Yetkilendirme (BOLA)

Nedir: API, bir nesneye erişen kullanıcının o nesneye gerçekten yetkili olup olmadığını doğrulamaz. İstek içindeki nesne kimliği değiştirildiğinde başka kullanıcının verisine erişilir. Bu, API güvenliğinin en yaygın ve en yıkıcı zafiyetidir.

Örnek senaryo: Bir kullanıcı kendi faturasını çekmek için şu isteği gönderir:

GET /api/v1/invoices/1001 HTTP/1.1
Authorization: Bearer eyJhbGciOi...

Saldırgan kimliği 1001 yerine 1002 yapar:

GET /api/v1/invoices/1002 HTTP/1.1
Authorization: Bearer eyJhbGciOi...

Sunucu, oturum açan kullanıcının 1002 numaralı faturanın sahibi olup olmadığını kontrol etmezse, başka bir müşterinin faturası döner. Bu, ardışık kimliklerin sıralı taranmasıyla (enumeration) tüm veritabanının sızdırılmasına yol açar.

Nasıl test edilir: İki ayrı kullanıcı hesabı oluşturulur. A kullanıcısının nesne kimlikleri, B kullanıcısının oturumuyla istenir. Yanıt verisi B'ye değil A'ya aitse zafiyet doğrulanır. Sayısal kimlikler, UUID'ler, e-posta adresleri ve dolaylı referanslar tek tek denenir. Otomatik araçlarla kimlik aralıkları taranır.

Nasıl korunur: Her istekte, oturum sahibinin istenen nesneye yetkili olduğu sunucu tarafında zorunlu olarak doğrulanır. Tahmin edilebilir ardışık kimlikler yerine rastgele UUID kullanmak yardımcı olur ama tek başına yeterli değildir; asıl çözüm her nesne erişiminde sahiplik kontrolüdür.

API2:2023 Bozuk Kimlik Doğrulama (Broken Authentication)

Nedir: Kimlik doğrulama mekanizmaları hatalı uygulanır; saldırgan kimlik bilgilerini ele geçirir veya doğrulamayı atlar. Zayıf jeton üretimi, jeton süresinin hiç dolmaması, deneme sınırının olmaması bu sınıfa girer.

Örnek senaryo: Giriş uç noktası hız sınırlaması içermez ve hesap kilitleme yoktur. Saldırgan, çalınmış parola listesiyle (credential stuffing) saniyede yüzlerce deneme yaparak hesapları ele geçirir. Ayrıca JWT jetonunun imza algoritması none olarak kabul ediliyorsa, saldırgan jetonu kendisi imzasız üretir.

Nasıl test edilir: Giriş, parola sıfırlama ve jeton yenileme uç noktalarında deneme sınırı test edilir. JWT jetonları çözümlenir; algoritma karıştırma (RS256 yerine HS256), none algoritması, zayıf imzalama anahtarı denenir. Jeton süresinin dolup dolmadığı, çıkışta geçersiz kılınıp kılınmadığı kontrol edilir.

Nasıl korunur: Çok faktörlü kimlik doğrulama, güçlü ve doğrulanmış JWT imzalaması, kısa jeton ömrü, giriş uç noktalarında hız sınırlaması ve hesap kilitleme uygulanır. Algoritma sunucu tarafında sabitlenir, asla istemcinin belirttiği algoritmaya güvenilmez.

API3:2023 Bozuk Nesne Özelliği Seviyesi Yetkilendirme (BOPLA)

Nedir: API, bir nesnenin tek tek özelliklerine (alanlarına) yetkilendirme uygulamaz. Bu hem aşırı veri ifşası (kullanıcının görmemesi gereken alanların döndürülmesi) hem de kütle atama (mass assignment, kullanıcının değiştirmemesi gereken alanları güncelleyebilmesi) olarak ortaya çıkar.

Örnek senaryo: Profil güncelleme isteği yalnızca ad ve telefon bekler, ancak istemci ekstra alan ekler:

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

{"name": "Ali", "phone": "5xx", "role": "admin", "isVerified": true}

Sunucu gelen JSON'u körü körüne nesneye atarsa, kullanıcı kendisini yönetici yapar. Tersine, bir kullanıcı listesi yanıtı passwordHash veya internalNotes alanlarını döndürüyorsa aşırı ifşa söz konusudur.

Nasıl test edilir: Yanıtlar fazla alanlar için incelenir. İstek gövdelerine role, isAdmin, balance, verified gibi hassas alanlar eklenip kabul edilip edilmediği denenir. Önceki bir okuma isteğinden alınan tam nesne, güncelleme isteğine geri gönderilerek hangi alanların yazılabildiği gözlenir.

Nasıl korunur: Giriş ve çıkış için açık beyaz liste (allow list) şemaları kullanılır. İstemciden gelen veri asla doğrudan veri modeline atanmaz; yalnızca izin verilen alanlar seçilerek alınır. Yanıtlarda hangi alanların döneceği açıkça tanımlanır.

API4:2023 Sınırsız Kaynak Tüketimi (Unrestricted Resource Consumption)

Nedir: API, istek başına tüketilen kaynaklara (CPU, bellek, ağ, üçüncü taraf maliyetleri) sınır koymaz. Bu, hizmet dışı bırakma ve maliyet patlamasına yol açar.

Örnek senaryo: Bir uç nokta sayfalama parametresi limit değerini sınırsız kabul eder. Saldırgan ?limit=10000000 göndererek sunucuyu yorar. Veya SMS doğrulama uç noktası sınırsız çağrılabildiğinde, saldırgan binlerce SMS tetikleyerek firmaya yüksek fatura çıkarır.

Nasıl test edilir: Sayfalama, dosya yükleme boyutu, toplu işlem (batch) sayıları sınır testine tabi tutulur. Aşırı büyük değerler, çok sayıda eşzamanlı istek ve büyük yükler gönderilir. SMS, e-posta, ödeme gibi maliyetli işlemlerin hız sınırı denetlenir.

Nasıl korunur: İstek boyutu, sayfalama, eşzamanlılık ve yürütme süresi sınırlandırılır. Hız sınırlama hem IP hem kullanıcı bazında uygulanır. Maliyetli işlemlerde ek doğrulama ve katı kotalar konur.

API5:2023 Bozuk Fonksiyon Seviyesi Yetkilendirme (BFLA)

Nedir: API, bir fonksiyonu (genellikle yönetici işlevlerini) çağıran kullanıcının o işleve yetkili olup olmadığını doğrulamaz. BOLA nesnelere, BFLA ise eylemlere/uç noktalara odaklanır.

Örnek senaryo: Sıradan kullanıcı, yönetici uç noktasını doğrudan çağırır:

DELETE /api/v1/admin/users/500 HTTP/1.1
Authorization: Bearer <normal-kullanici-jetonu>

Sunucu yalnızca arayüzde yönetici düğmesini gizlemiş ama uç noktada rol kontrolü yapmamışsa, normal kullanıcı başka hesapları silebilir. HTTP metodu değişimi de (GET yerine PUT/DELETE denemek) yetkilendirme boşluklarını ortaya çıkarır.

Nasıl test edilir: Yönetici ve ayrıcalıklı uç noktalar düşük yetkili hesapla çağrılır. Dokümantasyondan veya JavaScript dosyalarından keşfedilen gizli uç noktalar denenir. Farklı HTTP metotları (PUT, DELETE, PATCH) aynı yol üzerinde test edilir.

Nasıl korunur: Her uç noktada rol ve yetki kontrolü sunucu tarafında merkezi olarak zorunlu kılınır. Varsayılan olarak reddet (deny by default) ilkesi uygulanır; bir uç nokta açıkça izin verilmedikçe erişilemez.

API6:2023 Hassas İş Akışlarına Sınırsız Erişim (Sensitive Business Flows)

Nedir: API, bir iş akışının otomatik ve aşırı kullanıma karşı korunmadığı durumdur. Teknik olarak her istek geçerli olsa da, akışın toplu otomasyonu işi zarara uğratır.

Örnek senaryo: Sınırlı sayıda satılan bir ürünün satın alma akışı, botlarla saniyeler içinde tüketilerek gerçek müşteriler dışlanır (scalping). Veya yorum/oylama akışı botlarla manipüle edilir. Her istek tek başına meşrudur, sorun ölçek ve otomasyondur.

Nasıl test edilir: Kritik iş akışları (kayıt, satın alma, kupon kullanımı, davet) betiklerle otomatikleştirilir ve aşırı hızla tekrarlanır. Bot tespiti, CAPTCHA, cihaz parmak izi ve davranışsal kontrollerin var olup olmadığı gözlenir.

Nasıl korunur: İş akışı düzeyinde otomasyon karşıtı önlemler eklenir: hız sınırlama, bot tespiti, ikinci kanal doğrulama, anormal davranış izleme ve akış başına kotalar. Korumanın iş etkisine göre önceliklendirilmesi gerekir.

API7:2023 Sunucu Taraflı İstek Sahteciliği (SSRF)

Nedir: API, kullanıcıdan gelen bir URL'yi doğrulamadan getirir. Saldırgan sunucuyu, dahili ağa veya bulut meta veri servisine istek atması için kandırır.

Örnek senaryo: Bir uç nokta uzaktan görsel alır:

POST /api/v1/import-image HTTP/1.1
Content-Type: application/json

{"imageUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Sunucu bu URL'yi körü körüne getirirse, bulut sağlayıcının meta veri servisinden geçici kimlik bilgileri sızdırılır. Dahili http://localhost:8080/admin gibi adresler de hedeflenebilir.

Nasıl test edilir: URL kabul eden tüm parametreler tespit edilir (webhook, görsel içe aktarma, PDF üretimi, bağlantı önizleme). Bu parametrelere dahili IP'ler, localhost, bulut meta veri adresleri ve kontrol edilen bir dış sunucu (out-of-band) verilir. Sunucudan geri çağrı gelip gelmediği izlenir.

Nasıl korunur: Kullanıcı sağladığı URL'ler katı bir beyaz listeye göre doğrulanır. Dahili IP aralıkları ve meta veri adresleri engellenir. Yönlendirmeler (redirect) izlenmez veya kısıtlanır. Çağrılar ayrı bir ağ segmentinden yapılır.

API8:2023 Güvenlik Yanlış Yapılandırması (Security Misconfiguration)

Nedir: API yığınının herhangi bir katmanında güvensiz varsayılanlar, eksik sertleştirme veya gereksiz açık özellikler bulunur. Eksik güvenlik başlıkları, aşırı izin veren CORS, ayrıntılı hata mesajları, açık hata ayıklama uç noktaları bu sınıftadır.

Örnek senaryo: API, Access-Control-Allow-Origin: * ile birlikte kimlik bilgilerini kabul eder, böylece kötü amaçlı bir site kullanıcı oturumuyla istek atabilir. Veya bir hata yanıtı tam yığın izini (stack trace) ve veritabanı sorgusunu döndürerek iç yapıyı ifşa eder.

Nasıl test edilir: Güvenlik başlıkları, CORS politikası, TLS yapılandırması, hata mesajlarının ayrıntı düzeyi ve gereksiz HTTP metotları (TRACE, OPTIONS) denetlenir. Varsayılan kimlik bilgileri, açık yönetim panelleri ve eski API sürümleri aranır.

Nasıl korunur: Tüm ortamlarda tutarlı, sertleştirilmiş ve otomatikleştirilmiş yapılandırma uygulanır. Hata mesajları genel tutulur, iç detay sızdırmaz. CORS yalnızca güvenilen kaynaklara açılır. Gereksiz özellikler ve metotlar kapatılır.

API9:2023 Uygunsuz Envanter Yönetimi (Improper Inventory Management)

Nedir: Kurum, hangi API'lerin, hangi sürümlerin ve hangi uç noktaların yayında olduğunu tam bilmez. Eski (/api/v1), test (/api/beta) veya gölge (shadow) API'ler güncellenmeden açık kalır.

Örnek senaryo: Üretimdeki /api/v2 sertleştirilmişken, unutulmuş /api/v1 aynı verilere zayıf kimlik doğrulamayla erişim verir. Saldırgan eski sürümü keşfederek yeni sürümdeki tüm korumaları atlar.

Nasıl test edilir: Sürüm numaraları, alt alan adları, eski yollar ve dokümantasyon dosyaları (Swagger/OpenAPI tanımları) aranır. Pasif keşif, DNS, sertifika şeffaflık kayıtları ve JavaScript analiziyle bilinmeyen uç noktalar çıkarılır.

Nasıl korunur: Tüm API'lerin ve sürümlerin merkezi, güncel bir envanteri tutulur. Kullanımdan kaldırılan sürümler kapatılır. Test ortamları üretim verisinden ve internetten izole edilir. OpenAPI tanımları erişim kontrolünün kaynağı yapılır.

API10:2023 API'lerin Güvensiz Tüketimi (Unsafe Consumption of APIs)

Nedir: Geliştiriciler, üçüncü taraf API'lerden gelen veriye kendi kullanıcılarından gelen veriden daha fazla güvenir. Entegre edilen bir dış servis ele geçirilir veya kötü veri dönerse, bu veri doğrulanmadan işlenir.

Örnek senaryo: Bir ödeme veya zenginleştirme servisinden dönen yanıt, doğrulanmadan veritabanına yazılır. Dış servis enjeksiyon yüküyle yanıt verirse, bu yük iç sistemde çalışır. Yönlendirmelerin (redirect) körü körüne izlenmesi de SSRF benzeri sonuçlar doğurur.

Nasıl test edilir: Dış API entegrasyonları haritalanır. Mümkünse dış servisin yanıtı taklit edilerek (proxy ile araya girilerek) hatalı/zararlı veri döndüğünde uygulamanın davranışı gözlenir. TLS doğrulamasının aktif olup olmadığı kontrol edilir.

Nasıl korunur: Üçüncü taraf veriler de kullanıcı verisi gibi doğrulanır ve temizlenir. Dış çağrılarda TLS zorunlu kılınır, sertifika doğrulanır. Dış servislerden gelen yönlendirmeler izlenmez. Zaman aşımı ve devre kesici (circuit breaker) mekanizmaları kullanılır.

API Sızma Testi Süreci

Kurumsal bir API sızma testi, rastgele araç çalıştırmaktan çok daha fazlasıdır. Yapılandırılmış, kapsamı belirlenmiş ve kanıta dayalı bir süreç izler. Sürecin standartları ve fiyatlandırması için sızma testi süreci ve fiyatı yazımızdan ayrıntılı bilgi alabilirsiniz; burada API'ye özgü adımlara odaklanıyoruz.

1. Kapsam Belirleme ve Yetkilendirme

Test öncesinde hedef API'ler, alan adları, ortamlar (üretim mi, hazırlık mı), hesap rolleri ve dışlanan işlemler açıkça yazılı olarak belirlenir. API testlerinde en az iki farklı yetki seviyesinde hesap (örneğin normal kullanıcı ve ikinci normal kullanıcı, ayrıca bir yönetici) sağlanması, BOLA ve BFLA testleri için kritiktir. Maliyetli işlemlerin (SMS, ödeme) test sınırları belirlenir.

2. Keşif ve Envanter Çıkarma

Tüm uç noktalar, parametreler ve veri akışları haritalanır. OpenAPI/Swagger dokümantasyonu, mobil uygulama trafiği, JavaScript dosyaları ve ağ yakalama (proxy) verisi birleştirilerek tam bir yüzey çıkarılır. GraphQL için introspection sorgusu denenir; gRPC için sunucu yansıması kontrol edilir. Bu adım API9 (envanter) riskini de doğrudan değerlendirir.

3. Kimlik Doğrulama ve Oturum Analizi

Kimlik doğrulama akışları, jeton yapısı (JWT iddiaları), jeton ömrü ve yenileme mekanizması incelenir. Jetonun nasıl üretildiği, imzalandığı ve geçersiz kılındığı doğrulanır.

4. Yetkilendirme Testleri

Sürecin kalbi burasıdır. Her uç nokta, farklı hesaplarla ve farklı nesne kimlikleriyle çalıştırılarak yatay (BOLA) ve dikey (BFLA) yetki yükseltme aranır. Bu, otomasyon ve insan analizinin birleştiği aşamadır.

5. İş Mantığı ve Girdi Testleri

Kütle atama, aşırı veri ifşası, SSRF, enjeksiyon ve hassas iş akışı suistimalleri test edilir. İş mantığı zafiyetleri otomatik araçların gözden kaçırdığı, insan muhakemesi gerektiren alandır.

6. Doğrulama ve Raporlama

Her bulgu, kanıt (PoC) ile doğrulanır ve yanlış pozitifler elenir. Bu nokta kurumsal güvenin temelidir; gürültülü, doğrulanmamış raporlar zaman kaybettirir. Doğrulanmış zafiyet, yanlış pozitifsiz test yaklaşımımızda her zafiyet kanıtla sunulur ve net düzeltme önerisiyle kapatılır.

API Test Araçları

API testinde tek bir araç yetmez; manuel keşif, otomatik tarama ve özel betiklerin birleşimi gerekir.

  • Postman: API isteklerini oluşturmak, koleksiyonları yönetmek ve yetkilendirme akışlarını manuel test etmek için yaygın kullanılır. Ortam değişkenleri ve test betikleriyle tekrarlı senaryolar kurulur.
  • Burp Suite: Araya girerek (proxy) trafiği yakalar, istekleri tekrar oynatır (Repeater), parametreleri otomatik değiştirir (Intruder) ve BOLA için kimlik aralıklarını tarar. Kurumsal API testlerinin omurgasıdır.
  • OWASP ZAP: Açık kaynaklı bir araya girme ve tarama aracıdır. OpenAPI tanımını içe aktararak otomatik uç nokta taraması yapar, pasif ve aktif tarama sunar.
  • GraphQL araçları: Introspection ile şema çıkaran ve iç içe sorgu yükü üreten özel araçlar GraphQL'e özgü riskleri test eder.

Bu araçlar güçlüdür ancak yetkilendirme mantığı ve iş akışı zafiyetlerini ölçeklenebilir biçimde, yanlış pozitifsiz tespit etmek otomasyon ister.

KAOS ile Otomatik ve Sürekli API Testi

KAOS yapay zeka güvenlik motoru, DSET'in geliştirdiği yapay zeka destekli ofansif güvenlik ajanıdır. Yetkili sızma testlerinde keşif, zafiyet tespiti, exploit üretimi ve doğrulamayı (kanıt/PoC ile, yanlış pozitifsiz) otomatikleştirir.

API testlerinde KAOS, otomatik endpoint keşfi yaparak yüzeyi çıkarır, çoklu hesaplarla BOLA ve BFLA testlerini sistematik olarak yürütür ve bulguları kanıtla doğrular. Sürekli tarama modunda, yeni sürümler ve değişen uç noktalar düzenli olarak yeniden test edilir; böylece API9 envanter sapması erken yakalanır. Tüm testler yetki dahilinde, tanımlı kapsam içinde çalışır. KAOS, deneyimli test uzmanının yerini almaz; tekrarlı ve geniş yüzeyli işi otomatikleştirerek uzmanın iş mantığı analizine odaklanmasını sağlar.

REST, GraphQL ve gRPC Testinde Özel Noktalar

REST: Kaynak tabanlı yapısı nedeniyle BOLA testi merkezdedir. Her /{kaynak}/{id} deseni, farklı hesaplarla denenir. Kütle atama için tam nesne geri gönderilir.

GraphQL: Tek uç nokta esnek sorgular sunar. Introspection açıksa tüm şema sızar; bu kapatılmalıdır. İç içe ilişkisel sorgular (örneğin yorumların yazarının yorumlarının yazarı) derinlik sınırı yoksa hizmet dışı bırakma yaratır. Sorgu maliyeti ve derinlik sınırlama test edilir. Yetkilendirme her alan (field) düzeyinde kontrol edilmelidir.

gRPC: İkili Protocol Buffers ve HTTP/2 kullanır. Sunucu yansıması açıksa servis tanımı keşfedilir. TLS yapılandırması, akış (streaming) çağrılarında kaynak tüketimi ve metot seviyesi yetkilendirme öncelikli test alanlarıdır.

Sıkça Sorulan Sorular

API güvenliği ile web uygulama güvenliği aynı şey mi?

Hayır. Web uygulama testi çoğunlukla sunucu tarafından üretilen sayfalara odaklanırken, API testi ham veri alışverişine, yetkilendirme mantığına ve servisler arası güvene odaklanır. API'ler iş mantığını ve veri modelini doğrudan açar; bu nedenle BOLA ve BFLA gibi yetkilendirme zafiyetleri API'lerde çok daha baskındır.

En yaygın API zafiyeti nedir?

BOLA (bozuk nesne seviyesi yetkilendirme), OWASP API Security Top 10'da birinci sıradadır ve pratikte en sık karşılaşılan zafiyettir. Saldırgan istek içindeki nesne kimliğini değiştirerek başka kullanıcının verisine erişir. Çözümü, her nesne erişiminde sunucu tarafında sahiplik doğrulamasıdır.

GraphQL API'ler REST'ten daha mı güvenli?

Doğası gereği ne daha güvenli ne de daha güvensizdir, farklı riskler taşır. GraphQL'in esnekliği, iç içe sorgularla hizmet dışı bırakma ve introspection ile şema sızıntısı gibi kendine özgü riskler yaratır. Yetkilendirmenin alan düzeyinde uygulanması ve sorgu derinliği/maliyetinin sınırlanması şarttır.

API sızma testi ne sıklıkla yapılmalı?

En az yılda bir kez ve önemli her mimari değişiklik, yeni sürüm yayını veya yeni entegrasyon sonrasında yapılması önerilir. API'ler sık değiştiği için sürekli (otomatik) tarama, periyodik derin manuel testle birleştirildiğinde en etkili sonucu verir. KAOS gibi araçlar sürekli tarama katmanını sağlar.

Yanlış pozitif raporlar neden sorun yaratır?

Doğrulanmamış bulgular ekiplerin zamanını boşa harcatır, gerçek zafiyetlerin gölgede kalmasına yol açar ve güveni zedeler. Bu yüzden her bulgunun kanıtla (PoC) doğrulanması ve net düzeltme önerisiyle sunulması, kurumsal bir testin olmazsa olmazıdır.

Kaynaklar

API güvenliği, modern kurumların en hızlı büyüyen saldırı yüzeyidir ve doğru test edilmediğinde tek bir BOLA zafiyeti tüm müşteri verisini riske atabilir. Uzman analizini KAOS'un sürekli, kanıta dayalı otomasyonuyla birleştirerek API'lerinizi gerçek dünya saldırılarına karşı doğrulayın.

DSET Bilişim ve Siber Güvenlik (kuruluş 2003). Kurumsal API güvenlik testi ve KAOS ile sürekli tarama için: +90 536 662 38 09.