API Güvenliği 2026: OWASP API Top 10 ve Üretimde Korunma Stratejileri

API Güvenliği Nedir ve OWASP API Top 10 Üretimde Hangi Riskleri Kapsar

API güvenliği; uygulama programlama arayüzlerinin yetkisiz erişim, veri sızıntısı ve istismara karşı korunmasıdır. 2026’da bu alanın referans çerçevesi OWASP API Security Top 10’dur (2023 sürümü hâlâ güncel temeldir) ve en kritik üç risk açık ara öne çıkar: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication ve API3 Broken Object Property Level Authorization. Üretimde korunmanın özü, yetkilendirmeyi her nesne ve her özellik düzeyinde, ağ geçidinde değil iş mantığında zorunlu kılmaktır.

API’lerin saldırı yüzeyi katlanarak büyüyor. Gartner uzun süredir API’lerin web uygulamaları için en sık saldırı vektörü olduğunu öngörüyordu; Salt Security’nin 2024 State of API Security raporuna göre kurumların yaklaşık %95’i son 12 ayda bir API güvenlik olayı yaşadı ve API trafiğinin yaklaşık üçte biri kötü amaçlı veya anomali olarak işaretlendi. Akamai verileri, web saldırı trafiğinin önemli ve artan bir payının doğrudan API’leri hedeflediğini gösteriyor. Modern uygulamalarda iş mantığının büyük kısmı API üzerinden aktığı için, geleneksel WAF kuralları tek başına yetersiz kalır.

Sorunun kökü mimaridir: mobil uygulamalar, tek sayfa uygulamalar (SPA), mikroservisler ve üçüncü taraf entegrasyonlar arasındaki tüm iletişim API’ler üzerinden akıyor. Bu, on yıl önce sunucu tarafında gizli kalan iş mantığının artık doğrudan internete açık olması demek. OWASP API Security Project, bu yeni yüzeyi sistematik biçimde haritalamak için Top 10’u oluşturdu; liste, web uygulamalarına yönelik klasik OWASP Top 10’dan ayrı ve API’ye özgüdür.

Rakamlar sorunun ölçeğini somutlaştırır. Salt Security raporuna göre kurumların yaklaşık %95’i son 12 ayda en az bir API güvenlik olayı yaşadı ve katılımcıların %23’ü doğrudan bir API ihlaliyle karşılaştığını bildirdi; aynı dönemde kötü amaçlı API trafiği yaklaşık iki katına çıktı. Akamai’nin gözlemlerinde API’ler artık tüm hesap ele geçirme (account takeover) saldırılarının önemli bir bölümünün giriş noktası. Maliyet tarafında IBM’in 2024 veri ihlali raporu, ortalama bir ihlalin küresel maliyetini 4,88 milyon dolar olarak ölçtü; API kaynaklı ihlaller, geniş veri ifşası potansiyeli nedeniyle bu ortalamanın üzerinde seyrediyor. Gartner ise yıllar önce 2025’e kadar API kötüye kullanımının en sık saldırı vektörü olacağını öngörmüştü; 2026 verileri bu öngörünün gerçekleştiğini doğruluyor. Bu tablo, API güvenliğinin neden artık ayrı bir disiplin olarak ele alınması gerektiğini net biçimde ortaya koyuyor.

OWASP API Top 10 2023: Tam Liste ve Etki

OWASP API Security Top 10, API’lere özgü riskleri sistematik biçimde sıralar. Aşağıdaki tablo, her riskin tipik istismar yöntemini ve birincil savunmasını özetler.

Liste API9 (Improper Inventory Management) ve API10 (Unsafe Consumption of APIs) ile tamamlanır. OWASP’ın açıkça vurguladığı kritik nokta şudur: BOLA, API1 olarak listenin tepesindedir çünkü hem en yaygın hem de otomatik araçlarla tespiti en zor risktir; yetkilendirme mantığı her uygulamaya özgü olduğu için jenerik tarayıcılar onu yakalayamaz.

2019 sürümüyle karşılaştırıldığında 2023 listesi iki önemli değişiklik içerir: “Excessive Data Exposure” ve “Mass Assignment” tek bir kategoride (API3 BOPLA) birleştirildi ve iki yeni risk eklendi: API6 (Unrestricted Access to Sensitive Business Flows) ve API10 (Unsafe Consumption of APIs). Bu değişiklikler, saldırganların artık tek tek açıkları değil, iş akışlarını otomatik kötüye kullanmaya yöneldiğini yansıtır; örneğin bir bilet satış akışını botla istismar etmek teknik bir “açık” değil, iş mantığı suistimalidir.

