Günümüzün dijital ekosisteminde uygulamalar artık monolitik yapılar değil; birbirine binlerce API (Application Programming Interface) ile bağlı mikro servisler bütünüdür. Mobil uygulamalardan IoT cihazlarına kadar her şey arka planda bir API ile konuşur. Ancak bu durum, saldırganlar için devasa ve genellikle zayıf korunan bir saldırı yüzeyi (Attack Surface) oluşturur. Geleneksel bir WAF, bir SQL Injection'ı engelleyebilir; ancak bir API'deki mantıksal yetkilendirme hatasını (BOLA) tespit etmesi neredeyse imkansızdır.

1. API Güvenliğinde "Kutsal Kase": BOLA (IDOR 2.0)

OWASP API Security Top 10 listesinin zirvesinde yer alan BOLA (Broken Object Level Authorization), modern API saldırılarının en yıkıcı olanıdır.

  • Sorun: API, kullanıcıdan gelen "ID" parametresine güvenir ve bu ID'nin o kullanıcıya ait olup olmadığını kontrol etmez.
  • Senaryo: /api/v1/orders/1001 adresine giden bir istekte 1001 değerini 1002 yaptığınızda, başka bir kullanıcının sipariş detaylarını görebiliyorsanız, sisteminizde BOLA zafiyeti var demektir.
  • Neden Tehlikeli? Bu bir yazılım hatası değil, bir mantık hatasıdır. Hiçbir otomatik tarayıcı bu yetkilendirme açığını tek başına bulamaz; manuel ve derinlemesine test gerektirir.

2. Mass Assignment: Beklenmedik Veri Girişleri

Modern yazılım frameworkleri (Node.js, Ruby on Rails vb.), gelen JSON verisini doğrudan veritabanı objesine eşlemeyi sever. Bu kolaylık, büyük bir güvenlik açığını beraberinde getirir.

  • Saldırı: Bir kullanıcı profilini güncellerken sadece name ve email göndermesi beklenirken, saldırgan isteğe "is_admin": true parametresini ekler.
  • Sonuç: Eğer API uç noktası (endpoint) hangi alanların güncellenebileceğini (Allow-list) kısıtlamamışsa, saldırgan kendisini saniyeler içinde yönetici yapabilir.

3. Shadow APIs ve Dokümantasyon Sızıntıları

Bir siber güvenlik araştırmacısı için en değerli hazine, unutulmuş veya iyi dökümante edilmemiş API uç noktalarıdır.

  • Shadow (Gölge) API: Geliştirme aşamasında unutulmuş, eski versiyon (v1, v2) veya test amaçlı açılmış ama kapatılmamış API'lardır. Genellikle güncel güvenlik yamalarından yoksundurlar.
  • Swagger/Postman Sızıntıları: /swagger.json veya /v1/api-docs gibi dizinler, saldırgana tüm API mimarisini, beklenen parametreleri ve yetkilendirme yöntemlerini bir harita gibi sunar. Keşif (Recon) aşamasında bu dökümanları bulmak, saldırının %50'sinin tamamlanması demektir.

4. JWT (JSON Web Token) Manipülasyonu

API'ların çoğunda kimlik doğrulama için kullanılan JWT, yanlış yapılandırıldığında birer "anahtar teslim" zafiyetine dönüşür:

  • Algoritma Karışıklığı: alg: RS256 (asimetrik) olan başlığı alg: HS256 (simetrik) yaparak token imzalamaya çalışmak.
  • None Algorithm: Bazı kütüphaneler alg: none ifadesini kabul ederek herhangi bir imza kontrolü yapmadan girişe izin verir.
  • Sensitive Data: Token içine şifrelenmemiş hassas verilerin (TCKN, Rol bilgisi vb.) koyulması.

5. Savunma Stratejisi: API Güvenlik Duvarı Yeterli mi?

API güvenliği "set and forget" (kur ve unut) bir yapı değildir. Proaktif bir savunma için şunlar şarttır:

  1. Sıkı Yetkilendirme (Strict RBAC/ABAC): Her istekte kullanıcı-obje ilişkisi doğrulanmalıdır.
  2. Rate Limiting ve Throttling: API'nızın brute-force veya DoS saldırılarıyla boğulmasını engellemek için istek limitleri koyun.
  3. Input Validation: Gelen her veriyi bir "kara kutu" olarak görün ve şema doğrulaması yapın.
  4. Logging & Monitoring: Olağandışı "403 Forbidden" veya "404 Not Found" trafiklerini izleyin; bu genellikle bir saldırganın endpoint keşfi yaptığının işaretidir.

API'lar Geleceğin Anahtarlarıdır

Modern siber güvenlikte "perimeter" (çevre) artık ağ duvarları değil, API uç noktalarıdır. API güvenliğine yatırım yapmayan bir kurum, arka kapısını açık bırakan bir kaleye benzer. Unutmayın; bir API'yi korumak için önce onun varlığından haberdar olmalı, sonra da her isteği en ince detayına kadar sorgulamalısınız.