API & REST Security

1. Giriş

Modern uygulamalar artık "sunucunun HTML ürettiği" monolitler değil; ön yüz (web/mobil) ile arka uç arasında API'ler üzerinden konuşan sistemlerdir. Bu mimari değişim, güvenlik açısından temel bir sonuç doğurur: API, veriye ve işlemlere doğrudan erişim sunar — geliştiricilerin bazen (yetersiz) kontrolleri koyduğu UI katmanını atlayarak. UI'da bir butonu gizlemek (Bölüm 14) API karşısında hiçbir şey ifade etmez; saldırgan API'yi doğrudan çağırır.

API'ler açıkları üç şekilde yoğunlaştırır ve büyütür: (1) doğrudan erişim — kontrol UI'da değil, API'de olmalı; (2) makine-tüketilebilirlik — istekler kolayca otomatikleştirilir, bu yüzden numaralandırma ve kütlesel sızdırma önemsizleşir; (3) durumsuzluk — token tabanlı kimlik ve dağıtık servisler yeni saldırı yüzeyleri açar.

Bu yoğunlaşmanın ders kitabı örneği 2022 Optus ihlalidir (Bölüm 11): tek bir kimlik doğrulamasız API uç noktası, sıralı müşteri kimlikleri, rate limiting eksikliği ve unutulmuş bir API domain'i bir araya gelince ~9.8 milyon kayıt, "curl scriptiyle ID'yi bir artırarak" sızdırıldı. Optus bunu "sofistike saldırı" diye nitelese de, hükümet yetkilisinin dediği gibi aslında "pencere açık bırakılmıştı".

Bu bölüm, API güvenliğini OWASP API Security Top 10 çerçevesiyle ele alır. Bu risklerin çoğu önceki bölümlerin API'ye özgü izdüşümleridir (BOLA = IDOR, Bölüm 15; BFLA = fonksiyon-düzeyi yetki, Bölüm 14); bu yüzden onlara atıfla geçip, API'ye özgü yeni konulara (aşırı veri ifşası, rate limiting, API envanteri) derinlemesine eğileceğiz.

---

2. Temel Teori

API neden farklı? Klasik web uygulamasında sunucu HTML üretir; kontrolleri (bazen yanlışlıkla) o katmana koymak mümkündür. API'de ise istemci — tarayıcı, mobil uygulama, üçüncü taraf — tümüyle güvenilmezdir (Bölüm 1) ve veriyi/işlemi doğrudan tüketir. Sonuç: her kontrol sunucuda, API katmanında olmalıdır. Ayrıca API'ler makine dostu olduğundan, bir açık anında otomatik ve ölçekli sömürüye açılır.

OWASP API Security Top 10 (2023) — organizasyon çerçevesi:

#	Risk	Bu kitapta
API1	BOLA (Broken Object Level Authorization)	= IDOR, Bölüm 15
API2	Broken Authentication	Bölüm 12, 23, 24
API3	Broken Object Property Level Authz	Aşırı veri ifşası + Mass Assignment (Bölüm 4) — bu bölüm
API4	Unrestricted Resource Consumption	Rate limiting — bu bölüm
API5	BFLA (Broken Function Level Authorization)	= fonksiyon-düzeyi yetki, Bölüm 14
API6	Unrestricted Access to Sensitive Business Flows	İş mantığı, Bölüm 18
API7	SSRF	Bölüm 21
API8	Security Misconfiguration	Bölüm 26, 27
API9	Improper Inventory Management	Shadow/eski API — bu bölüm
API10	Unsafe Consumption of APIs	Bölüm 30 (tedarik zinciri)

BOLA — API'nin 1 numaralı riski. BOLA, IDOR'un (Bölüm 15) API dilindeki adıdır ve sürekli olarak en yaygın API açığıdır: bir uç nokta, istemcinin verdiği nesne kimliğini sahiplik kontrolü olmadan kullanır. Her nesne erişiminde "bu kullanıcı bu nesneye erişebilir mi?" sorulmalıdır.

