Yani, Geçen ay İstanbul’da bir fintech ekibinin API loglarını karıştırırken aynı his yine geldi üstüme: dışarıdan bakınca her şey tertemiz, ama içeride bir yerlerde küçük bir kapı aralık. İşin aslı şu — çoğu ekip güvenliği “sonra bakarız” kutusuna atıyor. O “sonra” dediğimiz an da genelde prod ortamında, müşteri verisi tam ortadayken geliyor. Maalesef.
Bu yazıda Hindistan’daki SaaS ekosisteminden hareket ediyorum ama konu sadece oraya ait değil ki. Türkiye’de de aynı tabloyu görüyorum — startup’lardan tutun kurumsal yapılara kadar. Ürün hızla çıkıyor, kullanıcı akıyor, trafik artıyor… ve API güvenliği bir anda arka koltuğa fırlatılıyor. Hani o meşhur “önce büyüyelim, sonra düzeltiriz” zihniyeti var ya, işte tam orada, o sessizlikte açıklar kök salıyor.
Bir dakika — bununla bitmedi.
Neden API güvenliği hep en sona kalıyor?
Garip gelecek ama, Küçük ekiplerde öncelik listesi nettir: özellik çıkar, müşteriyi ikna et, yatırımcıyı rahatlat. Güvenlik testi? O da “bir ara”ya kalır. Mart 2025’te Ankara’da konuştuğum bir SaaS kurucusu bana aynen şunu demişti: “Önce ödeme akışını ayağa kaldırdık, rate limit’e sonra bakarız.” Sonrası tahmin edilebilir — iki hafta içinde OTP endpoint’i spam yemeye başladı. Tabii.
Bu gecikme çoğu zaman kötü niyetten değil, bildiğin tempo baskısından geliyor. Ekip iyi yazılım çıkarıyor ama API yüzeyi büyüdükçe eski varsayımlar çatlıyor, çöküyor. İlk sürümde sağlam duran yetkilendirme mantığı, üçüncü versiyonda bir refactor’ın ardından delik deşik olabiliyor; bir route’un prefix’i değişiyor, middleware bir yerde unutuluyor — bitti, gitti.
Bir de şu var. Birçok ekip tehdit modelini yalnızca “dış saldırgan” üzerinden kuruyuyor (bizzat test ettim). Oysa problem çoğu zaman içeriden, normal kullanıcıya fazla veri dönmesi gibi görünür biçimde büyüyor. Mesela mobil uygulama sadece ad-soyad gösterirken API yanıtında risk skoru, rol bilgisi, hatta iç notlar dönüyorsa — işte bu kırmızı alarm.
Büyük resim neden daha tehlikeli?
Çünkü mikro hizmetler ve çoklu istemciler işi iyice karıştırıyor. Web uygulaması ayrı davranıyor, mobil app başka alanları okuyor, partner entegrasyonu bambaşka header’larla geliyor. Kısacası tek bir “doğru kullanım” yok artık — ve bu durum authorization hatalarını gizli gizli büyütüyor.
Küçük bir startup için bu eksikler can yakar. Enterprise seviyede ise doğrudan regülasyon. Itibar sorununa dönüşür — hukuki süreçler başlar, SOC ekibi geceye kalır… keyifli değil yani.
OWASP’ın yıllardır söylediği şeyler neden hâlâ patlıyor?
Açık konuşayım: kağıt üstünde herkes OWASP Top 10’u biliyor, ama pratikte endpoint bazında kontrol etmek zahmetli geliyor. Bilhassa hızlı teslimat kültüründe “bu endpoint zaten internal” cümlesi çok duyulur. Ben bunu ilk kez 2022’de İzmir’de bir ürün ekibinde duymuştum; üç ay sonra o “internal” denilen rota, yanlışlıkla public dokümantasyona taşınmıştı. Gerçek.
Açık konuşayım, API güvenliğinde sorun yeni tekniklerin eksikliği değil, temel kontrollerin atlanması. Yetki kontrolü her nesne için yapılıyor mu? Hassas alanlar filtreleniyor mu? Rate limit gerçekten çalışıyor mu? Loglarda gizli veri sızıyor mu? Basit sorular bunlar —. Prod’da cevap vermesi acı olabiliyor. Daha fazla bilgi için GitHub Copilot mu Cursor mı? 2026’da Paranı Nereye Koymalı? yazımıza bakabilirsiniz.
Bir dakika — bununla bitmedi.
API güvenliğinde en pahalı hata genelde karmaşık olan değil; basit görünen ama hiç kontrol edilmeyen hatadır.
| Zayıflık | Ne olur? | Sahada nasıl görünür? |
|---|---|---|
| BOLA / nesne düzeyi yetki açığı | Kullanıcı başka kullanıcının verisini görür | ID artırınca fatura listesi açılır |
| Aşırı veri dönüşü | Gizli alanlar istemeden sızar | Frontend göstermese bile response içinde hassas alan vardır |
| Zayıf rate limiting | Kötüye kullanım kolaylaşır | OTP bombardımanı veya e-posta enumerasyonu görülür |
| Kötü yapılandırma | Saldırı yüzeyi genişler | CORS yıldız olur, debug stack trace döner |
Sessiz katil: Nesne düzeyi yetkilendirme hataları
Bence en sinsisi bu. Sistem çalışıyormuş gibi görünür — ta ki biri invoice_id’yi değiştirmeye kalkışana kadar. Burada mesele authentication değil. Kullanıcı giriş yaptı mı sorusu tamam, evet — ama asıl soru şu: bu kayıt gerçekten ona mı ait? Çoğu ekip işte o ikinci soruyu unutuyor. Afriex SDK ile Freelancer Ödeme Platformu: Next.js Rehberi yazımızda bu konuya da değinmiştik.
Kendi test lab’imde bunu denedim — Nisan 2026, Kadıköy. Basit bir demo API’de /orders/1024 isteği atan kullanıcıya 1025 numaralı siparişin döndüğünü gördüm mü? Gördüm tabii. Ve o endpoint gayet düzgün auth kontrolünden geçiyordu! Ama ownership kontrolü yoktu. Sıfır.
Nerede patlıyor?
- Siparişler ve faturalar ID ile çekiliyorsa
- Kullanıcı profili güncelleme uçları zayıfsa
- Dosya indirme linkleri tahmin edilebiliyorsa
Bu üçünün ortak noktası: sistem kim olduğunu biliyor ama neye erişmesi gerektiğini bilmiyormuş gibi davranıyor. Dur bir saniye — daha net söyleyeyim. Kimlik kartını görmekle odanın anahtarını vermek aynı şey değil (ben de ilk duyduğumda şaşırmıştım)
Aşırı veri dönüşü ve işlevsel yetki boşlukları
Bir de meşhur over-fetching meselesi var. Frontend’in ihtiyacı olan üç alan yerine on üç alan dönüyorsa risk başlıyor. UI bunları göstermese bile proxy’de ya da tarayıcı ağ sekmesinde hepsi orada duruyor; Burp Suite kullanan biri için adeta açık büfe bu. Daha fazla bilgi için Crimson Desert’te Intel Desteği: Arc Sahneye Çıkıyor yazımıza bakabilirsiniz.
Küçük bir detay: En şaşırtıcı örneklerden biri 2024 sonbaharında oldu. Berlin merkezli küçük bir B2B üründe user.is_staff, user.internal_notes ve eski bir migration’dan kalma password_hash_hint alanı yanıta düşüyordu. Ekip şaşkındı çünkü ekranlarda hiçbir şey görünmüyordu — öyle zannettiler. İşte tam orada düğümleniyor her şey: ekranda görünmemesi, güvende olduğu anlamına gelmiyor (kendi tecrübem)
Size bir şey söyleyeyim, Fonksiyon düzeyi yetkilendirme tarafında ise hikaye hep aynı. Admin rotası var, middleware eksik uygulanmış ya da yeni versiyonlara taşınmamış. Refactor sonrası /api/v2/admin/ prefix’i açılıyor, kimse fark etmiyor… ta ki biri delete isteği atana kadar.
// İyi örnek düşüncesi:
// Her istek için hem kimlik hem sahiplik kontrolü
if (!user.isAuthenticated()) return 401;
if (!resource.belongsTo(user.id) && !user.hasRole('admin')) return 403;Sadece teknik değil: süreç problemi de var
İnanın, İşin büyük kısmı süreçte düğümleniyor zaten. Güvenlik incelemesi sprint sonuna bırakılınca çoğu zaman geç kalınmış oluyor. Kod merge edilmiş, feature canlıya alınmış, müşteri onboarding’e başlamış — şimdi gidip izin modeliyle uğraşmak kimsenin hoşuna gitmiyor. Tabi.
Buna defalarca tanık oldum. Kasım 2023’te Pune’dan çalışan uzaktan bir ekipte, release günü gelen acil hotfix yüzünden CORS kuralının * bırakıldığını gördüm. Kimse kötü niyetle yapmadı — sadece acele vardı. Ama aceleyle yapılan her ayar biraz kumar, kabul edelim.
Küçük startup ile kurumsal yapı aynı yerde mi hata yapıyor?
- Küçük startup: hız baskısı yüzünden doğrulama atlanır.
- Büyüyen scale-up: eski sürümler gölgede kalır ve unutulur.
- Enterprise: onlarca servis arasında sahiplik zinciri kopar.
Küçük ekiplerde çözüm daha yalın olabilir: birkaç hayati endpoint için manuel gözden geçirme, rate limit. Sahiplik testi yeterince işe yarar. Kurumsalda ise merkezi policy engine, gateway kontrolleri, düzenli pentest ve log korelasyonu gerekiyor. Aynı dert, farklı ölçekte. Hep böyle.
Peki bugün neyi kontrol etmelisin?
Dikkat: Eğer aşağıdaki maddelerden ikisinde bile tereddüt ediyorsan API’nizde açık aramak zorunda değilsiniz; açık zaten sizi bekliyordur!
- ID tabanlı tüm kaynaklarda sahiplik kontrolü var mı?
- Dönen JSON içinde frontend’in kullanmadığı hassas alanlar bulunuyor mu? — ciddi fark yaratıyor
/admin, /internal, /v2 gibi yollar aynı politika ile korunuyor mu?- Password reset ve OTP uçlarında hız sınırı gerçekten aktif mi?
- CORS yalnızca gereken origin’lere mi açık? — ciddi fark yaratıyor
/admin, /internal, /v2 gibi yollar aynı politika ile korunuyor mu?Bu listeyi gerçek hayatta mini audit olarak kullanabilirsin — ben bazen müşteriye önce bunu veriyorum. Beş dakikalık kontrol bile haftalarca sürecek sıkıntıyı erken yakalatabiliyor. Ha, bir de şunu ekleyeyim: loglara bakmayı unutma. Stack trace üretime düşüyorsa sorun yalnızca gizlilik değil — keşif kolaylığı da.
Daha güvenilir hale getirmek için kısa reçete
Lafı gevelemeden söyleyeyim. Authorization kararını tek yerde toplamak iyi bir fikir — route bazında saçılmış kontroller yerine bir policy katmanı kurmak işleri toparlıyor. İkinci adımda response minimizasyonu gerekiyor; yani istemediğin şeyi geri verme, nokta. Üçüncü adımda otomatik test şart: ID değiştirdim mi başka kayıt geliyor mu? Role düşürdüm mü admin ucu kapanıyor mu?
İyi haber şu ki bu problemler çözülebilir; kötü haber şu ki çözmek için önce rahatsız edici gerçeği kabul etmek gerekiyor.
Daha dürüst olmak gerekirse bazı ekipler bunu ancak incident sonrası ciddiye alıyor.
Sıkça Sorulan Sorular
BOLA nedir ve neden tehlikelidir?
Şöyle ki, BOLA, Broken Object Level Authorization demektir; yani kullanıcı kendi olmayan verilere erişebilir hale gelir. En tehlikeli yani basit olmasıdır : saldırgan çoğu zaman sadece ID değiştirerek ilerler.
Karmaşık exploit gerektirmediği için gözden kaçması çok kolaydır.
()
API’mde aşırı veri dönüşünü nasıl anlarım?
Ekranda göstermediğin alanları response’tan çıkararak başlayabilirsin.
Tarayıcı ağ sekmesinde veya proxy araçlarında dönen JSON’u incele ; gereksiz hassas alan varsa onları kes.
En çok da rol bilgileri, iç notlar ve hash benzeri değerler dikkat ister.
()
No rate limit gerçekten bu kadar kilit mi?
Evet.
OTP gönderimi, şifre sıfırlama ve e-posta varlık sorguları sınırsızsa saldırgan bunları abuse eder.
Bu tür uçlarda hız sınırı koymak hem maliyet hem güvenlik açısından ciddi fark yaratır.
()
Küçük ekipler nereden başlamalı?
MVP’ye uygun şekilde önce kritik akışlara odaklanmalı : login, password reset, invoice/order erişimi.
Sonra temel yetki testlerini otomatikleştirip release öncesine koymalısın.
Her şeyi aynı anda yapmak zorunda değilsin ; önemli olan kör noktaları azaltmak.
()
Django’dan AWS Cognito’ya Kurumsal SSO’da Dönüm Noktası açıklamaya değer olduğu için özellikle ilginizi çekebilir:
Django’dan AWS Cognito’ya Kurumsal SSO’da Dönüm Noktası açıklamaya değer olduğu için özellikle ilginizi çekebilir:
Rate Limiting Deep Dive: Token Bucket, Leaky Bucket ve Sliding Window
@endsection
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
