Herkese Merhabalar. Bugün OWASP TOP 10-(Open Worldwide Application Security Project TOP TEN) listesinde 2 defa ard-arda (2021-2025) listenin en başında gelen Broken Access Control hakkında kısa bir bilgi vereceğim.
// Öncelikle OWASP TOP 10-(Open Worldwide Application Security Project) hakkında bilgisi olmayan üyeler için bilgi vereceğim:
OWASP Top 10, web ve API uygulamalarında en kritik güvenlik açıklarını sıralayan, uluslararası kabul görmüş bir referans listesidir. Güvenlik topluluğunun veri ve gözlemlerine dayanarak düzenli aralıklarla güncellenir; kurumlar, geliştiriciler ve denetçiler tarafından risk önceliklendirmesi ve farkındalık sağlama amacıyla sıkça kullanılır. Liste sonucları her 5 yıldan bir güncellenir.
——————————————————————————————————————————————————————————————————————————
A01:2025 - Broken Access Control
Tanım - Broken Access Control nedir?:
Broken Access Control, bir kullanıcının veya istemin erişmemesi gereken veri, sayfa veya işleme erişebilmesi durumudur. Kimlik doğrulama (kimin giriş yaptığı) ayrı; burada eksik veya yanlış olan şey “bu kimliğe hangi kapılar açılsın” sorusuna verilen yanıtın güvenilir olmamasıdır.
// OWASP bağlamı
OWASP Top 10:2025’te A01 olarak yer alan bu kategori, hem klasik yetki atlama örüntülerini hem de 2025’te içine dahil edilen bazı yeni ilişkilendirmeleri (ör. SSRF ile ilgili erişim-durumları) kapsar. Yani konu sadece “hesaplar arasında veri sızması” değildir; uygulama davranışının her katmanında “kim neye erişebilir” sorusunun tutarlı cevaplanamamasıyla ilgilidir.
// OWASP 2021 - 2025: Kısa tarihçe (Broken Access Control neden hala önde?)
OWASP 2021 sürümünde de Broken Access Control yüksek öncelikteydi; 2025 sürümünde ise kategori kapsamı daha da genişletilerek bazı ilişkilendirilen zafiyet tipleri (ör. SSRF) bu başlık altına alınmıştır. OWASP 2025 raporu, erişim kontrolüne ilişkin zafiyetlerin hâlâ yaygın ve yüksek etkili olduğunu, veri setlerindeki analizlerin bu durumu desteklediğini belirtir. Bu da A01’in listede korunmasının sebeplerindendir.
——————————————————————————————————————————————————————————————————————————
2. Görünüm: Broken Access Control uygulamada neye benzer?
Aşağıda, gerçek bir kullanıcı, ürün sahibi veya destek/operasyon ekibinin gözlemleyebileceği görsel ve davranışsal işaretler listelenmiştir:
1. Kullanıcı arayüzünde (UI) görünen işaretler
Beklenmeyen menü/bağlantılar: Normal bir kullanıcı hesabında görünmemesi gereken “Yönetici”, “Kullanıcıları Düzenle”, “Fatura Onayı” gibi menü öğelerinin görünmesi.
Erişim kontrolü sadece gizleme ile yapılmış: UI’da bazı düğme/alanlar gizleniyor ama URL doğrudan girildiğinde aynı sayfa/işlem erişilebiliyorsa (kullanıcı “görünürde” engellenmiş olsa bile).
“Düzenle” veya “Sil” butonunun görünmesi: Bir kaydın yanında herkes için aktif olan düzenleme/silme butonları — olması gerekenden fazla yetki verdiğine dair görünür ipucu.
Yanlış rol etiketleri: Profilde ya da kullanıcı bilgisi ekranında rol veya izinlerle ilgili tutarsız, çelişkili etiketlerin görünmesi (ör. normal kullanıcıda “Admin” yazıyor gibi).
2. URL / adres çubuğu görünümü
Tahmin edilebilir id/isimler: Adres çubuğunda ?id=123 veya /user/45 gibi açık, ardışık veya kolay tahmin edilebilen değerler göze çarpıyorsa — bu tek başına hatadır demek değildir ama eksik sunucu tarafı kontrolü varsa risk işaretidir.
Direkt erişimle ulaşılan gizli sayfalar: Kullanıcının görememesi gereken sayfa URL’leri (ör. /admin/...) doğrudan girildiğinde veya bir linkten ulaşılabildiğinde görünür olur.
3. Formlar / giriş alanları
Her kullanıcıya açık düzenleme alanları: Sadece sahibi tarafından düzenlenmesi gereken alanların herkese düzenlenebilir görünmesi.
Formda görünmeyen ama erişilebilir alanlar: Arayüzde gizlenen alanların tarayıcı üzerinden aktif hâle getirilebilmesi (görsel işaret olarak “gizli alanın varlığı”), istemci tarafı gizlemelerin yetki sağlamadığına dair ipucu verir.
4. Hata mesajları ve yanıt davranışları
Tutarsız hata/erişim mesajları: Aynı tür istek farklı kullanıcılardan geldiğinde farklı hata kodları veya mesajlar dönmesi (ör. bazen 200/OK bazen 403/Forbidden) bu tutarsızlık yetki kontrollerinin tutarsız uygulanıyor olabileceğine işaret edebilir.
Aşırı bilgi veren mesajlar: “Bu kaynağa erişmek için admin olmalısınız” gibi açık rol bilgilerinin sistem tarafından kullanıcıya gösterilmesi; bu tip mesajlar politikaların yanlış yerde uygulandığını gösterebilir.
5. Yönetim panelleri / dashboard’larda görünüm
Normal kullanıcının gördüğü yönetim widget’ları: Raporlar, kullanıcı listeleri veya yönetim sekmeleri normal kullanıcı görünümünde aktifse.
Filtrelenmemiş içerik: Dashboard’larda kullanıcıya özel olması gereken verilerin (örn. sadece kendi işlemleri) tümüyle görünüyor olması.
6. Operasyonel / destek tarafında görünen işaretler
Kullanıcı şikayetleri ve destek talepleri: “Benim görmemem gereken bir şey görüyorum” gibi geri bildirimler.
Loglarda ilginç erişimler: Aynı kaynağa farklı kullanıcı kimliklerinden erişim denemeleri; reddedilmiş ama ısrarla erişim talepleri (burada yine istismar adımı verilmez, sadece gözlem olarak belirtilir).
Beklenmeyen veri paylaşımı: Raporlama veya export işlevlerinin beklendiği gibi filtrelenmemiş veri döndürmesi.
// Görünüm örneği:
Kullanıcı A, profil sayfasında sadece kendi bilgilerini görmesi gerekirken ana menüde “Kullanıcı Listesi” linki belirmiş gibi görür. Linke tıklamasa bile adres çubuğunda /users yazdığında bir kullanıcı listesi ekranı açılabiliyorsa, bu “arayüzde yetki kısıtlamasının sadece saklama/gizleme ile yapıldığı”na dair net bir görsel ipucudur. Özet: arayüzde görünmeyen şeyler sunucu tarafında da engellenmiyorsa problem vardır.
// Görünümle ilgili sık rastlanan yanlış anlamalar
“Eğer bir düğme görünmüyorsa erişim yoktur.” — Yanlış. Sadece UI’da düğmenin gizlenmesi erişimi sağlamaz; sunucu tarafı denetimi olmalıdır.
“Hata mesajı veriliyorsa sistem güvenli.” — Hata mesajlarının olması değil; hataların ve erişim kontrolünün tutarlı olması önemlidir. Tutarsız mesajlar tersine sorun işaretidir.
——————————————————————————————————————————————————————————————————————————
3. Hangi takımlar / roller bu görünümden etkilenir?
Ürün/UX ekipleri: Kullanıcı arayüzünde ne gösterildiğine karar verirken yetki sınırlarını net tanımlamalı.
Geliştiriciler: UI ve sunucu tarafı kontrollerin paralel, tutarlı olmasını sağlamalı.
Operasyon/Support: Kullanıcı raporları ve loglar üzerinden belirtileri erken fark edip eskalasyon yapmalı.
Hukuk & Uyumluluk: Görünen hata ve veri sızıntıları mevzuat açısından risk değerlendirmesi gerektirir.
——————————————————————————————————————————————————————————————————————————
Detaylı bilgi için göz ata bilirsiniz: Broken_Access_Control
// Öncelikle OWASP TOP 10-(Open Worldwide Application Security Project) hakkında bilgisi olmayan üyeler için bilgi vereceğim:
OWASP Top 10, web ve API uygulamalarında en kritik güvenlik açıklarını sıralayan, uluslararası kabul görmüş bir referans listesidir. Güvenlik topluluğunun veri ve gözlemlerine dayanarak düzenli aralıklarla güncellenir; kurumlar, geliştiriciler ve denetçiler tarafından risk önceliklendirmesi ve farkındalık sağlama amacıyla sıkça kullanılır. Liste sonucları her 5 yıldan bir güncellenir.
——————————————————————————————————————————————————————————————————————————
A01:2025 - Broken Access Control
Tanım - Broken Access Control nedir?:
Broken Access Control, bir kullanıcının veya istemin erişmemesi gereken veri, sayfa veya işleme erişebilmesi durumudur. Kimlik doğrulama (kimin giriş yaptığı) ayrı; burada eksik veya yanlış olan şey “bu kimliğe hangi kapılar açılsın” sorusuna verilen yanıtın güvenilir olmamasıdır.
// OWASP bağlamı
OWASP Top 10:2025’te A01 olarak yer alan bu kategori, hem klasik yetki atlama örüntülerini hem de 2025’te içine dahil edilen bazı yeni ilişkilendirmeleri (ör. SSRF ile ilgili erişim-durumları) kapsar. Yani konu sadece “hesaplar arasında veri sızması” değildir; uygulama davranışının her katmanında “kim neye erişebilir” sorusunun tutarlı cevaplanamamasıyla ilgilidir.
// OWASP 2021 - 2025: Kısa tarihçe (Broken Access Control neden hala önde?)
OWASP 2021 sürümünde de Broken Access Control yüksek öncelikteydi; 2025 sürümünde ise kategori kapsamı daha da genişletilerek bazı ilişkilendirilen zafiyet tipleri (ör. SSRF) bu başlık altına alınmıştır. OWASP 2025 raporu, erişim kontrolüne ilişkin zafiyetlerin hâlâ yaygın ve yüksek etkili olduğunu, veri setlerindeki analizlerin bu durumu desteklediğini belirtir. Bu da A01’in listede korunmasının sebeplerindendir.
——————————————————————————————————————————————————————————————————————————
2. Görünüm: Broken Access Control uygulamada neye benzer?
Aşağıda, gerçek bir kullanıcı, ürün sahibi veya destek/operasyon ekibinin gözlemleyebileceği görsel ve davranışsal işaretler listelenmiştir:
1. Kullanıcı arayüzünde (UI) görünen işaretler
Beklenmeyen menü/bağlantılar: Normal bir kullanıcı hesabında görünmemesi gereken “Yönetici”, “Kullanıcıları Düzenle”, “Fatura Onayı” gibi menü öğelerinin görünmesi.
Erişim kontrolü sadece gizleme ile yapılmış: UI’da bazı düğme/alanlar gizleniyor ama URL doğrudan girildiğinde aynı sayfa/işlem erişilebiliyorsa (kullanıcı “görünürde” engellenmiş olsa bile).
“Düzenle” veya “Sil” butonunun görünmesi: Bir kaydın yanında herkes için aktif olan düzenleme/silme butonları — olması gerekenden fazla yetki verdiğine dair görünür ipucu.
Yanlış rol etiketleri: Profilde ya da kullanıcı bilgisi ekranında rol veya izinlerle ilgili tutarsız, çelişkili etiketlerin görünmesi (ör. normal kullanıcıda “Admin” yazıyor gibi).
2. URL / adres çubuğu görünümü
Tahmin edilebilir id/isimler: Adres çubuğunda ?id=123 veya /user/45 gibi açık, ardışık veya kolay tahmin edilebilen değerler göze çarpıyorsa — bu tek başına hatadır demek değildir ama eksik sunucu tarafı kontrolü varsa risk işaretidir.
Direkt erişimle ulaşılan gizli sayfalar: Kullanıcının görememesi gereken sayfa URL’leri (ör. /admin/...) doğrudan girildiğinde veya bir linkten ulaşılabildiğinde görünür olur.
3. Formlar / giriş alanları
Her kullanıcıya açık düzenleme alanları: Sadece sahibi tarafından düzenlenmesi gereken alanların herkese düzenlenebilir görünmesi.
Formda görünmeyen ama erişilebilir alanlar: Arayüzde gizlenen alanların tarayıcı üzerinden aktif hâle getirilebilmesi (görsel işaret olarak “gizli alanın varlığı”), istemci tarafı gizlemelerin yetki sağlamadığına dair ipucu verir.
4. Hata mesajları ve yanıt davranışları
Tutarsız hata/erişim mesajları: Aynı tür istek farklı kullanıcılardan geldiğinde farklı hata kodları veya mesajlar dönmesi (ör. bazen 200/OK bazen 403/Forbidden) bu tutarsızlık yetki kontrollerinin tutarsız uygulanıyor olabileceğine işaret edebilir.
Aşırı bilgi veren mesajlar: “Bu kaynağa erişmek için admin olmalısınız” gibi açık rol bilgilerinin sistem tarafından kullanıcıya gösterilmesi; bu tip mesajlar politikaların yanlış yerde uygulandığını gösterebilir.
5. Yönetim panelleri / dashboard’larda görünüm
Normal kullanıcının gördüğü yönetim widget’ları: Raporlar, kullanıcı listeleri veya yönetim sekmeleri normal kullanıcı görünümünde aktifse.
Filtrelenmemiş içerik: Dashboard’larda kullanıcıya özel olması gereken verilerin (örn. sadece kendi işlemleri) tümüyle görünüyor olması.
6. Operasyonel / destek tarafında görünen işaretler
Kullanıcı şikayetleri ve destek talepleri: “Benim görmemem gereken bir şey görüyorum” gibi geri bildirimler.
Loglarda ilginç erişimler: Aynı kaynağa farklı kullanıcı kimliklerinden erişim denemeleri; reddedilmiş ama ısrarla erişim talepleri (burada yine istismar adımı verilmez, sadece gözlem olarak belirtilir).
Beklenmeyen veri paylaşımı: Raporlama veya export işlevlerinin beklendiği gibi filtrelenmemiş veri döndürmesi.
// Görünüm örneği:
Kullanıcı A, profil sayfasında sadece kendi bilgilerini görmesi gerekirken ana menüde “Kullanıcı Listesi” linki belirmiş gibi görür. Linke tıklamasa bile adres çubuğunda /users yazdığında bir kullanıcı listesi ekranı açılabiliyorsa, bu “arayüzde yetki kısıtlamasının sadece saklama/gizleme ile yapıldığı”na dair net bir görsel ipucudur. Özet: arayüzde görünmeyen şeyler sunucu tarafında da engellenmiyorsa problem vardır.
// Görünümle ilgili sık rastlanan yanlış anlamalar
“Eğer bir düğme görünmüyorsa erişim yoktur.” — Yanlış. Sadece UI’da düğmenin gizlenmesi erişimi sağlamaz; sunucu tarafı denetimi olmalıdır.
“Hata mesajı veriliyorsa sistem güvenli.” — Hata mesajlarının olması değil; hataların ve erişim kontrolünün tutarlı olması önemlidir. Tutarsız mesajlar tersine sorun işaretidir.
——————————————————————————————————————————————————————————————————————————
3. Hangi takımlar / roller bu görünümden etkilenir?
Ürün/UX ekipleri: Kullanıcı arayüzünde ne gösterildiğine karar verirken yetki sınırlarını net tanımlamalı.
Geliştiriciler: UI ve sunucu tarafı kontrollerin paralel, tutarlı olmasını sağlamalı.
Operasyon/Support: Kullanıcı raporları ve loglar üzerinden belirtileri erken fark edip eskalasyon yapmalı.
Hukuk & Uyumluluk: Görünen hata ve veri sızıntıları mevzuat açısından risk değerlendirmesi gerektirir.
——————————————————————————————————————————————————————————————————————————
Detaylı bilgi için göz ata bilirsiniz: Broken_Access_Control
İyi Forumlar..