API'ye özgü üç yeni odak: - Aşırı veri ifşası (API3): Uç nokta, nesnenin tüm alanlarını döndürür (parola hash'i, iç bayraklar, başka kullanıcıların verisi) ve "istemci nasılsa filtreler" varsayılır. Ama istemci güvenilmez; ham yanıt saldırgana açıktır. Çözüm: sunucuda açık çıktı sözleşmesi (DTO/serializer) — yalnızca gerekli alanlar. - Rate limiting (API4): Sınırsız istek; numaralandırma, kaba kuvvet, DoS ve maliyet suistimaline açık. Optus'ta rate limiting eksikliği, milyonlarca kaydın hızla sızdırılmasını sağladı. - Envanter/shadow API (API9): Unutulmuş, versiyonu eskimiş veya belgelenmemiş API'ler (Optus'un ikincil domain'i). "Göremediğini koruyamazsın." Güncel bir API envanteri şarttır.

---

3. Mimarisel Bakış

 GÜVENSİZ API (Optus kalıbı — çoklu kusur):
   Saldırgan → GET /api/users/5332   (kimlik doğrulama YOK — API2)
        ↓  ╳ güven sınırı
   SELECT * FROM users WHERE id = 5332   (sahiplik kontrolü YOK — API1/BOLA)
        ↓  tüm alanlar döner (aşırı ifşa — API3)
   { id, name, dob, passport, medicare, ... }
        ↓  saldırgan ID'yi ++ ile döngüler (rate limit YOK — API4)
   5332 → 5333 → ... → 9.8M kayıt   (üstelik unutulmuş domain'de — API9)

 GÜVENLİ API:
   İstek → [ authN: token doğrula (Böl. 23/24) ]
        → [ authZ: BOLA — bu nesne bu kullanıcının mı? (Böl. 15) ]
        → [ authZ: BFLA — bu fonksiyona yetkili mi? (Böl. 14) ]
        → [ çıktı DTO: yalnızca gerekli alanlar (data minimization) ]
        → [ rate limit + envanter + monitoring ]
   → güvenli yanıt

Kritik gözlem: Optus'ta hiçbir kontrol "gelişmiş" değildi — temel kontrollerin hepsi birden eksikti. API güvenliği bütüncüldür; katmanlardan biri değil, hepsi gereklidir (derinlemesine savunma, Bölüm 1).

---

4. Güvensiz Kod

Gerçekçi bir REST API uç nokta kümesi:

<?php
// ⚠️ GÜVENSİZ — çoklu API açığı (OWASP API Top 10)
declare(strict_types=1);

// GET /api/users/{id} — kimlik doğrulama YOK, BOLA, aşırı ifşa
$id = (int)$request->route('id');
$user = User::find($id);                    // sahiplik kontrolü yok (BOLA/API1)
return json($user->toArray());              // TÜM alanlar: pass_hash, is_admin, ... (API3)

// POST /api/users/{id} — mass assignment (Böl. 4) + BFLA
$user = User::find($id);
$user->fill($request->all());               // role/is_admin dahil her alan (API3/mass assignment)
$user->save();                              // fonksiyon-düzeyi yetki yok (BFLA/API5)

// Hiçbir uç noktada rate limiting yok (API4)
// Eski /v1/ ve test.api.example.com hâlâ açık ve unutulmuş (API9)

---

5. Açığın Analizi

User::find($id) (sahiplik kontrolü yok) — BOLA (API1) = IDOR (Bölüm 15). Uç nokta, istemcinin verdiği id'yi doğrudan kullanıyor; "bu kullanıcı bu kaydı görebilir mi?" sorulmuyor. Kimlikler sıralıysa (Optus), saldırgan hepsini numaralandırır. Bu, API'nin en yaygın açığıdır.

json($user->toArray()) (aşırı ifşa) — Excessive Data Exposure (API3). Yanıt, nesnenin tüm alanlarını döndürüyor: parola hash'i, is_admin, iç bayraklar, belki başka kullanıcıların verisi. "İstemci gerekeni gösterir" varsayımı yanlış; ham yanıt saldırgana açıktır. Sunucu, açık bir çıktı sözleşmesiyle yalnızca gerekli alanları döndürmeli.

$user->fill($request->all()) (mass assignment) — API3 (özellik-düzeyi) + Mass Assignment (Bölüm 4). Tüm istek alanları körü körüne modele yazılıyor; saldırgan role=admin/is_admin=1 ekleyerek yetki yükseltir. Alanlar beyaz listelenmelidir.

Fonksiyon-düzeyi yetki yok — BFLA (API5) = Bölüm 14. Güncelleme uç noktası "bu kullanıcı bu işlemi yapmaya yetkili mi?" diye sormuyor.

Kimlik doğrulama yok + rate limiting yok + unutulmuş uç nokta — API2 + API4 + API9. Optus'ta bu üçü, BOLA'yı kütlesel bir ihlale dönüştüren çarpanlardı.

Kök sorun: API, istemciye güveniyor ve temel kontrollerin (authN, object-authz, function-authz, data minimization, rate limit, envanter) hiçbirini uygulamıyor. Her biri ayrı bir OWASP API riskidir ve birlikte felakete yol açarlar.

---

6. Hacker Bakış Açısı

Saldırgan API'leri nasıl hedefler?

Envanter çıkarır. Önce tüm uç noktaları haritalar: dokümantasyon (Swagger/OpenAPI), JS dosyalarındaki API çağrıları, mobil uygulama trafiği, eski versiyonlar (/v1/, /v2/), alt alanlar (api., test., staging.). Optus'taki gibi unutulmuş/shadow API'ler (API9) en zayıf halkadır çünkü izlenmez ve yamalanmaz.

Kimlik doğrulamayı test eder. Her uç noktayı token olmadan çağırır — şaşırtıcı sıklıkta bazıları kimlik doğrulamasızdır (API2). Optus'ta ana açık buydu.

BOLA'yı yoklar (birincil). Kendi nesne kimliğini başkasınınkiyle değiştirir (Bölüm 15). Sıralı kimlikse hepsini döngüler. BOLA, API testinin ilk ve en verimli adımıdır.

Yanıtı inceler (aşırı ifşa). UI'da görünmese de, ham API yanıtında fazladan alanlar arar: is_admin, iç kimlikler, başka kullanıcıların verisi, hata mesajlarında iç yapı. Yanıt genelde gösterilenden fazlasını taşır.

Mass assignment ve BFLA dener. İsteğe fazladan alanlar (role, is_admin) ekler (Bölüm 4); ve düşük yetkiyle admin fonksiyonlarını çağırır (Bölüm 14).

Rate limiting'i ölçer. Hızlı ardışık istekler atıp sınır olup olmadığını görür; yoksa numaralandırma/kaba kuvvet/DoS serbesttir. Sınır varsa, "low and slow" (yavaş ve sinsi) veya dönen IP'lerle atlatmayı dener (Optus saldırganı dönen IP kullandı).

Savunmacı dersi: Saldırgan API'yi bir veri musluğu olarak görür ve her uç noktayı bağımsızca yoklar. Tek bir korunmasız uç nokta (özellikle unutulmuş biri) tüm veriyi açabilir. Savunma her uç noktada, her katmanı uygulamalıdır.

---

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. API açıklarının neden bu kadar yıkıcı olduğu kavramsaldır:

• Doğrudan ve ölçekli. API veriye doğrudan eriştiğinden ve makine-tüketilebilir olduğundan, bir BOLA veya kimlik-doğrulamasız uç nokta anında otomatik, kütlesel sızdırmaya açılır. Optus'ta bu, tek scriptle 9.8M kayıttı.
• Bütüncül başarısızlık. Tek bir açık nadiren tek başına felakettir; ama Optus'ta olduğu gibi temel kontrollerin hepsi eksikse, küçük kusurlar bir "domino"ya dönüşür (UpGuard'ın deyimiyle). Her katman ayrı bir savunma fırsatıydı.
• Görünmezlik ve unutulmuşluk. Shadow/eski API'ler izlenmediğinden, oradaki bir açık aylarca fark edilmeden sömürülür (Optus'un ikincil domain'i yıllarca açıktı).
• Sofistike gerektirmez. Çoğu API ihlali "gelişmiş" değildir; kimlik doğrulamasız uç nokta + sıralı ID + rate limit yokluğu, bir okul çocuğunun yazabileceği curl scriptiyle sömürülür.