API1 BOLA: En Tehlikeli ve En Sık Görülen Açık

BOLA, bir kullanıcının kendi yetkisi dışındaki nesnelere erişmesidir. Klasik örnek: /api/orders/1043 isteğinde ID’yi 1044 yapıp başka kullanıcının siparişini görmek. Endpoint kimliği doğrular ama erişilen nesnenin gerçekten istek sahibine ait olup olmadığını kontrol etmez.

• Kök neden: Yetkilendirme kararının yalnızca kimlik doğrulama (authentication) ile karıştırılması.
• Doğru savunma: Her veri erişiminde “bu kaynak bu kullanıcıya mı ait?” kontrolünü iş mantığına gömmek; sahiplik (ownership) doğrulamasını merkezi bir yetkilendirme katmanına almak.
• Tasarım ilkesi: Tahmin edilebilir sıralı ID yerine UUID kullanmak yüzeyi azaltır ama tek başına yeterli değildir; yetki kontrolü asla atlanmamalıdır.

BOLA’nın bu denli tehlikeli olmasının nedeni, istismarının teknik olarak ne kadar basit olmasıdır. Saldırgan geçerli bir hesapla giriş yapar, kendi kaynaklarına eriştiği isteklerdeki tanımlayıcıları gözlemler ve ardından sıralı veya tahmin edilebilir ID’leri tek tek deneyerek başkalarına ait kayıtları toplar. Bu işlem bir betikle otomatikleştirildiğinde, dakikalar içinde binlerce kaydın sızdırılması mümkün hale gelir. Geçmişte büyük teknoloji ve fintek şirketlerinde yaşanan en geniş veri sızıntılarının önemli bir bölümü tam olarak bu sınıfa girer: sistem “kim olduğunu” doğru kontrol etmiş ama “neye erişebileceğini” kontrol etmemiştir.

Doğru savunmanın merkezinde merkezi bir yetkilendirme katmanı vardır. Her veritabanı sorgusu, sahiplik koşulunu (örneğin WHERE owner_id = :current_user) zorunlu kılacak biçimde tasarlanır; bu koşul isteğe bağlı bir kontrol değil, sorgunun ayrılmaz parçası olmalıdır. Open Policy Agent (OPA) gibi politika motorları, yetkilendirme kararlarını iş mantığından soyutlayıp test edilebilir ve denetlenebilir kurallara dönüştürür. Önemli bir mimari ilke de “secure by default”tur: yeni eklenen her endpoint, açıkça yetki tanımlanana kadar erişimi reddetmelidir; varsayılan açık (allow) yerine varsayılan kapalı (deny) tasarım, BOLA yüzeyini kökten daraltır.

Bu kontrol felsefesi, her isteği bağımsız doğrulayan sıfır güven mimarisi ile birebir örtüşür: API çağrısı, ağın “içinden” geliyor olsa bile asla otomatik güven kazanmaz.

Kimlik Doğrulama ve Token Güvenliği

API2 (Broken Authentication), zayıf token yönetimi, eksik rate limiting ve hatalı OAuth2 akışlarından kaynaklanır. Üretimde güvenli kimlik doğrulama için doğrulanmış uygulamalar:

• Kısa ömürlü access token + refresh: JWT’ler dakikalar ölçeğinde geçerli olmalı; uzun ömürlü token sızdığında tehlike penceresi büyür.
• İmza doğrulaması: alg: none kabul edilmemeli; algoritma sunucu tarafında sabitlenmeli.
• Rate limiting + brute force koruması: Login ve token endpoint’leri sıkı kotalarla korunmalı.

Token yaşam döngüsü ve dinamik kimlik bilgisi yönetimi, doğrudan secrets yönetimi disiplinine bağlıdır; API anahtarları statik ve dönmeyen biçimde dağıtıldığında API2 riski kalıcılaşır. Kimlik doğrulama mekanizması seçimi de risk profilini doğrudan belirler:

OAuth2 akışlarında en sık hata, public istemcilerde (SPA, mobil) PKCE kullanmamaktır; bu, yetkilendirme kodunun ele geçirilmesine kapı açar. JWT’lerde ise alg: none kabulü veya algoritma karışıklığı (algorithm confusion) saldırısı, imzanın tamamen atlanmasına yol açabilir.

