OWASP'ın Diğer Listeleri: API Security, LLM Top 10, ASVS ve Cheat Sheet Series

Sürüm notu: Bu yazı OWASP Top 10:2025'in yanındaki diğer OWASP projelerini (API Security Top 10 2023, Top 10 for LLM Applications 2025, ASVS 5.0) anlatır; kod ASP.NET Core 10 (.NET 10) ile denenmiştir.

Önce Tahmin Et

Bookstore API'de bir kitabın yorumlarını dönen bir endpoint var. Handler, veritabanından gelen Review nesnelerini olduğu gibi döndürüyor ve her Review'un içinde yazarı temsil eden bir User nesnesi var. Endpoint anonim, giriş gerektirmiyor. JSON'da yorumun metni ve yazarın adı dışında ne görürsün?

Kendi lab'ımda ilk denemede yanıtta email, passwordHash ve isAdmin alanları da vardı. Kimse bir yetki kontrolünü atlatmadı; endpoint tam olarak yazıldığı şeyi yaptı. Bu sorunun Top 10'daki yeri A01 (hassas bilgi ifşası CWE-200 ve CWE-201 orada eşleniyor), ama OWASP API Security Top 10'da kendi adı var. Serinin son yazısında Top 10'un dışına çıkıp OWASP'ın diğer listelerine bakıyoruz. Örnekler yine yalnız kendi makinende; bu teknikleri yalnız sahibi olduğun ya da yazılı izin aldığın sistemlerde dene.

Neden Tek Bir Liste Yetmiyor

Top 10, web uygulamalarının genelini kapsayan bir farkındalık belgesi. Genel olduğu için bazı alanlarda kaba kalıyor. Bir REST API'nin en sık hatası ile bir dil modeline bağlı bir uygulamanın en sık hatası aynı değil. OWASP bu yüzden belirli alanlar için ayrı listeler ve ayrı projeler yürütüyor. Bunları üç gruba ayırmak işe yarar: farkındalık listeleri (API Security Top 10, Top 10 for LLM Applications), doğrulama standardı (ASVS) ve "nasıl yapılır" rehberleri (Cheat Sheet Series).

API Security Top 10 (2023)

Güncel sürüm 2023. Maddeler şöyle: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication, API3 Broken Object Property Level Authorization (BOPLA), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization (BFLA), API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management ve API10 Unsafe Consumption of APIs.

Listenin dili Top 10'dan daha ayrıntılı. Top 10'daki Broken Access Control, burada üç seviyeye bölünüyor: nesne seviyesi (BOLA, yani IDOR'un API'deki adı), property seviyesi (BOPLA) ve fonksiyon seviyesi (BFLA). 3. yazıda başka bir kullanıcının siparişini okumak BOLA'ydı, admin endpoint'indeki eksik kontrol BFLA. Açılıştaki yorum endpoint'i ise BOPLA: nesneye erişim doğru, ama nesnenin hangi property'lerinin görüneceği kontrol edilmemiş. Aynı madde, mass assignment yazısındaki "istemci yazmaması gereken property'yi yazabiliyor" durumunu da kapsıyor.

API9 Improper Inventory Management ise Top 10'da doğrudan karşılığı olmayan bir madde: hangi API sürümlerinin, hangi ortamlarda, hangi endpoint'lerle açık olduğunu bilmemek. Unutulmuş bir v1 ya da herkese açık bırakılmış bir test ortamı, kodun geri kalanı ne kadar sağlam olursa olsun bir kapıdır.

Bir Örnek: API3 ve Response DTO'su

Düzeltme, veri modelini ve API sözleşmesini ayırmak. Endpoint entity'yi değil, yalnız göstermek istediğin alanları taşıyan bir response DTO'su döner:

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
WebApplication app = builder.Build();

User ada = new(1, "Ada", "ada@example.com", "dev-only-not-a-real-hash", IsAdmin: false);
List<Review> reviews = [new(1, BookId: 1, "Great book", ada)];

app.MapGet("/books/{id:int}/reviews", (int id) =>
    reviews.Where(r => r.BookId == id)
           .Select(r => new ReviewResponse(r.Id, r.Body, r.Author.DisplayName)));

app.Run();

public record User(int Id, string DisplayName, string Email, string PasswordHash, bool IsAdmin);
public record Review(int Id, int BookId, string Body, User Author);
public record ReviewResponse(int Id, string Body, string AuthorName);

$ curl -i http://localhost:5191/books/1/reviews
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Fri, 06 Nov 2026 19:08:08 GMT
Server: Kestrel
Transfer-Encoding: chunked

[{"id":1,"body":"Great book","authorName":"Ada"}]

Artık yanıtta yalnız üç alan var. Bu yaklaşımın güzel tarafı, varsayılanı tersine çevirmesi: entity'ye yarın yeni bir property eklendiğinde (PhoneNumber, LastLoginIp) API'ye kendiliğinden sızmaz; birinin onu bilerek ReviewResponse'a eklemesi gerekir. EF Core kullanıyorsan Select ile projeksiyon, gereksiz kolonları veritabanından hiç çekmemek gibi bir performans kazancı da getirir. Yazma tarafında aynı ilke input DTO'su olarak geçerli; 17. yazıdaki UnmappedMemberHandling.Disallow ayarı da onun JSON'daki emniyet kemeri.

Top 10 for LLM Applications (2025)

OWASP'ın GenAI Security Project'i altında yürütülen bu liste, dil modeli kullanan uygulamalara odaklanıyor. 2025 sürümünün maddeleri: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation ve LLM10 Unbounded Consumption.