Araştırmacının çerçevesi: (a) uç nokta authN gerektiriyor mu, (b) nesne-düzeyi (BOLA) ve fonksiyon-düzeyi (BFLA) yetki var mı, (c) yanıt minimal mi, (d) rate limit var mı, (e) envanterde mi (yoksa shadow mı). Savunma bu katmanların hepsini uygular.

---

8. Güvenli Kod

Her katmanı uygulayan REST API:

<?php
// ✅ GÜVENLİ — katmanlı API güvenliği
declare(strict_types=1);

// GET /api/users/{id}
Route::get('/api/users/{id}', function (Request $req, int $id) {
    // 1) authN: token doğrula (Böl. 23/24) — middleware
    $current = $req->user();                      // kimliği doğrulanmış kullanıcı

    // 2) authZ: BOLA — bu nesne bu kullanıcının mı? (Böl. 15)
    $user = User::findOrFail($id);
    if ($user->id !== $current->id && !$current->isAdmin()) {
        abort(403);
    }

    // 3) Çıktı DTO — data minimization (yalnızca gerekli alanlar; API3)
    return response()->json([
        'id'    => $user->id,
        'name'  => $user->name,
        'email' => $user->email,
        // pass_hash, is_admin, iç bayraklar ASLA döndürülmez
    ]);
})->middleware(['auth:api', 'throttle:60,1']);    // 4) rate limit (API4)