API Gateway ve Üretim Savunma Katmanları

API gateway, kimlik doğrulama, rate limiting ve şema validasyonu için merkezi uygulama noktasıdır; ancak nesne-düzeyi yetkilendirme (BOLA savunması) gateway’de değil, servisin iş mantığında çözülmelidir. Doğru mimari, katmanlı savunmadır.

Gateway seçimi başlı başına bir mimari karardır; API gateway karşılaştırması, rate limiting ve auth yeteneklerini değerlendirirken güvenlik gereksinimlerinizi merkeze almanız gerektiğini gösterir.

Rate Limiting ve Kaynak Tüketimi Savunması

API4 (Unrestricted Resource Consumption), hem hizmet reddi (DoS) hem de maliyet patlaması riskidir; özellikle çıkarım veya arama gibi pahalı endpoint’lerde kritiktir. Doğru savunma katmanlı kotalardır:

GraphQL API’lerinde tek bir derin iç içe sorgu, milyonlarca veritabanı satırını tetikleyebilir; bu yüzden sorgu karmaşıklığı (complexity) analizi ve derinlik limiti zorunludur. REST’te ise sayfalama (pagination) olmadan dönen listeler, hem performansı hem de API3 kapsamında aşırı veri ifşasını riske atar.

Kaynak tüketimi savunmasında sık atlanan boyut maliyettir. Bulut tabanlı ve özellikle yapay zeka çıkarımı içeren endpoint’lerde, sınırsız istek yalnızca hizmet reddine değil, doğrudan faturaya yansıyan bir saldırıya (denial-of-wallet) dönüşür: token başına ücretlendirilen bir LLM ucu, kotasız bırakıldığında saatler içinde dört haneli dolar maliyeti üretebilir. Bu yüzden rate limiting yalnızca güvenlik değil, finansal bir kontroldür. Doğru tasarımda kotalar çok katmanlıdır: IP başına kaba bir limit edge’de, kullanıcı/token başına ince bir limit gateway’de ve pahalı işlemler için iş-mantığı seviyesinde ayrı bir bütçe tanımlanır. Cloudflare ve benzeri edge sağlayıcılarının verileri, hacimsel saldırıların büyük bölümünün daha uygulama katmanına ulaşmadan kenarda emildiğini gösteriyor; bu da rate limiting’in katmanlı kurulduğunda ne kadar etkili olduğunu kanıtlar.

Shift-Left: Güvenliği Pipeline’a Taşımak

Üretimdeki API’leri korumak yetmez; açıkları geliştirme aşamasında yakalamak gerekir. OpenAPI/Swagger şemasından otomatik test üretmek, DAST araçlarını API’lere yönlendirmek ve sözleşme (contract) testleriyle beklenmeyen alanları yakalamak shift-left yaklaşımının özüdür. Bu denetimleri DevSecOps pipeline’ına entegre etmek, güvenliği sürekli ve otomatik kılar. IBM verilerine göre tasarım aşamasında yakalanan bir açığın düzeltme maliyeti, production’a ulaşmış olana kıyasla kat kat düşüktür.

Snyk’in geliştirici güvenliği raporları, üretime kaçan açıkların büyük bölümünün aslında bilinen ve önceden yakalanabilir desenler olduğunu vurgular; sorun araçların eksikliği değil, kontrolün geç devreye girmesidir. Pratik bir shift-left dizisi şöyle kurgulanır: kodda statik analiz (SAST) sırların ve enjeksiyon desenlerinin sızmasını engeller, bağımlılık taraması (SCA) güvenlik açığı taşıyan üçüncü taraf paketleri yakalar, OpenAPI şemasına karşı çalışan sözleşme testleri beklenmeyen alanları (mass assignment yüzeyi) tespit eder ve son olarak otomatik DAST taraması canlıya yakın bir ortamda BOLA ve yetki açıklarını dener. Bu dört katman CI/CD’ye gömüldüğünde, güvenlik bir sürüm sonu denetimi olmaktan çıkıp her commit’te çalışan bir kalite kapısına dönüşür.

