API 5:2023 — Broken Function Level Authorization 🔓: Unseen Authorizations, Critical Threats

API’ler, dijital dönüşümün hızlandığı günümüzde yazılım sistemlerinin fonksiyonlarını dış dünyaya açan en kritik bileşenler haline geldi. Microservices architectures, multi-layer applications ve multi-platform strategies gibi modern yaklaşımlar, API’leri sistemin merkezine yerleştiriyor.

Bu büyüme sadece operasyonel avantajlar sağlamıyor, aynı zamanda yeni ve karmaşık security risk’lerini de beraberinde getiriyor.

💡 Peki, Authentication ve Access Control zaten uygulanıyorsa, ayrıca Function Level Authorization için özel bir güvenlik yaklaşımına ihtiyaç var mı?

🛠 Sorunun Temeli

• Authentication: Kullanıcının kimliğini doğrular.
• Access Control Lists (ACL): Belirli kaynaklara kimin erişebileceğini sınırlar.

Ancak Broken Function Level Authorization (BFLA), “Who?” sorusundan çok “What can they do?” sorusuna odaklanır.

Yanlış veya eksik yapılandırılmış role-, group-, hierarchy-based authorization policies, saldırganların yetkileri dışında kalan API functions’a erişmesine olanak tanır. Bu açıklar genellikle business logic’in derinliklerinde gizlidir ve yüzeysel testlerle tespit edilmesi zordur.

🚨 Saldırı Senaryosu

Penetration Testing sırasında tipik bir BFLA tespiti şu şekilde olabilir:

1. Test kullanıcısı normal user role ile giriş yapar.
2. API endpoint haritası, Swagger/OpenAPI dokümantasyonundan veya fuzzing ile çıkarılır.
3. Sadece admin role’ünün erişmesi gereken /admin/deleteUser endpoint’i tespit edilir.
4. User token ile şu istek gönderilir:

DELETE /admin/deleteUser?id=42 HTTP/1.1
Host: target.com
Authorization: Bearer <user_token>

📍 Eğer backend tarafında function level authorization check yoksa, sistem bu işlemi HTTP 200 ile onaylayabilir.

Bu, WAF veya API Gateway seviyesinde genellikle “allowed request” olarak görülür çünkü request formatı geçerlidir, ancak iş mantığı ihlal edilmiştir.

📄 API Documentation ve Reconnaissance

Saldırganlar için API documentation (Swagger, OpenAPI) altın değerindedir:

• Function map çıkarılabilir.
• Endpoint’ler üzerinde brute-force yerine hedefli test yapılabilir.
• Gizli veya sadece belirli rollere açık fonksiyonlar keşfedilebilir.

🛡 Sorun şu ki klasik WAF ve API Gateway genellikle:

• Request context’ini anlamaz.
• User role ile function’ı eşleştirmez.
• Function access logic’ini analiz etmez.

🔍 Function Level Authorization’ın Kritik Rolü

Function level authorization:

• Yalnızca erişim izni değil,
• Hangi functions’ın, hangi koşullarda, hangi role’ler tarafından çalıştırılabileceğini tanımlayan security layer’dır.

Modern API security solutions şunları yapmalıdır:

• Her API call’u role–function relationship içinde değerlendirmek.
• Role-Based Access Control (RBAC) politikalarını enforcement etmek.
• Business logic validation adımlarını her fonksiyon çağrısında uygulamak.

🧩 Entegre Güvenlik Mimarisi

BFLA riskini minimize etmek için:

• Authentication ✅
• ACL ✅
• API Gateway policies ✅
• Function level authorization checks ✅
• Runtime API Security ✅

Hepsi entegre bir security architecture içinde çalışmalıdır. Eksik olan her parça, authorization flaws için bir saldırı yüzeyi yaratır.

💡 Önerilen Stratejiler

1. Role-Based Access Control (RBAC) → Yetkileri role bazlı tanımlayın.
2. Permission Matrix → Fonksiyon-rol eşlemesini dokümante edin.
3. Function-Based Test Scenarios → Farklı rollerle tüm fonksiyonları test edin.
4. Security in Depth → WAF + API Gateway + Runtime API Security katmanlı koruma kullanın.

📊 Sonuç

BFLA, OWASP API Top 10:2023’te yer alan ve en çok gözden kaçan zafiyetlerden biridir.

Artık sadece giriş kapısını kilitlemek yetmez:

• Kim, hangi functions’ı çağırıyor?
• Hangi operations yapılıyor?
• Bu işlemler system integrity’yi nasıl etkiliyor?

Modern attacks hedefli, layered ve sophisticated olduğu için defense mechanisms da aynı derecede kapsamlı, bağlamsal (context-aware) ve sürekli aktif olmalıdır.

Tunahan Balcı | @Apifort Api Security | Apifort