// POST /api/users/{id} — mass assignment + BFLA savunması
Route::post('/api/users/{id}', function (Request $req, int $id) {
    $current = $req->user();
    $user = User::findOrFail($id);

    // BFLA: fonksiyon-düzeyi yetki (Böl. 14)
    if ($user->id !== $current->id && !$current->isAdmin()) {
        abort(403);
    }

    // Mass assignment savunması: yalnızca beyaz-listeli alanlar (Böl. 4)
    $data = $req->validate([
        'name'  => 'sometimes|string|max:100',
        'email' => 'sometimes|email',
        // 'role'/'is_admin' KABUL EDİLMEZ — sunucu belirler
    ]);
    $user->update($data);
    return response()->json(['status' => 'ok']);
})->middleware(['auth:api', 'throttle:30,1']);

Envanter ve versiyonlama (API9) — kod dışı ama kritik:

- Tüm API'lerin envanteri: host, path, method, kimlik doğrulama, veri sınıfı
- Eski versiyonları/domain'leri devre dışı bırak (Optus'un unutulmuş domain'i)
- OpenAPI/Swagger ile belgele; otomatik keşif + izleme (Böl. 31)
- Test/staging API'leri internete AÇMA

Öne çıkan modern kalıplar: - Her uç noktada authN + BOLA + BFLA: Kimlik doğrula (Bölüm 23/24), nesne-düzeyi (Bölüm 15) ve fonksiyon-düzeyi (Bölüm 14) yetkiyi ayrı ayrı uygula. - Çıktı DTO / serializer (data minimization): Ham modeli asla döndürme; açık bir çıktı sözleşmesiyle yalnızca gerekli alanları ver. Aşırı ifşayı (API3) kapatır. - Girdi beyaz listesi (mass assignment): validate ile yalnızca izinli alanları kabul et; role/is_admin sunucuda belirlenir (Bölüm 4). - Rate limiting (API4): throttle middleware; numaralandırma/kaba kuvvet/DoS'u sınırla. "Low and slow" için izlemeyle birleştir. - API envanteri + versiyon yönetimi (API9): Güncel envanter; eski/shadow API'leri kapat; test API'lerini izole et. - Güvenli kimlik: OAuth2/OIDC/JWT (Bölüm 23, 24) doğru uygulanmış. - İzleme (Bölüm 31): Anormal istek hacmi, numaralandırma kalıpları, kimlik-doğrulamasız hassas veri akışı için alarm.