Önemli bir tamamlayıcı, otomatik testlerin sınırını kabul etmektir: jenerik tarayıcılar BOLA gibi iş mantığına özgü açıkları büyük ölçüde kaçırır. Bu yüzden olgun ekipler, kritik yetkilendirme yollarını kapsayan özel sözleşme/entegrasyon testleri yazar ve düzenli aralıklarla manuel sızma testi (penetration test) ile bu kör noktayı kapatır. Shift-left, manuel denetimin yerini almaz; onu daha az ama daha derin hale getirir.

API Envanteri ve Çalışma Zamanı Görünürlüğü

API güvenliğinin en sık ihmal edilen temeli, korunması gereken yüzeyin tam olarak bilinmemesidir. Güvenlik takımları çoğu zaman dokümante edilmiş API’leri korur, oysa gerçek saldırı yüzeyini dokümante edilmemiş “gölge” (shadow) ve kullanımdan kalkmış “zombi” (zombie) endpoint’ler oluşturur. Salt Security verilerine göre kurumlar ortalama olarak sahip olduklarını sandıkları API sayısının belirgin biçimde fazlasını çalıştırıyor; bu fark, kör noktanın büyüklüğünü gösterir. Görünürlük olmadan hiçbir savunma katmanı eksiksiz olamaz; çünkü bir gateway yalnızca trafiğin geçtiği endpoint’leri koruyabilir.

Çalışma zamanı görünürlüğü, bu envanteri canlı tutar. Trafik tabanlı API keşfi, gateway’den geçmeyen endpoint’leri bile pasif dinleme veya log analiziyle ortaya çıkarır; davranışsal anomali tespiti ise normal kullanım kalıbından sapan istekleri (örneğin tek bir token’dan binlerce farklı kaynağa erişim girişimi, klasik BOLA imzası) gerçek zamanlı işaretler. Bu katman, OWASP API6 (Hassas İş Akışlarına Sınırsız Erişim) ve otomatik bot kötüye kullanımına karşı tek etkili savunmadır; çünkü her bir istek tek başına geçerli görünse de, toplu davranış kötü niyeti açığa çıkarır. Envanter ve çalışma zamanı izleme birlikte, “neyi koruyorum ve şu an ona ne oluyor” sorusunu sürekli yanıtlanabilir kılar.

Tipik Sorunlar ve Çözümleri

API güvenliği projelerinde en sık başarısızlık kaynakları; envanter eksikliği, yetkilendirmenin yanlış katmanda çözülmesi ve test kapsamının dar tutulmasıdır. En kritik sorunlar ve doğrulanmış çözümleri:

• “Gölge API” (shadow/zombie endpoint) envanteri yok: Çözüm: trafik tabanlı API keşfi + merkezi katalog; dokümante edilmemiş eski sürümleri kapat.
• BOLA’yı gateway’de çözmeye çalışmak: Çözüm: nesne sahipliği kontrolünü iş mantığına/yetki katmanına taşı; gateway yalnızca kimlik ve kota için.
• Mass assignment (aşırı alan kabulü): Çözüm: gelen payload’ı şema bazlı whitelist ile sınırla; istemciden gelen tüm alanları körü körüne bind etme.
• Hata mesajlarında veri sızıntısı: Çözüm: jenerik hata yanıtları; stack trace ve iç detayları asla istemciye verme.
• Eksik rate limiting (DoS yüzeyi): Çözüm: endpoint bazlı kota + sayfalama zorunluluğu + sorgu derinliği limiti (GraphQL için kritik).
• İç API’lerin korunmasız varsayılması: Çözüm: doğu-batı trafiğine de mTLS ve yetki uygula; iç ağ güvenilir kabul edilmemeli.

Sonuç

API güvenliği 2026’da uygulama güvenliğinin merkezindedir ve OWASP API Top 10 bu alanın net yol haritasıdır. En büyük tehlike BOLA’dır; çünkü yaygındır, otomatik tarayıcılarla yakalanamaz ve yetkilendirme mantığının her uygulamaya özgü olmasını gerektirir. Üretimde korunma, katmanlı savunmadan geçer: WAF ve gateway kimlik/kota için, servis katmanı nesne-düzeyi yetki için, pipeline ise shift-left tarama için. Salt Security’nin %95 olay oranı, API güvenliğinin artık opsiyonel olmadığını gösteriyor. Önce envanterinizi çıkarın, BOLA savunmasını iş mantığına gömün, ardından kademeli olarak diğer riskleri kapatın.

Sıkça Sorulan Sorular