Listede tanıdık fikirler var. Prompt injection, injection'ın yeni bir yorumlayıcıdaki hâli: veri, modelin talimatı olarak ele alınıyor. Improper Output Handling, modelin ürettiği metni güvenilmeyen girdi gibi ele almamak; modelin cevabını innerHTML'e basmak, 10. yazıdaki XSS'in aynısı. Excessive Agency ise en az yetki ilkesinin modele uygulanmış hâli: modele bir araç veriyorsan, o aracın yapabileceklerini sınırla. Bir .NET geliştiricisi için pratik sonuç şu: modele giden ve modelden gelen her şey, şimdiye kadar konuştuğumuz bütün kurallara tabi.

ASVS 5.0 ve Cheat Sheet Series

17. yazıda değindiğimiz gibi ASVS, Top 10'un "neye dikkat etmeli" sorusunu "neyi doğrulamalı" sorusuna çeviren standart. Güncel kararlı sürüm 30 Mayıs 2025'te yayımlanan 5.0.0. Gereksinimler üç seviyeye ayrılıyor; düşük riskli bir uygulama ilk seviyeden başlar, hassas veri işleyen bir uygulama daha üst seviyeleri hedefler. Bir gereksinimi ya bir teste, ya bir CI kuralına, ya da kod inceleme listesine bağlayabiliyorsan onu gerçekten uyguluyorsun demektir.

Cheat Sheet Series (cheatsheetseries.owasp.org) ise konu başına kısa ve uygulamaya dönük rehberler. Bu serideki parola saklama iterasyon sayıları ve localStorage'daki token uyarısı oradan geliyor. Bir konuda "pratikte nasıl yapılır" sorusu varsa ilk bakılacak yer burası; ama her rehberi kendi framework'ünün belgesiyle (learn.microsoft.com, angular.dev) birlikte oku, çünkü rehberler dilden bağımsız yazılıyor.

Serinin Bundan Sonrası

Bu seri, OWASP Top 10:2025'i ASP.NET Core 10 ve Angular üzerinden anlattı ve 2017'den bugüne listenin nasıl değiştiğini gösterdi. Yeni bir Top 10 sürümü çıktığında seri onunla birlikte sürecek: değişen kategoriler için yeni bir karşılaştırma yazısı gelecek ve kategori yazılarındaki kodlar güncellenecek.

Sıradaki güvenlik serileri, burada yüzeyine dokunduğumuz üç alanı derinleştirecek. Kimlik doğrulama serisinde passkey'ler, OpenID Connect ve token yaşam döngüsü; ASP.NET Core güvenliği serisinde authorization handler'ları, Data Protection ve güvenli yapılandırma; frontend güvenliği serisinde CSP, Trusted Types ve SPA'lar için BFF kalıbı var.

Sık Düşülen Tuzaklar

Birincisi, API'ni yalnız Top 10'la değerlendirmek. Top 10'da property seviyesi yetkilendirme ya da API envanteri ayrı bir madde değil; API Security Top 10'a da bakmazsan bu ikisi kolayca gözden kaçar.

İkincisi, response'u istemcide filtrelemek. Angular'da email alanını template'te göstermemek, onu yanıttan çıkarmak değildir; tarayıcının geliştirici araçlarında herkes görür. Filtreleme sunucuda, DTO ile yapılır.

Üçüncüsü, LLM'li bir özelliği "yapay zekâ ayrı bir dünya" diye güvenlik incelemesinin dışında tutmak. Modelin çıktısı da kullanıcı girdisi gibi encode edilmeli, modelin çağırdığı araçlar da yetkilendirilmeli.

Dördüncüsü, ASVS'yi bir kerede bütünüyle uygulamaya çalışmak. Seviye seç, uygulamana uyan gereksinimlerle başla, her sürümde birkaçını teste bağla.

Kontrol Listesi

API'n için API Security Top 10'u maddeler hâlinde gözden geçir: her endpoint'te nesne, property ve fonksiyon seviyesinde yetkilendirme var mı? Entity'ler API'den dönmüyor, her endpoint'in response ve input DTO'su ayrı. Açık olan bütün API sürümlerinin ve ortamların bir envanteri var. Kaynak tüketimi rate limiting ve boyut sınırlarıyla kontrol ediliyor. LLM kullanan özelliklerde model çıktısı encode ediliyor, modele verilen araçlar en az yetkiyle tanımlı. Uygulama için bir ASVS seviyesi seçilmiş ve gereksinimlerin bir kısmı testlere bağlanmış. Bir konuda karar verirken ilgili Cheat Sheet'e ve framework belgesine birlikte bakılıyor.

Küçük Bir Deneme

★☆☆ Yorum endpoint'ine bir CreatedAt alanı ekle. Önce yalnız Review record'una ekle ve yanıtın değişmediğini gör; sonra ReviewResponse'a ekleyip yanıtta belirdiğini doğrula.

★★☆ Kendi lab'ındaki bütün endpoint'leri listele (17. yazıdaki EndpointDataSource testini kullanabilirsin) ve her birini API Security Top 10'un ilk beş maddesine göre işaretle. Hangi endpoint'te property seviyesi kontrol eksik?

★★★ ReviewResponse dışında hiçbir şeyin dönmediğini garanti eden bir integration test yaz: yanıt JSON'undaki property adlarını oku ve beklenen listeyle birebir karşılaştır. Entity'ye yeni bir alan eklediğinde testin hâlâ geçtiğini, DTO'ya eklediğinde ise kırıldığını gör.

Seri burada bitiyor ama konu bitmiyor. Bir sonraki güvenlik serisinde kimlik doğrulamayla başlayacağız: parolanın ötesine geçip passkey'lere, OpenID Connect'e ve bir token'ın doğduğu andan iptal edildiği ana kadar geçen yaşam döngüsüne bakacağız.