---

9. Patch Analizi

Neden işe yarar? Her katman bir OWASP API riskini kapatır ve birlikte bütüncül savunma oluştururlar: authN kimlik-doğrulamasız erişimi (API2), BOLA kontrolü nesne numaralandırmayı (API1), BFLA fonksiyon istismarını (API5), çıktı DTO aşırı ifşayı (API3), girdi beyaz listesi mass assignment'ı (API3), rate limiting kütlesel sızdırmayı (API4), envanter yönetimi shadow API'leri (API9) kapatır. Optus'ta bu katmanlardan herhangi biri olsaydı ihlal ya önlenir ya da çok daha küçük kalırdı — bu, derinlemesine savunmanın (Bölüm 1) canlı kanıtıdır.

Aşırı ifşa — DTO neden kritik: "İstemci filtreler" varsayımı, güven sınırını yanlış yere koyar (Bölüm 1). Ham model döndürmek, bugün zararsız görünen bir alanın (yarın eklenen is_admin) sessizce sızmasına yol açar. Açık çıktı sözleşmesi, "varsayılan olarak gizli" (deny by default, Bölüm 14) ilkesini veriye uygular.

Alternatiflerin karşılaştırması:

Konu	Yanlış	Doğru
Nesne erişimi	find($id)	BOLA kontrolü / scope-to-user (Böl. 15)
Yanıt	Ham model (toArray)	Açık çıktı DTO
Girdi	fill($request->all())	Beyaz-listeli validate (Böl. 4)
İstek hacmi	Sınırsız	Rate limiting + izleme
Eski API	Unutulmuş, açık	Envanter + devre dışı bırakma

Performans: Yetki kontrolleri ve DTO dönüşümü ihmal edilebilir maliyettir; rate limiting hafif bir sayaç. Bu kontroller performansı düşürmez, aksine kötüye kullanımı engelleyerek kaynakları korur.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir fintech mobil uygulaması API'si. /api/accounts/{id}/transactions uç noktası, kimlik doğruluyor (API2 tamam) ama nesne-düzeyi yetki (BOLA) uygulamıyor: giriş yapmış herhangi bir kullanıcı, id'yi değiştirerek başka hesapların işlem geçmişine erişiyor. Ayrıca yanıt, iç risk skorlarını ve tam kart numaralarını içeriyor (aşırı ifşa) ve rate limiting yok. Bir saldırgan, kendi geçerli token'ıyla hesap kimliklerini numaralandırıp milyonlarca müşterinin finansal verisini topluyor — Optus'un fintech versiyonu. Dersler: (1) kimlik doğrulama tek başına yetmez; her nesne erişiminde BOLA kontrolü şart (Bölüm 15); (2) yanıt minimal olmalı (DTO); (3) rate limiting + izleme, numaralandırmayı yavaşlatıp yakalar.

---

11. Gerçek Vaka Analizi — Optus API İhlali (2022, ~9.8 milyon kayıt)

