BOLA (IDOR) Nedir? API'lerde Kırık Yetkilendirmeyi Kapatma Rehberi

Özet

OWASP API Security Top 10 listesinin zirvesi yıllardır değişmiyor: BOLA — Broken Object Level Authorization, eski adıyla IDOR. Saldırganın başkasına ait bir kayda, siparişe veya belgeye tek bir ID değiştirerek erişmesidir. Ne sıfırıncı gün açığı gerekir ne de özel araç: tarayıcı yeterli.

Bu yazıda BOLA'yı bir örnek senaryoyla anlatıp nasıl test edileceğini ve kalıcı olarak nasıl kapatılacağını adım adım gösteriyoruz.

Yazar: Aras Akyasan · Eylül 2026 · 10 dk okuma

Örnek senaryo: bir rakamla başkasının faturası

Kullanıcı kendi faturasını şu adreste görüntülüyor: /api/invoices/4821. Adresteki sayıyı 4822 yapıyor ve — yetkilendirme nesne düzeyinde denetlenmiyorsa — başka bir müşterinin faturası ekrana geliyor. Kimlik doğrulama çalışıyor, kullanıcı giriş yapmış; eksik olan tek şey “bu nesne gerçekten sana mı ait?” sorusu.

Saldırının sessizliği tehlikeyi büyütür: loglarda normal bir GET isteği gibi görünür, hız limiti tetiklemez, WAF imzası yoktur. Çoğu BOLA vakası bu yüzden aylarca fark edilmez.

Neden olur? 3 kök neden

Birincisi, yetkilendirmenin yalnızca arayüzde yapılması: buton gizlenir ama API uçta kontrol yoktur. İkincisi, tahmin edilebilir tanımlayıcılar: artan sayılar, UUID olmayan kısa kodlar. Üçüncüsü, toplu uçların unutulması: tekil kayıt korunur ama /api/invoices?user_id= başkasının ID'siyle aynı veriyi verir.

• ✓Arayüzde gizlemek ≠ API'de korumak
• ✓Artan sayı / tahmin edilebilir ID kullanımı
• ✓Toplu listeleme ve dışa aktarma uçlarının denetimsizliği

Nasıl test edilir? 4 adımlı kara kutu yöntemi

İki farklı kullanıcı hesabı açın (A ve B). A hesabıyla bir nesne oluşturun, ID'sini not edin. B hesabıyla aynı ID'ye istek atın: veri dönüyorsa BOLA var demektir. Ardından A'nın ID'sini birer birer artırıp azaltarak komşu kayıtları yoklayın.

Sonra toplu uçları deneyin: filtre, sıralama ve sayfalama parametrelerine başka kullanıcıya ait değerler verin. En çok atlanan yer burasıdır — tekil uç test edilip toplu uç unutulur.

Kalıcı kapatma: 4 savunma katmanı

Birinci katman: her nesne erişiminde sunucu tarafında sahiplik kontrolü — “giriş yapmış olmak” yeterli değildir, “bu nesnenin sahibi olmak” gerekir. İkinci katman: doğrudan nesne referansı yerine oturuma bağlı dolaylı referanslar (rastgele, tahmin edilemez anahtarlar) kullanın.

Üçüncü katman: yetkilendirme testlerini otomasyona bağlayın — her release'te BOLA prob seti çalışsın. Dördüncü katman: nesne erişimlerini kim-kime-ne zaman formatında loglayın; toplu ve olağandışı erişim örüntülerini alarmlayın.

Kontrol listesi: yayınlamadan önce

Yeni bir API ucu yayına girerken bu beş soruya “evet” cevabı verin. Bir tanesi bile “hayır” ise uç yayına çıkmamalıdır.

• ✓Her uçta nesne düzeyinde sahiplik kontrolü var mı?
• ✓ID'ler tahmin edilemez mi (rastgele, yeterli entropi)?
• ✓Toplu listeleme uçları aynı denetime tabi mi?
• ✓Yetkisiz erişim denemeleri loglanıp alarmlanıyor mu?
• ✓CI hattında otomatik BOLA prob seti çalışıyor mu?

Son söz

BOLA, kapatması en ucuz ama patladığında en pahalı API zafiyetidir. Bir öğleden sonra ayıracağınız sahiplik denetimi taraması, aylar sürecek bir veri ihlali açıklamasından her zaman ucuzdur.

API envanterinizi ve BOLA durumunuzu ücretsiz ön değerlendirmede birlikte çıkarabiliriz — Türkiye'nin ilk yerli ve milli DAST'ı Limma'nın IDOR dedektörü de bu testleri her release'te otomatik tekrarlar.

Sık sorulan sorular

İlgili hizmetler

Diğer yazılar