Web Pentest Kapsamı Nasıl Çıkarılır?

Temel Değerlendirme

Web pentest kapsamı yalnızca URL sayısı, ekran sayısı veya endpoint listesiyle çıkarılmaz. Doğru kapsam; uygulamanın kritik iş akışları, kullanıcı rolleri, veri sınıfları, entegrasyonları, ödeme veya yetki mekanizmaları, admin işlemleri ve production etkisi üzerinden belirlenir. Bir login ekranı basit görünebilir ama arkasında tenant isolation, fatura, ödeme, belge, API token veya admin onayı varsa pentest derinliği değişir. İyi kapsam, testin neyi kanıtlayacağını ve hangi riskleri dışarıda bırakmayacağını baştan netleştirir.

Kapsam Neden Bu Kadar Önemli?

Pentest kapsamı yanlış kurulursa iki kötü sonuç doğar. Ya ekip gereğinden fazla yüzeyi yüzeysel test eder ya da en kritik iş akışları kapsam dışında kalır. İkisi de güvenlik hissi üretir ama gerçek güvence üretmez.

Kapsamın amacı şunları netleştirmektir:

Hangi uygulamalar ve domainler test edilecek?
Hangi kullanıcı rolleri sağlanacak?
Hangi iş akışları kritik kabul edilecek?
Hangi veriler hassas?
Üçüncü parti entegrasyonlar testte nasıl ele alınacak?
Production mı staging mi kullanılacak?
Test sırasında hangi limitler ve onaylar geçerli olacak?

Asset Listesi Yetmez

Klasik kapsam formu çoğu zaman şöyle başlar: domain, IP, endpoint sayısı, teknoloji stack'i. Bunlar gerekir ama yeterli değildir. Bir pentestin gerçek değeri, iş akışlarını anlamasından gelir.

Örneğin iki uygulama da "20 endpoint" olabilir. Birinde public blog yönetimi vardır, diğerinde kredi başvurusu, belge yükleme, ödeme ve müşteri verisi işlenir. Endpoint sayısı aynı olsa bile risk ve test derinliği aynı değildir.

Web Pentest Scope Checklist

| Alan | Sorulacak soru | Neden önemli? | |---|---|---| | Roller | Kaç kullanıcı tipi var? | Authorization ve privilege escalation testleri için gerekir. | | Tenant modeli | Organization, workspace veya müşteri ayrımı var mı? | BOLA/IDOR ve cross-tenant sızıntı testlerini belirler. | | Hassas veri | Kişisel veri, finansal veri veya iç doküman var mı? | Etki ve önceliklendirme için gerekir. | | Kritik akış | Ödeme, iade, onay, belge yükleme, admin işlem var mı? | Business logic test derinliğini belirler. | | Entegrasyon | SMS, e-posta, ödeme, CRM, AI veya storage provider var mı? | SSRF, webhook, secret ve provider abuse testlerini etkiler. | | Ortam | Staging production'a ne kadar benziyor? | Bulguların gerçekliği için önemlidir. | | Test verisi | Farklı rollere ait test hesapları var mı? | Yetki testleri için şarttır. | | Rate limit | Test sırasında limitler nasıl yönetilecek? | Gerçek abuse kontrollerini ölçmek için gerekir. |

Pratik Kapsam Örneği

Bir B2B SaaS için doğru kapsam şöyle yazılabilir:

Web paneli ve public API test edilecek.
Rolleri: owner, admin, member, read-only user.
İki ayrı tenant için test hesapları sağlanacak.
Fatura, proje, dosya yükleme, davet, API token ve audit log akışları kritik kabul edilecek.
Staging ortamı production ile aynı auth, cache ve storage mimarisine sahip olacak.
E-posta/SMS provider gerçek gönderim yapmayacak ama API davranışı test edilebilir olacak.

Bu kapsam, "app.example.com test edilecek" cümlesinden çok daha değerlidir.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "Endpoint sayısı az, pentest kısa sürer." | Az endpoint yüksek iş etkisi taşıyabilir. | | "Staging var, production'a bakmaya gerek yok." | Staging production yetki, cache ve secret davranışını yansıtmayabilir. | | "Admin hesabı vermeyelim, saldırgan da admin değil." | Rol geçişleri ve admin iş akışları test edilmezse kritik riskler kaçar. | | "Sadece black-box daha gerçekçi." | Modern SaaS testlerinde doğru roller ve test verisi daha iyi kanıt üretir. |

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda kapsamı uzmanla çıkarmak daha sağlıklıdır:

Uygulama çok kiracılı SaaS modeliyle çalışıyor.
Finansal işlem, kişisel veri veya regülasyon yükü var.
Admin panel, API token, webhook veya provider entegrasyonu mevcut.
AI/RAG/agent özellikleri web uygulamasına bağlı.
Pentest sonucu müşteri, regülatör veya yönetim tarafından incelenecek.

Kapsam Toplantısına Hazırlık

Pentest öncesi teknik ve iş ekipleri şu bilgileri hazırlarsa test daha verimli ilerler:

Uygulama mimarisi ve kritik modüller.
Test ortamı ve production farkları.
Kullanıcı rolleri ve örnek test hesapları.
API dokümantasyonu veya örnek request koleksiyonu.
Hassas veri işleyen ekranlar.
Üçüncü parti servisler ve webhook akışları.
Önceki pentest veya scanner raporları.
Bilinen riskler ve ekipte şüphe uyandıran alanlar.

Bu hazırlık, pentester'ın zamanını yüzey keşfinden çok yüksek etkili akışlara ayırmasını sağlar.

Sonraki Adım

Kapsamı netleştirmenin en pratik yolu, teknik asset listesi ile iş etkisini aynı masaya koyan Web App Pentest Scope Checklist üzerinden ilerlemektir. Böylece test yalnızca URL sayısına göre değil, kritik iş akışlarına göre planlanır.

Checklist içinde şu başlıklar özellikle ayrılmalıdır:

Public ve authenticated yüzeyler.
Admin, müşteri, bayi, destek ve entegrasyon rolleri.
Tenant modeli ve veri izolasyonu.
Ödeme, fatura, export, webhook ve provider akışları.
Önceki scanner/pentest bulguları.

Bu hazırlık yapılırsa kapsam toplantısı daha kısa sürer, test süresi daha değerli alanlara ayrılır ve rapor yönetim tarafı için daha anlaşılır hale gelir.

Eresus Yaklaşımı

Eresus Security, web pentest kapsamını sayfa sayısına göre değil riskli iş akışına göre çıkarır. Amacımız sadece bulgu listesi üretmek değil; hangi saldırı yolunun gerçekten veri, para, yetki veya operasyon etkisi doğurduğunu kanıtlamaktır. Web uygulamanız için doğru kapsamı belirlemek istiyorsanız Web App Pentest Scope Checklist üzerinden birlikte netleştirebiliriz.

SSS

Pentest kapsamına API dahil edilmeli mi?

Web uygulaması API üzerinden çalışıyorsa evet. Modern web güvenliği çoğu zaman API authorization ve iş mantığı testine bağlıdır.

Production ortamında test yapılır mı?

Yapılabilir, ancak güvenli limitler, test hesapları ve etki sınırları baştan belirlenmelidir. Bazı testler staging üzerinde yürütülür.

Test hesabı vermek pentesti zayıflatır mı?

Hayır. Authenticated test, BOLA, IDOR, rol geçişi ve tenant isolation gibi kritik riskleri daha iyi gösterir.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?