OAIC/Optus açıklamaları, Jeremy Kirk (Information Security Media Group) röportajları, UpGuard, Security Boulevard ve OWASP API analizleriyle doğrulanmıştır. OWASP API Top 10'un tek olayda somutlaştığı vakadır.

Özet. Eylül 2022'de Avustralya'nın ikinci büyük telekom şirketi Optus'ta, kimlik doğrulamasız ve internete açık bir API uç noktası aracılığıyla yaklaşık 9.8 milyon mevcut/eski müşterinin verisi sızdırıldı: ad, doğum tarihi, telefon, e-posta, adres; ~2.1 milyon kişi için ehliyet, pasaport (~150.000) ve Medicare (~50.000) gibi kimlik belgeleri. Saldırgan ("Optusdata") 1 milyon dolar fidye istedi ve 10.000 kaydı sızdırdı. Sonuç: OAIC soruşturması, toplu dava ve Avustralya'da düzenleyici reform.

Teknik neden — OWASP API Top 10'un "domino"su. İhlal tek bir kusurdan değil, temel kontrollerin hepsinin birden eksikliğinden doğdu: 1. Kimlik doğrulamasız uç nokta (API2). Müşteri destek API'si (/users/{id} benzeri, contactid tabanlı) kimlik doğrulama gerektirmiyordu. Gazeteci Jeremy Kirk'ün saldırganla görüşmesine göre, kimlik bilgisi olmadan bir curl isteği yeterliydi. 2. Sıralı, tahmin edilebilir kimlikler → BOLA (API1). Müşteri kimlikleri 5332, 5333, ... gibi birer birer artıyordu. Saldırgan tahmin etmeye bile gerek duymadan hepsini döngüledi. (Bölüm 15: tamsayı birincil anahtarlar numaralandırılabilir.) 3. Rate limiting yok (API4). Milyonlarca istek engellenmeden atılabildi; saldırgan dönen IP'lerle ayak izini de azalttı. 4. Aşırı veri ifşası (API3). Uç nokta, tam hassas müşteri kaydını döndürüyordu. 5. Unutulmuş/shadow API (API9). 2018'deki bir kodlama hatası erişim kontrollerini zayıflatmıştı; Optus bunu ana domain'de Ağustos 2021'de düzeltti ama yedek/ikincil API domain'inde (api.www...) düzeltmedi — bu domain en az 2017'den beri internete açıktı ve gözden kaçtı. "Göremediğini koruyamazsın."

Bu beş kusur bir "domino yığını" oluşturdu (UpGuard): saldırganın tek yapması gereken onu bulup itmekti. Optus "sofistike saldırı" dese de, analistlerin ve hükümetin ortak görüşü "pencerenin açık bırakıldığıydı" — sömürü, bir okul çocuğunun yazabileceği düzeyde bir scriptti.

Etki. ~9.8 milyon kayıt (Avustralya tarihinin en büyük ihlallerinden); ~2.1 milyon kimlik belgesi; pasaport/ehliyet değişim maliyetleri, kredi izleme, toplu dava, ve ulusal düzeyde gizlilik/telekom düzenleme reformları.

Çıkarılacak dersler: 1. API güvenliği bütüncüldür. Tek bir kontrol değil, authN + BOLA + rate limit + data minimization + envanterin hepsi gerekir; biri bile domino'yu kırardı. 2. Sıralı kimlikler + eksik yetki = kütlesel BOLA. Nesne-düzeyi yetki (Bölüm 15) ve öngörülemez kimlikler birlikte. 3. Shadow/unutulmuş API'ler ölümcüldür (API9). Envanter tutulmalı; eski/yedek domain'ler ve test API'leri kapatılmalı/izole edilmeli. 4. İzleme kritik. Milyonlarca isteklik anormal hacim, API-farkında izlemeyle (Bölüm 31) forum paylaşımından çok önce yakalanabilirdi.

---

12. Detection

Kod incelemede: Her uç noktada authN/BOLA/BFLA/DTO/rate-limit varlığını arayın:

grep -rnE 'Route::(get|post|put|delete)' src/ | grep -v middleware   # korumasız rota?
grep -rnE '::find\(|->find\(' src/ | grep -vi 'auth\|owner\|current'  # BOLA adayı
grep -rnE 'toArray\(\)|->all\(\)|json\(\$' src/   # aşırı ifşa / mass assignment
grep -rn  'throttle\|RateLimiter' src/            # rate limit var mı?

Kontroller: authN middleware var mı? Nesne sahiplik kontrolü (BOLA)? Fonksiyon yetki (BFLA)? Çıktı DTO mu ham model mi? Rate limit? Envanterde mi?

SAST: Eksik yetki (CWE-862/863), aşırı ifşa (CWE-213), mass assignment (CWE-915) için kurallar. API-özgü araçlar korumasız/dokümantasyonsuz uç noktaları işaretler.

DAST/API tarama: Çok-hesaplı BOLA testi (Bölüm 15), kimlik-doğrulamasız uç nokta taraması, aşırı ifşa (yanıttaki fazla alanlar), rate limit testi. OpenAPI/Swagger'dan otomatik test üretimi.

Loglar/SIEM — Optus'ta atlanan sinyaller: Tek kaynağın sıralı nesne kimliklerine kütlesel erişimi (BOLA numaralandırma imzası); anormal istek hacmi (milyonlarca); kimlik-doğrulamasız uç noktalardan hassas veri akışı; ve shadow API keşfi (envanterde olmayan host/path'lere trafik). API-farkında izleme (Bölüm 31) en güçlü savunmadır; dönen IP'lere karşı toplam hacim ve "low and slow" kalıpları için ML/anomali kullanılır.

---

13. Prevention

• Her uç noktada authN (Bölüm 12, 23, 24): İstisnasız; test/legacy uç noktalar dahil.
• BOLA (Bölüm 15): Her nesne erişiminde sahiplik/yetki; öngörülemez kimlikler ek katman.
• BFLA (Bölüm 14): Fonksiyon-düzeyi yetki; UI gizleme güvenlik değil.
• Data minimization (DTO): Ham model döndürme; açık çıktı sözleşmesi.
• Mass assignment savunması (Bölüm 4): Girdi beyaz listesi.
• Rate limiting (API4): Numaralandırma/kaba kuvvet/DoS'a karşı + izleme.
• API envanteri + versiyon yönetimi (API9): Güncel envanter; eski/shadow/test API'leri kapat/izole et.
• Güvenli konfigürasyon (Bölüm 26, 27): TLS, güvenli hata yönetimi (iç yapı sızdırma).
• İzleme (Bölüm 31): API-farkında anomali tespiti.

---

14. Mitigation

• Acil: Kimlik-doğrulamasız/korumasız uç noktaları kapat veya authN ekle; BOLA kontrolü ekle; rate limiting devreye al; unutulmuş/shadow domain'leri kaldır.
• Geçici: Loglardan numaralandırma/sızdırma kapsamını belirle; etkilenen kullanıcıları bildir (yasal yükümlülük); aşırı ifşa eden yanıtları DTO'ya indir.
• Kalıcı: Tüm uç noktalara katmanlı kontrolleri uygula; API envanteri + otomatik keşif kur; API-farkında izleme ekle; CI'a API güvenlik testleri (BOLA, authN) al.

---

15. Checklist

• [ ] Her uç nokta (test/legacy dahil) kimlik doğrulama gerektiriyor mu (API2)?
• [ ] Her nesne erişimi BOLA kontrolünden geçiyor mu (API1, Bölüm 15)?
• [ ] Fonksiyon-düzeyi yetki (BFLA) uygulanıyor mu (API5, Bölüm 14)?
• [ ] Yanıtlar açık DTO ile mi (ham model/toArray değil — API3)?
• [ ] Girdi beyaz-listeli mi (mass assignment yok — Bölüm 4)?
• [ ] Rate limiting var mı ve izlemeyle birleştirilmiş mi (API4)?
• [ ] Güncel bir API envanteri var; eski/shadow/test API'ler kapalı mı (API9)?
• [ ] Öngörülemez nesne kimlikleri ek katman olarak kullanılıyor mu?
• [ ] Hata yanıtları iç yapıyı sızdırmıyor mu?
• [ ] API-farkında anomali izleme kurulu mu (Bölüm 31)?

---

16. Laboratuvar

Lab 22.1 — BOLA numaralandırma. İzole ortamda iki hesaplı, sıralı kimlikli bir /api/users/{id} uç noktası kur; bir hesapla diğerlerinin verisine id'yi artırarak eriş. BOLA kontrolü (scope-to-user) ekleyip kapat.

Lab 22.2 — Aşırı ifşa. Ham modeli (toArray) döndüren bir uç nokta yaz; yanıtta pass_hash/is_admin gibi alanların sızdığını gözlemle. Açık DTO'ya geçip yalnızca gerekli alanları döndür.

Lab 22.3 — Rate limiting. Rate limit'siz bir uç noktaya hızlı ardışık istekler atıp numaralandırmanın serbest olduğunu gözlemle. throttle ekleyip farkı gör; "low and slow" için izlemenin neden gerektiğini yaz.

Lab 22.4 — Envanter/shadow. Bir /v1/ (eski, korumasız) ve /v2/ (korumalı) uç nokta kur; saldırganın eski versiyonu tercih edeceğini göster. Eski versiyonu kapatıp envanterin önemini açıkla.

---

17. Quiz

1. API güvenliği neden ayrı bir disiplindir? API'ler klasik açıkları hangi üç şekilde yoğunlaştırır?
2. BOLA nedir ve hangi önceki bölümle (IDOR) aynıdır? Neden API'nin 1 numaralı riskidir?
3. BFLA nedir ve hangi bölümle (fonksiyon-düzeyi yetki) ilişkilidir?
4. Aşırı veri ifşası (API3) nedir? "İstemci filtreler" varsayımı neden yanlıştır?
5. Çıktı DTO / data minimization neden güven sınırını doğru yere koyar?
6. Rate limiting (API4) hangi saldırıları sınırlar? "Low and slow" neden izleme gerektirir?
7. Shadow/unutulmuş API (API9) neden özellikle tehlikelidir? Optus'ta bu nasıl rol oynadı?
8. Optus ihlalinde hangi OWASP API riskleri bir araya geldi? Hangisi tek başına domino'yu kırardı?
9. Sıralı tamsayı kimlikler BOLA'yı nasıl büyütür (Bölüm 15'e atıfla)?
10. Mass assignment (Bölüm 4) API bağlamında nasıl görünür?
11. Neden "kimlik doğrulama var" API'yi güvenli yapmaz (BOLA açısından)?
12. API-farkında izleme (Bölüm 31), Optus'ta neyi erken yakalayabilirdi?

---

18. Kaynakça

• OWASP, API Security Top 10 (2023) — API1 BOLA, API2 Broken Authentication, API3 BOPLA, API4 Unrestricted Resource Consumption, API5 BFLA, API9 Improper Inventory Management.
• MITRE, CWE-639 (BOLA), CWE-862/863 (yetki), CWE-213 (aşırı ifşa), CWE-915 (mass assignment), CWE-770 (kaynak sınırı).
• Jeremy Kirk / Information Security Media Group, Optus saldırgan röportajları; UpGuard, How Did the Optus Data Breach Happen?; Security Boulevard, Optus — Why Vulnerable APIs are to Blame.
• OAIC ve Optus resmî açıklamaları; Terem, Optus API Hack Analysis.
• Laravel API Resources (DTO), Rate Limiting, Authorization; Symfony Serializer/Security dokümantasyonu.