Web Uygulaması Sızma Testinde Kapsam Nasıl Belirlenir?

Bir şirket web uygulaması için sızma testi teklifi istiyor ve kapsam satırına yalnızca şunu yazıyor:

https://portal.example.com

İlk bakışta hedef bellidir. Fakat uygulama açıldığında browser farklı sistemlerle konuşmaya başlar:

• Login işlemi auth.example.com üzerinden yürür
• Business data api.example.com/v2 üzerinden gelir
• File upload ayrı bir object storage domain'ine gider
• Admin panel farklı hostname kullanır
• Mobile application aynı API'nin eski /v1 version'ını çağırır
• Payment flow third-party provider'a redirect olur
• Password reset link'i ayrı bir identity service tarafından üretilir
• Export işlemi background job ile hazırlanır
• Webhook endpoint'i partner sistemlerden request kabul eder
• Support ekibi kullanıcı hesabını başka bir backoffice üzerinden yönetir

Teklifte yalnızca portal domain'i yazılıysa bunların hangisi test kapsamındadır?

Tester browser'ın çağırdığı API'yi test edebilir mi? Third-party payment page'e dokunabilir mi? Standard user dışında başka role verilecek mi? İki farklı tenant oluşturulacak mı? Rate limit testi production üzerinde yapılabilir mi? File upload sonrasında oluşan asynchronous processing kapsamda mı? Eski API version'ı hâlâ internetten erişilebiliyorsa test edilmeli mi?

Bu sorular test başladıktan sonra cevaplanıyorsa kapsam geç hazırlanmıştır.

Web uygulaması sızma testinde kapsam nasıl belirlenir sorusunun kısa cevabı şudur:

Eksik kapsam yalnızca bazı açıkların kaçmasına neden olmaz. Tekliflerin birbirleriyle karşılaştırılamamasına, test süresinin yanlış hesaplanmasına, production riskine, yetki belirsizliğine ve rapor tesliminde “biz bunu kapsamda sanıyorduk” tartışmasına yol açar.

Bu yazıda web application pentest scope'unun teknik ve business açıdan nasıl kurulacağını, hangi bilgilerin provider'a verilmesi gerektiğini ve satın alma dokümanının hangi kabul kriterlerini içermesi gerektiğini adım adım ele alacağız.

Web uygulaması sızma testi kapsamı neden URL sayısı değildir?

URL, application'a giriş noktalarından yalnızca biridir. Modern web application çoğu zaman frontend, API, identity provider, storage, message queue, third-party service ve administrative interface bileşimidir.

Aynı URL altında son derece farklı iki uygulama bulunabilir:

• Birincisi public content gösteren, login içermeyen ve yalnızca birkaç read-only endpoint kullanan kurumsal sitedir.
• İkincisi onlarca role, multi-tenant authorization, payment, file processing, reporting, approval ve partner API barındıran business platform'dur.

İkisi de teknik olarak “bir domain” olabilir. Test effort'ü ve riskleri aynı değildir.

Tersi de mümkündür. Tek bir application, CDN ve service architecture nedeniyle on farklı subdomain kullanabilir. Bunları on ayrı uygulama saymak aynı authentication, business logic ve backend üzerinde gereksiz tekrar oluşturabilir.

Kapsam büyüklüğünü daha doğru belirleyen faktörler şunlardır:

• Authentication modeli
• User role ve permission sayısı
• Tenant veya organization ilişkileri
• Critical business flow sayısı
• API endpoint ve method çeşitliliği
• Object ownership modeli
• Sensitive data type'ları
• File upload ve processing davranışı
• Integration ve webhook sayısı
• Admin ve support fonksiyonları
• Payment ve financial action'lar
• Application state ve lifecycle geçişleri
• Technology stack ve protocol çeşitliliği
• Environment'ın production'a benzerliği
• Testte istenen coverage ve evidence düzeyi

Bu yüzden “50 URL'ye kadar web pentest” ifadesi tek başına teknik kapsam tanımı değildir. Route sayısı effort için yardımcı veri olabilir, fakat risk ve logic complexity'yi temsil etmez.

Kapsam belirlemenin temel amacı nedir?

İyi hazırlanmış scope, dört tarafın aynı çalışmayı anlamasını sağlar:

1. 1Business owner hangi kritik işlevlerin test edileceğini bilir.
2. 2Technical owner hangi component, environment ve dependency'nin teste dahil olduğunu bilir.
3. 3Tester hangi action'lara yetkili olduğunu ve hangi coverage'in beklendiğini bilir.
4. 4Satın alma ve yönetim teklifleri aynı deliverable ve sınırlar üzerinden karşılaştırabilir.

Kapsam aynı zamanda test sonucunun yorumlanma sınırını belirler. Yalnızca unauthenticated surface test edildiyse rapor “application güvenlidir” sonucu veremez. Admin role sağlanmadıysa administrative authorization hakkında assurance oluşmaz. Mobile API scope dışıysa web frontend'in güvenli bulunması mobile channel için kanıt değildir.

NCSC, penetration testing scope'unun service'in business logic'iyle bağlantılı olmasını ve platform içinde belirlenmiş risk alanlarını incelemesini önerir. Bu yaklaşım kritik bir fark yaratır:

Önce testin amacı yazılmalı

Kapsam formunda ilk alan domain değil test objective'i olmalıdır.

Farklı objective'ler farklı kapsam üretir:

Pre-release security assessment

Yeni uygulamanın production öncesinde authentication, authorization, session, input validation, business logic ve deployment configuration riskleri test edilir. Staging environment kullanılabilir, ancak production parity doğrulanmalıdır.

Periyodik application pentest

Canlı uygulamanın değişen attack surface'i, yeni feature'ları, mevcut role'leri ve production configuration'ı değerlendirilir. Önceki bulgular ve önemli değişiklikler scope'a yön verir.

Compliance odaklı test

PCI DSS veya başka bir standardın gerektirdiği boundary ve test kriterleri dikkate alınır. Compliance scope ile gerçek application risk scope'u aynı olmayabilir. Minimum requirement'ın dışında kalan kritik business flow'lar ayrıca değerlendirilmelidir.

Incident sonrası doğrulama

Gerçek olayda kullanılan veya şüphelenilen attack vector, benzer code path'ler ve remediation etkisi test edilir. Bu çalışma yalnızca klasik checklist coverage'i değil root cause ve recurrence riskini ele alır.

Yeni feature veya architecture değişikliği

SSO geçişi, payment integration, file upload, GraphQL migration, multi-tenant dönüşüm veya yeni admin panel gibi değişiklik hedeflenir. Değişikliğin etkilediği eski flow ve trust boundary'ler de scope'a alınmalıdır.

Müşteri assurance talebi

Enterprise customer belirli service ve data flow için bağımsız güvence ister. Scope, müşterinin kullandığı tenant modelini ve integration path'ini temsil etmelidir. Sadece marketing site'ı test ederek SaaS platform için assurance üretilemez.

Test zamanlamasını ayrıntılı ele aldığımız Sızma testi ne zaman yaptırılmalı? Yayına çıkmadan önce mi, olay sonrası mı? yazımızı da inceleyebilirsiniz.

1. Application boundary nasıl çıkarılır?

Application boundary, kullanıcı arayüzünün bittiği yerde bitmez. Bir request'in kimlik, data veya action bakımından güvendiği bütün component'ler incelenmelidir.

Kapsam toplantısında basit bir architecture ve data flow görünümü hazırlanmalıdır:

Bu görünüm ayrıntılı enterprise architecture dokümanı olmak zorunda değildir. Şu sorulara cevap vermesi yeterlidir:

• User hangi client'larla erişiyor?
• Authentication nerede gerçekleşiyor?
• Token veya session kim tarafından üretiliyor?
• Business action hangi API ve service üzerinde işleniyor?
• Data nerede okunuyor, yazılıyor ve export ediliyor?
• File hangi component üzerinden yükleniyor ve işleniyor?
• Third-party'lere hangi data gönderiliyor?
• Admin ve support action'ları hangi interface üzerinden yapılıyor?
• Background job ve asynchronous process hangi flow'ları tamamlıyor?

Boundary çıkarılmadan yalnızca hostname listesi vermek testin component'ler arası riskleri kaçırmasına neden olur.

2. Host, domain ve environment envanteri nasıl hazırlanmalı?

Her hostname için testteki rolü ve ownership'i belirtilmelidir.

Örnek inventory:

Buradaki kritik alan ownership'tir. DNS'in kurum domain'i altında olması altyapının tamamen kuruma ait olduğunu garanti etmez. SaaS, managed service, shared hosting ve CDN üzerinde provider'a ait component'ler bulunabilir.

Tester'ın third-party asset üzerinde işlem yapma yetkisi otomatik oluşmaz. Contract ve provider testing policy doğrulanmalıdır.

Unutulan environment'lar

Sahada en çok atlanan alanlar şunlardır:

• Eski production API version'ları
• UAT ve staging hostname'leri
• Partner portal'ları
• Mobile backend
• GraphQL endpoint
• WebSocket service
• Admin ve support panel
• Preview ve file conversion service
• Password reset ve e-mail verification endpoint'leri
• Monitoring veya debug interface
• Regional deployment'lar
• Acquisition sonrasında kalan legacy domain'ler
• Alternate port ve protocol'ler

OWASP API Security Top 10:2023 içindeki Improper Inventory Management başlığı, API host'larının environment, access ve version bilgileriyle inventory edilmesini, integrated service'lerin ve data flow'larının belgelenmesini önerir. Bu yalnızca operasyonel hygiene değil pentest scope'unun da temelidir.

3. API kapsamı neden ayrıca yazılmalı?

Modern web frontend çoğu business action'ı API üzerinden yapar. “Web uygulaması test edilecek” cümlesi API'nin derinlemesine test edileceğini garanti etmez.

API scope en az şu bilgileri içermelidir:

• Base URL'ler
• REST, GraphQL, gRPC-Web, WebSocket veya diğer protocol'ler
• Version'lar
• OpenAPI, Swagger, Postman veya GraphQL schema erişimi
• Authentication method'u
• Token scope ve audience
• User role'leri
• Tenant modeli
• Endpoint ve HTTP method listesi
• Object type'ları
• Bulk ve export endpoint'leri
• File upload ve download path'leri
• Webhook receiver ve sender flow'ları
• Rate limit ve quota'lar
• Deprecated fakat erişilebilir endpoint'ler
• Partner veya machine-to-machine API'ler

Sadece frontend üzerinden görülen endpoint'leri test etmek coverage sağlamaz. UI'ın çağırmadığı admin function, hidden parameter, alternate method ve legacy route bulunabilir.

Endpoint sayısı nasıl yorumlanmalı?

GET /products/{id} ile DELETE /products/{id} aynı path'i kullansa da farklı authorization ve business impact taşır. Bu nedenle inventory path değil path + method + role + object relationship düzeyinde ele alınmalıdır.

Örnek:

Bu tablo authorization scope'u ve test data ihtiyacını aynı anda görünür hale getirir.

IDOR ve object relationship testinin neden ayrı data seti gerektirdiğini IDOR açığı neden hâlâ bu kadar yaygın? yazımızda ayrıntılı biçimde açıklıyoruz.

4. User role ve yetki modeli scope'a nasıl eklenmeli?

Tek bir standard user account ile yapılan test, çok role'lü application için yeterli değildir. Authorization testinin yapılabilmesi için tester'ın beklenen allow ve deny kararlarını karşılaştırabileceği account'lara ihtiyacı vardır.

Role inventory şu bilgileri taşımalıdır:

• Role adı
• Business amacı
• Tenant veya organization ilişkisi
• Read ve write yetkileri
• Approval veya administrative action'lar
• Data visibility seviyesi
• Impersonation veya delegation capability'si
• MFA requirement'ı
• Account lifecycle state'i

Örnek role seti:

• Anonymous user
• Registered but unverified user
• Verified standard user
• Premium user
• Tenant member
• Tenant manager
• Finance approver
• Support agent
• Read-only auditor
• Application administrator
• Super administrator
• Suspended veya disabled user

Her role için account vermek her zaman mümkün değildir. Bu durumda risk bazlı önceliklendirme yapılmalı ve test edilmeyen role'ler raporun limitation bölümünde açıkça yazılmalıdır.

İki user neden gereklidir?

Aynı role içinde en az iki user, horizontal authorization testleri için gerekir. User A'nın User B object'ini okuyup değiştiremediği ancak bu şekilde doğrulanabilir.

İki tenant neden gereklidir?

Multi-tenant application'da aynı tenant içindeki cross-user test ile cross-tenant test farklıdır. En az iki tenant ve her tenant içinde uygun role kombinasyonu sağlanmalıdır.

Örnek minimum data seti:

Account sayısını azaltmak için tester'a role switching vermek bazı testlerde faydalı olabilir. Ancak switching implementation'ı gerçek session ve authorization davranışını değiştiriyorsa sonuç güvenilir olmaz.

5. Business flow kapsamı nasıl çıkarılır?

OWASP WSTG yalnızca input validation değil authentication, authorization, session management, business logic, client-side ve configuration alanlarını da kapsar. Bunun nedeni application security'nin endpoint listesinden ibaret olmamasıdır.

Business flow, bir iş sonucuna ulaşmak için birden fazla action'ın state içinde sıralanmasıdır.

Örnek e-commerce flow:

1. 1Product seçilir
2. 2Discount uygulanır
3. 3Cart hesaplanır
4. 4Address seçilir
5. 5Shipping cost eklenir
6. 6Payment başlatılır
7. 7Provider callback alınır
8. 8Order confirmed state'e geçer
9. 9Refund veya cancellation açılır

Her adım tek başına doğru olabilir. Açık adımların sırası, tekrar edilmesi veya farklı role tarafından çağrılmasıyla ortaya çıkabilir:

• Expired discount'ın yeniden kullanılması
• Negative quantity
• Payment callback replay
• Amount ile order arasındaki mismatch
• Shipping calculation bypass
• Aynı refund'ın iki kez işlenmesi
• Approval atlanarak state değişimi
• Cancelled order'ın tekrar active yapılması

Scope dokümanında kritik flow'lar adları ve business impact'leriyle yazılmalıdır:

• Registration ve verification
• Login, MFA ve recovery
• Organization invitation
• Subscription upgrade ve downgrade
• Cart, order ve payment
• Refund ve chargeback
• File upload, review ve publication
• Approval ve maker-checker
• Data export ve deletion
• Sharing ve permission revoke
• Support impersonation
• Account closure ve reactivation

Tester business rule'u bilmiyorsa beklenmeyen response'un açık mı feature mı olduğunu doğru değerlendiremez.

6. Object ve data lifecycle neden kapsamın parçasıdır?

Bir object yalnızca active state'te bulunmaz. Draft, pending, approved, archived, deleted, restored veya expired olabilir. Authorization ve business rule her state'te değişebilir.

Örneğin document için şu matrix hazırlanabilir:

Scope yalnızca create-read-update-delete action'larını değil lifecycle transition'larını da içermelidir.

Sensitive data type'ları ayrıca belirtilmelidir:

• Personal data
• Payment data
• Health data
• Source code
• Authentication secret
• API key
• Commercial document
• Audit record
• Confidential attachment

Bu bilgi hem risk önceliğini hem de test evidence'ının nasıl maskeleneceğini belirler.

7. Authentication ve session kapsamı nasıl tanımlanmalı?

Login ekranını görmek authentication kapsamını anlamak için yeterli değildir. Kimlik akışının tamamı belgelenmelidir.

Test edilmesi gereken olası alanlar şunlardır:

• Registration
• E-mail veya phone verification
• Password policy
• Login
• MFA enrollment
• MFA challenge
• Remember device
• Password reset
• Username recovery
• Account unlock
• SSO initiation ve callback
• OAuth veya OIDC consent
• SAML response processing
• Session creation
• Token refresh
• Logout
• Global logout
• Device ve session management
• Suspended account davranışı
• Role veya password değişimi sonrası session durumu
• Service account ve machine authentication

Identity provider third-party olsa bile application'ın integration sorumluluğu kapsamda kalabilir. Örneğin provider'ın kendisi test edilmez, fakat application'ın state, nonce, redirect URI, token validation, account linking ve logout implementation'ı test edilir.

MFA testinde ne sağlanmalı?

Tester'ın farklı MFA state'leri oluşturabilmesi gerekir:

• MFA kayıtlı user
• MFA kayıtsız user
• Recovery code kullanan user
• Trusted device işaretli session
• Reset veya re-enrollment yapabilen user

SMS veya e-mail OTP kullanılıyorsa test mailbox ve phone erişimi sağlanmalıdır. Production customer'ın OTP'si istenmemelidir.

Session testinde hangi kanallar birlikte ele alınmalı?

Web cookie, access token, refresh token, mobile token ve API key farklı lifecycle taşıyabilir. Password değiştiğinde web session kapanırken mobile refresh token geçerli kalabilir. User tenant'tan çıkarıldığında active WebSocket connection çalışmaya devam edebilir.

Bu nedenle scope, token type ve client channel'larını birlikte göstermelidir.

8. Production mı, staging mi test edilmeli?

Tek bir doğru cevap yoktur. Seçim test objective'i, environment parity ve operational risk üzerinden yapılmalıdır.

Staging avantajları

• Destructive olmayan fakat yüksek yük üreten testler daha güvenli yapılabilir
• Test data kolay oluşturulur
• E-mail, payment ve notification side effect'leri sınırlandırılabilir
• Debug ve engineering desteği daha hızlı olabilir
• Yeni release production öncesinde değerlendirilebilir

Staging sınırlamaları

• Production ile farklı configuration kullanabilir
• WAF, CDN, API gateway veya identity flow farklı olabilir
• Daha az instance ve farklı scaling behavior bulunabilir
• Real role ve tenant complexity temsil edilmeyebilir
• Third-party integration mock olabilir
• Production'da bulunan legacy endpoint staging'de olmayabilir
• Error handling ve secret management farklı olabilir
• Debug feature'lar sonucu yanıltabilir

Production avantajları

• Gerçek deployment ve security control'leri test eder
• Public attack surface'i doğru gösterir
• Identity, network, cache ve integration davranışı gerçektir
• Configuration drift görünür hale gelir

Production riskleri

• Data integrity ve availability etkilenebilir
• E-mail, SMS, shipment veya payment tetiklenebilir
• Rate limit ve resource consumption testi hizmeti etkileyebilir
• Test data gerçek analytics ve reporting'e karışabilir
• Customer notification oluşabilir
• Security monitoring incident süreci başlatabilir

En güçlü yaklaşım

Birçok projede hybrid model daha doğru sonuç verir:

1. 1Business logic, authorization ve input validation testlerinin önemli bölümü production'a eşdeğer staging üzerinde yapılır.
2. 2Production üzerinde deployment, exposure, security header, TLS, WAF behavior, authentication integration ve güvenli seçilmiş critical flow'lar doğrulanır.
3. 3Production'da yapılmayan action'lar raporda limitation olarak belirtilir.

“Staging production ile aynıdır” beyanı doğrulanabilir alanlarla desteklenmelidir. Build version, configuration, route inventory, identity integration ve security control farkları paylaşılmalıdır.

9. Black box, gray box veya white box seçimi scope'u nasıl etkiler?

Test yaklaşımı verilecek bilgi ve access düzeyini belirler. Aynı application farklı görünürlükle test edildiğinde coverage ve evidence değişir.

Black box

Tester'a public bilgi dışında sınırlı context verilir. External attacker perspective ve exposed attack surface değerlendirilir.

Avantajı reconnaissance ve public exposure gerçekliğidir. Sınırlaması ise test süresinin discovery'ye harcanması ve authenticated role, hidden API, business rule ile negative authorization coverage'inin düşük kalabilmesidir.

Gray box

Tester'a test account'ları, role bilgisi, API documentation, business flow ve gerektiğinde architecture context'i verilir. Web application pentest için çoğu zaman en yüksek risk coverage'ini sağlayan modeldir.

Bu yaklaşım attacker realism'ini tamamen kaybetmez. Aynı zamanda sınırlı test süresinde authorization, session ve business logic üzerine derinleşmeyi sağlar.

White box

Source code, configuration, architecture ve internal documentation erişimi dahil edilebilir. Runtime pentest ile code-level root cause aynı çalışmada ilişkilendirilebilir.

White box test otomatik olarak source code review değildir. Teklifte review depth, repository scope, branch, language, manual review süresi ve SAST kullanımı ayrıca tanımlanmalıdır.

Yaklaşımların gerçekte ne gösterdiğini Black box, gray box, white box sızma testi: Hangisi gerçekten neyi gösterir? yazımızda karşılaştırıyoruz.

Yaklaşım seçiminde doğru soru

“Saldırgan bunları bilmez” ifadesi her zaman iyi kapsam gerekçesi değildir. Testin amacı bilinmeyen attack surface'i ölçmekse black box uygundur. Ama amaç business logic ve tenant isolation hakkında assurance üretmekse tester'a gerekli context ve account verilmelidir.

Kısıtlı bütçede yalnızca realism'e yatırım yapmak coverage'i azaltabilir. Scope dokümanı bu trade-off'u açıkça göstermelidir.

10. Web application türü scope'u nasıl değiştirir?

Her web application aynı test yöntemini gerektirmez.

Traditional server-rendered application

Route, form, cookie session, server-side validation, access control ve CSRF akışları öne çıkar. Hidden field ve multi-step workflow'lar dikkatle incelenmelidir.

Single Page Application

Frontend route'ları security boundary değildir. API endpoint'leri, client-side state, token storage, CORS, source map, runtime configuration ve DOM-based attack surface kapsamda olmalıdır.

Multi-tenant SaaS

Tenant isolation temel kapsam maddesidir. İki tenant, cross-user ve cross-role data seti gerekir. Custom domain, organization invitation, sharing, billing ve support impersonation ayrı flow olarak ele alınır.

E-commerce

Price, quantity, discount, shipping, payment callback, refund, inventory reservation, gift card, loyalty point ve order state testleri önemlidir. Gerçek charge oluşmaması için sandbox veya test payment instrument sağlanmalıdır.

Financial application

Maker-checker, beneficiary, transaction limit, step-up authentication, idempotency, reconciliation, statement export ve approval segregation test edilir. Proof boundary ve test account balance planlanmalıdır.

Healthcare application

Patient-provider relationship, consent, record sharing, break-glass access, sensitive field masking, export ve audit trail kritik olabilir. Evidence içinde real patient data kullanılmamalıdır.

File processing platform

Upload, content-type validation, parser, conversion, preview, metadata, antivirus pipeline, object storage, signed URL, file ownership ve asynchronous job'lar scope'a dahil edilmelidir.

Marketplace veya platform

Buyer, seller, moderator, support, payment, dispute, messaging, listing lifecycle ve content moderation flow'ları birlikte incelenir.

B2B partner portal

Organization onboarding, partner API key, IP allowlist, certificate authentication, bulk file transfer, shared account ve offboarding riskleri öne çıkar.

11. Third-party integration'lar kapsamda nasıl ele alınmalı?

Third-party service'i out of scope ilan etmek, integration riskini de out of scope yapmaz.

Payment provider örneğinde provider altyapısına saldırı yapılmaz. Fakat şu alanlar application scope'unda kalır:

• Redirect parameter'ları
• Amount ve currency integrity
• Callback authentication
• Webhook signature validation
• Replay protection
• Order ile transaction binding
• Success ve failure state handling
• User-controlled return URL
• Refund authorization
• Error ve timeout behavior

Benzer şekilde third-party identity provider'ın platformu test edilmez, application'ın token validation ve account linking logic'i test edilir.

Integration inventory şu alanları içermelidir:

Shared responsibility açık yazılmalı

Cloud ve SaaS ortamlarında hangi configuration'ın kuruma, hangisinin provider'a ait olduğu belirlenmelidir. NCSC de cloud-based platform scope'unda shared security model'in anlaşılmasını önerir.

Provider testing policy, rate limit ve notification requirement'ları kickoff öncesinde kontrol edilmelidir.

12. Hangi test alanları açıkça scope'a yazılmalı?

“OWASP Top 10 test edilecektir” tek başına yeterli coverage tanımı değildir. OWASP Top 10 bir awareness ve risk listesi sağlar. Test methodology ve verification catalog olarak OWASP WSTG ve uygun olduğunda OWASP ASVS kullanılabilir.

Web application scope'u risk bazlı olarak şu alanları içerebilir:

Information gathering ve attack surface

• Application fingerprinting
• Hidden content ve route discovery
• Exposed file ve backup
• Source map ve client configuration
• Public API documentation
• Metadata ve version disclosure
• Alternate host ve environment

Configuration ve deployment

• TLS ve security header
• CORS
• Cache behavior
• Error handling
• Debug mode
• Default file ve interface
• HTTP method
• Host header handling
• Reverse proxy ve CDN trust
• Cloud storage exposure

Identity management

• Registration
• Username ve account enumeration
• Role provisioning
• Organization invitation
• Account lifecycle
• Dormant ve suspended account

Authentication

• Login bypass
• Password policy
• Credential stuffing resistance için güvenli validation
• MFA flow
• Password reset
• SSO ve federation
• Account linking
• Step-up authentication

Authorization

• Horizontal authorization
• Vertical authorization
• Cross-tenant access
• Object-level authorization
• Property-level authorization
• Function-level authorization
• File ve export authorization
• Admin ve support access

Session management

• Cookie security
• Token storage
• Session fixation
• Token rotation
• Logout ve revoke
• Concurrent session
• Role change sonrası session
• Refresh token lifecycle

Input validation ve server-side injection

• SQL ve NoSQL injection
• Command injection
• Template injection
• LDAP ve XPath injection
• SSRF
• Path traversal
• File inclusion
• Deserialization
• XML parser riskleri
• Header ve response injection

Business logic

• Workflow bypass
• State transition
• Price ve quantity manipulation
• Replay
• Race condition
• Limit bypass
• Approval bypass
• Duplicate transaction
• Feature abuse
• Sensitive business flow automation

File handling

• Upload validation
• Content sniffing
• Parser attack surface
• File name ve path handling
• Malware scanning flow
• Preview ve conversion
• Storage permission
• Signed URL
• Metadata leakage

Client-side

• Reflected, stored ve DOM-based XSS
• DOM manipulation
• Cross-window communication
• Clickjacking
• Client-side redirect
• Browser storage
• Service worker
• Dependency exposure
• CSP behavior

API-specific

• BOLA
• Broken authentication
• Object property authorization
• Function authorization
• Resource consumption
• Sensitive business flow abuse
• SSRF
• Inventory ve version management
• Unsafe API consumption
• GraphQL resolver authorization
• Batch ve alias abuse

Bu liste her projede bütün maddelerin aynı depth'te uygulanacağı anlamına gelmez. Application capability ve riskine göre applicable test case'ler belirlenmeli, uygulanmayan alanlar işaretlenmelidir.

OWASP ASVS nasıl kullanılmalı?

OWASP ASVS 5.0.0, application security control'lerini requirement düzeyinde ifade etmek için kullanılabilir. Scope dokümanında hedeflenen ASVS level veya seçili requirement seti yazılabilir.

Ancak “ASVS uyumluluğu” denecekse bütün applicable requirement'ların nasıl verify edileceği, source veya architecture evidence gerekip gerekmediği ve test limitation'ları açıklanmalıdır. Sınırlı black-box pentest ile her ASVS requirement'ı hakkında assurance verilemez.

13. Test edilmeyecek alanlar nasıl yazılmalı?

Out-of-scope listesi net değilse tester gereksiz risk alır veya kritik component'e dokunmaz.

Kötü örnek:

İyi örnek:

• Denial of service ve yüksek hacimli load test yasaktır
• Gerçek customer account'ları kullanılmayacaktır
• DELETE action yalnızca belirlenmiş test object'lerinde uygulanacaktır
• E-mail ve SMS gönderimi test recipient'leriyle sınırlandırılacaktır
• Gerçek payment oluşturulmayacaktır
• Third-party provider domain'lerinde automated scan yapılmayacaktır
• Social engineering kapsam dışıdır
• Source code review bu engagement'a dahil değildir
• Mobile binary test edilmeyecek, fakat kullandığı /api/v1 kapsam içindedir
• Object storage control plane kapsam dışı, application tarafından üretilen signed URL flow'u kapsam içindedir

Out-of-scope kararının security sonucu ayrıca düşünülmelidir. Admin panel kapsam dışı bırakılıyorsa application'ın en yüksek privilege path'i test edilmiyor demektir. Bu limitation raporda görünmelidir.

14. Rules of Engagement hangi maddeleri içermeli?

NIST, Rules of Engagement'i test öncesinde oluşturulan, security testing'in yürütülmesine ilişkin ayrıntılı guideline ve constraint'ler olarak tanımlar. ROE tester'a tanımlı activity'leri ek izin beklemeden yürütme yetkisi verir.

Web pentest için ROE şu başlıkları içermelidir:

• Yetki veren kurum ve system owner
• In-scope asset'ler
• Out-of-scope asset'ler
• Test başlangıç ve bitiş zamanı
• Timezone
• İzin verilen IP source'ları
• Tester contact bilgisi
• Kurum technical contact'ı
• Emergency stop contact'ı
• Incident escalation kanalı
• Test account ve data kuralları
• Automated scanning rate'i
• Brute force ve credential testing sınırı
• Resource consumption testi sınırı
• File upload payload kuralları
• Data access ve download limiti
• Evidence handling
• Sensitive finding notification süresi
• WAF veya SOC whitelist durumu
• Cleanup ve persistence yasağı
• Third-party boundary
• Retest yetkisi

Whitelist yapılmalı mı?

Amaç application code ve logic coverage'i ise WAF tester IP'sini sürekli block ediyorsa kontrollü whitelist düşünülebilir. Ancak bu durumda WAF'ın gerçek behavior'ı ayrıca test edilmelidir.

İki fazlı model uygulanabilir:

1. 1Normal production control'leriyle external behavior doğrulanır.
2. 2Coverage'i engelleyen control için onaylı bypass veya whitelist ile application layer derinleştirilir.

Whitelist kullanımı raporda belirtilmelidir. Aksi halde test sonucu gerçek external exposure ile karıştırılır.

15. Tester'a hangi bilgi ve erişimler verilmeli?

Gray-box testte doğru input sağlamak güvenliği azaltmaz. Sınırlı sürede daha fazla risk coverage'i üretir.

Minimum bilgi paketi

• Application'ın business amacı
• In-scope ve out-of-scope listesi
• Architecture ve data flow özeti
• Environment bilgisi
• Role ve permission açıklaması
• Test account'ları
• İki user ve gerekiyorsa iki tenant
• Kritik business flow listesi
• API documentation
• Test data hazırlama yöntemi
• Yasak action'lar
• Technical contact
• Known issue ve önceki önemli findings
• Release veya build version

API testi için yararlı artifact'lar

• OpenAPI veya Swagger specification
• Postman collection
• GraphQL schema veya introspection policy bilgisi
• Authentication ve token alma adımları
• Client credential
• Webhook sample ve signature documentation
• Error code catalog
• Rate limit bilgisi
• Deprecated endpoint listesi
• Object relationship açıklaması

Business logic testi için yararlı artifact'lar

• User journey
• State diagram
• Role-permission matrix
• Approval limit'leri
• Discount ve pricing rule'ları
• Transaction state'leri
• Expected negative behavior
• Test payment veya sandbox bilgisi
• Known fraud control'leri

Bu belgelerin eksik olması testin yapılmasını engellemez. Tester reconnaissance ve traffic analysis ile önemli bölümü çıkarabilir. Fakat süre aynı tutulursa documentation eksikliği deep testing süresini azaltır.

Secret paylaşımı nasıl yapılmalı?

Password, API key ve token e-mail'in açık gövdesinde gönderilmemelidir. Approved secret sharing channel kullanılmalı, access süreli olmalı ve test sonrasında credential rotate veya revoke edilmelidir.

Tester'a production customer credential verilmemelidir. Dedicated test identity oluşturulmalıdır.

16. Test data nasıl planlanmalı?

Authorization ve business logic testlerinin kalitesi büyük ölçüde test data'ya bağlıdır.

“Tester kendi verisini oluştursun” yaklaşımı bazı flow'larda çalışır. Fakat approved invoice, archived project, refunded payment veya suspended membership gibi state'leri tester tek başına üretemeyebilir.

Test data planı şunları içermelidir:

• Her role için account
• Her tenant için object'ler
• Own ve foreign object seti
• Farklı lifecycle state'leri
• Min, max ve boundary value'lar
• Approved ve rejected transaction
• Expired invitation veya token
• Revoked share
• Archived ve soft-deleted record
• File type ve size örnekleri
• Test payment instrument
• Synthetic sensitive data

Production data neden kullanılmamalı?

Gerçek personal veya customer data'ya gereksiz erişim privacy ve evidence riskini artırır. Mümkün olduğunda synthetic data kullanılmalıdır.

Production üzerinde mevcut gerçek data kaçınılmaz biçimde görünürse tester minimum access ilkesini izlemeli, toplu download yapmamalı ve report evidence'ını maskelemelidir.

Test data temizliği

Test sırasında oluşturulan user, order, file, webhook subscription, API key ve session'lar operation sonrasında temizlenmelidir. Hangi tarafın cleanup yapacağı scope'ta yazılmalıdır.

Web pentest eforu nasıl hesaplanmalı?

Eforu yalnızca screen veya endpoint sayısıyla hesaplamak yanlış fiyat ve coverage üretir. Daha sağlıklı estimation birden fazla complexity driver kullanır.

Eforu artıran temel faktörler

• Authentication flow sayısı
• MFA ve SSO integration'ı
• User role sayısı
• Tenant sayısı
• Permission relationship karmaşıklığı
• Critical business flow sayısı
• API endpoint ve method sayısı
• GraphQL veya WebSocket gibi ek protocol'ler
• File upload ve parser sayısı
• Payment veya financial action
• Admin ve backoffice function'ları
• Legacy version'lar
• Third-party callback ve webhook'lar
• Asynchronous processing
• Environment sayısı
• Source code review beklentisi
• Retest kapsamı
• Compliance mapping
• Rapor dili ve deliverable sayısı

Basit complexity modeli

Kurum ilk estimation için aşağıdaki tabloyu kullanabilir:

Bu tablo günlük eforu otomatik üretmez. Provider'ın riskli alanları görmesini ve teklif varsayımlarını açık yazmasını sağlar.

Endpoint sayısı yine de gerekli mi?

Evet, API workload için yararlıdır. Ancak method, authentication ve role context'iyle verilmelidir. Yüz adet birbirine benzeyen read-only endpoint ile yirmi adet complex transaction endpoint aynı effort'e sahip olmayabilir.

Bütçe yetersizse kapsam nasıl daraltılmalı?

Rastgele endpoint çıkarmak yerine risk bazlı phase uygulanmalıdır:

1. 1Critical business flow'lar
2. 2Authentication ve account recovery
3. 3Authorization ve tenant isolation
4. 4Sensitive data ve file handling
5. 5Payment, approval ve privileged action
6. 6Internet-facing API ve legacy version
7. 7Daha düşük impact'li content ve secondary feature'lar

Daraltılan alanlar “test edildi” gibi raporlanmamalıdır. Coverage limitation açıkça gösterilmelidir.

Örnek web application pentest scope matrix

Aşağıdaki örnek, teknik ve business kapsamın tek tabloda nasıl birleştirilebileceğini gösterir.

Bu matrix'in yanında role-permission ve business flow tabloları bulunmalıdır.

Tam örnek role-permission matrix

Bu tablo yalnızca tester için değildir. Product owner'ın authorization expectation'larını doğrulamasını sağlar. “Support başka user'ın invoice'ını görür mü?” sorusu test sırasında değil scope sırasında karara bağlanır.

Scope ile methodology arasındaki fark nedir?

Scope neyin test edileceğini tanımlar. Methodology nasıl test edileceğini açıklar.

Scope örneği:

Methodology örneği:

İkisi birbirinin yerine geçmez. “OWASP'a göre test edilsin” asset, role ve flow kapsamını belirtmez. Domain listesi de test depth'ini açıklamaz.

Checklist compliance ile risk-based testing dengesi

WSTG veya ASVS coverage consistency sağlar. Tester yalnızca aklına gelen technique'lerle ilerlemez. Ancak uygulamaya özgü business logic, threat model ve architecture riskleri checklist'in ötesinde ele alınmalıdır.

En iyi yaklaşım iki katmanlıdır:

1. 1Applicable standard test case'leriyle baseline coverage
2. 2Application'a özgü attack path ve abuse case'lerle derinlik

Scope freeze ne zaman yapılmalı?

Scope, teklif öncesinde yeterince netleşmeli ve kickoff sonunda freeze edilmelidir. Fakat application test boyunca değişebilir.

Freeze edilen alanlar:

• Asset listesi
• Environment
• Role ve account seti
• Critical flow'lar
• Test teknikleri
• Out-of-scope alanlar
• Timeline
• Deliverable
• Effort varsayımları

Test sırasında yeni endpoint bulunursa ne olur?

Change process önceden yazılmalıdır:

1. 1Tester yeni asset veya route'u bildirir.
2. 2Ownership doğrulanır.
3. 3Risk ve effort etkisi değerlendirilir.
4. 4Kapsama dahil edilirse yazılı onay alınır.
5. 5Dahil edilmezse limitation ve follow-up recommendation kaydedilir.

Tester'ın browser traffic'inde gördüğü her third-party host'a otomatik olarak saldırması doğru değildir.

Test sırasında release yapılırsa ne olur?

Build değişimi bulguların yeniden üretilebilirliğini ve coverage'i etkiler. Scope dokümanında change freeze beklentisi veya deployment notification süreci bulunmalıdır.

Critical hotfix dışında test boyunca stable build tercih edilir. Release zorunluysa version, time ve affected component paylaşılmalıdır. Gerekirse ilgili alanlar yeniden test edilir ve effort etkisi değerlendirilir.

Deliverable ve kabul kriterleri scope'a dahil edilmeli mi?

Evet. Aynı teknik test, çok farklı rapor kalitesinde teslim edilebilir.

Beklenen deliverable'lar teklif öncesinde yazılmalıdır:

• Executive summary
• Scope ve limitation özeti
• Methodology
• Asset ve role coverage matrix
• Technical findings
• Reproduction steps
• Maskelenmiş request ve response evidence
• Business impact
• Severity ve scoring method
• Root cause
• Remediation recommendation
• Affected endpoint ve role'ler
• Positive finding veya control observation
• Test account ve artifact cleanup kaydı
• Retest report
• Executive ve technical presentation

İyi finding için kabul kriteri

Bir finding en az şu sorulara cevap vermelidir:

• Nerede bulundu?
• Hangi precondition gerekiyor?
• Hangi role ve tenant etkileniyor?
• Nasıl reproduce edilir?
• Ne kanıtlandı?
• Sensitive data maskelendi mi?
• Business impact nedir?
• Root cause nedir?
• Hangi benzer path'ler etkilenebilir?
• Nasıl kalıcı düzeltilir?
• Retest nasıl yapılacak?

“Scanner critical buldu” report acceptance için yeterli değildir.

Severity yöntemi

CVSS kullanılacaksa version ve environmental context belirtilmelidir. Business logic finding'lerinde technical score tek başına yeterli olmayabilir. Data sensitivity, role, tenant crossing, scale, automation ve financial impact birlikte değerlendirilmelidir.

Retest kapsamı

Retest'in ücretsiz veya ücretli olması kadar neyi kapsadığı önemlidir:

• Yalnızca original PoC mi?
• Benzer endpoint'ler de kontrol edilecek mi?
• Fix'in regression etkisi değerlendirilecek mi?
• Kaç retest turu var?
• Hangi süre içinde kullanılmalı?
• Yeni finding ortaya çıkarsa nasıl ele alınacak?

Kapsam dokümanında retest window ve expected evidence yazılmalıdır.

Web application pentest scope'unda en sık yapılan hatalar

Yalnızca ana domain'i yazmak

Frontend'in kullandığı API, identity, file, admin ve legacy component'ler görünmez kalır. Host inventory ve data flow birlikte hazırlanmalıdır.

Ekran sayısını test büyüklüğü sanmak

Tek ekran arkasında onlarca API ve complex authorization bulunabilir. On ekranlı content site ise çok daha düşük risk taşıyabilir. Role, flow ve method complexity değerlendirilmelidir.

API'yi web kapsamına otomatik dahil saymak

Provider yalnızca browser üzerinden görülen endpoint'leri test edebilir. Hidden, mobile, partner ve deprecated API route'ları kaçabilir. API base URL, version ve documentation açıkça yazılmalıdır.

Sadece bir user vermek

Horizontal authorization ve IDOR testleri zayıflar. Multi-tenant sistemde yalnızca cross-role değil cross-user ve cross-tenant data seti gerekir.

Admin role'ü dışarıda bırakmak

En yüksek impact'li export, impersonation, configuration ve user management function'ları test edilmez. Admin panel test edilemiyorsa bu limitation yönetim raporunda görünmelidir.

Business rule'ları tester'dan saklamak

“Gerçek saldırgan bunları bilmez” düşüncesi gray-box coverage'i azaltır. Tester expected behavior'ı bilmeden logic flaw'u feature sanabilir veya normal iş kuralını açık diye raporlayabilir.

Production yerine temsil gücü düşük staging vermek

Mock payment, bypass edilmiş SSO, debug mode ve farklı API version kullanan staging production assurance sağlamaz. Parity farkları yazılmalı ve production doğrulaması planlanmalıdır.

Third-party'yi tamamen görmezden gelmek

Provider platformu out of scope olabilir. Fakat callback, token, redirect, data mapping ve signature validation application'ın sorumluluğundadır.

“OWASP Top 10 test edilsin” demek

Bu ifade role, endpoint, flow, environment, test depth ve deliverable belirtmez. WSTG test area'ları ve application-specific abuse case'ler ayrıca tanımlanmalıdır.

Automated scan ile pentest'i aynı kapsamda düşünmek

Scanner geniş attack surface'te signal üretir. Manual pentest authorization, state, chaining ve business impact'i değerlendirir. Teklifte manual test depth ve false positive validation yazılmalıdır.

Kaynak kod analizini farkında olmadan scope'a eklemek

White-box context verilmesi tam secure code review anlamına gelmez. Repository, language, branch, manual review depth ve SAST beklentisi ayrı efor gerektirir.

Kaynak kod analizinin runtime testten neden farklı problem çözdüğünü Kaynak kod analizi ile sızma testi aynı problemi çözmez: nerede ayrışır? yazımızda açıklıyoruz.

Test sırasında sürekli release yapmak

Coverage belirsizleşir, bulgu evidence'ı eski build'e ait kalır ve retest ile original test birbirine karışır. Change management kuralı scope'ta olmalıdır.

Riskli action'ları belirsiz bırakmak

Tester güvenlik için kritik testleri atlayabilir veya yanlışlıkla production etkisi oluşturabilir. Delete, payment, notification, upload, bulk ve rate limit sınırları tek tek yazılmalıdır.

Retest'i tek cümleyle bırakmak

Original request'in artık 403 dönmesi systemic fix kanıtı olmayabilir. Retest'in benzer path, role ve regression coverage'i tanımlanmalıdır.

Teklifleri karşılaştırırken nelere dikkat edilmeli?

En düşük gün sayısı her zaman en verimli teklif değildir. İki provider aynı “bir web uygulaması” ifadesine farklı coverage yükleyebilir.

Teklif karşılaştırma tablosu şu alanları içerebilir:

Sorulması gereken provider soruları

1. 1Scope estimate'ini hangi complexity factor'lere göre yaptınız?
2. 2Hangi testler manual, hangileri automated yapılacak?
3. 3Authorization için kaç user ve tenant gerekiyor?
4. 4API documentation eksikse inventory nasıl çıkarılacak?
5. 5Business logic flow'ları nasıl modelleyeceksiniz?
6. 6Production safety ve emergency stop nasıl yönetilecek?
7. 7Third-party integration boundary'sini nasıl test edeceksiniz?
8. 8Critical finding ne kadar hızlı bildirilecek?
9. 9Evidence ve credential nerede saklanacak?
10. 10Report sample içinde request-response ve root cause bulunuyor mu?
11. 11Retest yalnızca original endpoint'i mi kapsıyor?
12. 12Test edilen ve edilmeyen alanları coverage matrix ile gösterecek misiniz?

Provider'ın “her şeyi test ederiz” cevabı iyi kapsam değildir. Applicability ve limitation gösterebilen teklif daha güvenilirdir.

Kickoff toplantısında cevaplanması gereken sorular

Kickoff yalnızca tarih belirleme toplantısı olmamalıdır.

Business soruları

• Application hangi kritik hizmeti sunuyor?
• En hassas data ve action hangileri?
• Hangi abuse scenario kurum için kabul edilemez?
• Yakın dönemde hangi büyük değişiklik yapıldı?
• Önceki incident veya finding hangi alandaydı?

Technical sorular

• Frontend hangi API ve service'lerle konuşuyor?
• Authentication ve token lifecycle nasıl çalışıyor?
• Kaç role ve tenant modeli var?
• Admin ve support path'leri nelerdir?
• File processing ve background job var mı?
• Legacy version veya alternate client bulunuyor mu?
• WAF, CDN ve rate limit nasıl çalışıyor?

Operation soruları

• Hangi environment test edilecek?
• Test account'ları hazır mı?
• Test data kim tarafından oluşturulacak?
• Tester source IP'leri whitelist edilecek mi?
• Riskli action sınırı nedir?
• Critical finding kime bildirilecek?
• Gerçek incident ile test nasıl ayrıştırılacak?
• Test sonunda credential ve data nasıl temizlenecek?

Delivery soruları

• Rapor dili nedir?
• Executive ve technical report ayrı mı?
• Severity yöntemi nedir?
• Technical presentation yapılacak mı?
• Retest kaç tur ve hangi window içinde?
• Rapor kimlerle güvenli biçimde paylaşılacak?

Kopyalanabilir web uygulaması sızma testi kapsam şablonu

Aşağıdaki yapı RFP, teklif talebi veya internal scope formu için başlangıç olarak kullanılabilir.

1. Proje bilgisi

• Uygulama adı:
• Business owner:
• Technical owner:
• Security contact:
• Test amacı:
• Beklenen test tarihi:
• Production release tarihi:

2. Business context

• Uygulamanın sunduğu hizmet:
• Kritik business function'lar:
• Sensitive data type'ları:
• Kabul edilemez impact senaryoları:
• Regulatory veya contractual requirement:

3. Asset inventory

• Frontend domain'leri:
• API base URL ve version'ları:
• Authentication domain'i:
• Admin ve support interface'leri:
• Mobile backend:
• File ve object storage flow'u:
• Webhook endpoint'leri:
• Legacy ve deprecated asset'ler:
• Environment'lar:
• Third-party dependency'ler:

4. Architecture ve technology

• Frontend technology:
• Backend technology:
• API protocol:
• Identity protocol:
• Hosting ve cloud provider:
• WAF, CDN ve API gateway:
• Database ve storage type:
• Asynchronous worker veya queue:

5. Identity ve authorization

• User role listesi:
• Tenant modeli:
• Test account sayısı:
• MFA method'u:
• SSO veya federation:
• Privileged function'lar:
• Impersonation veya delegation:
• Account lifecycle state'leri:

6. Critical business flow

• Registration ve verification:
• Login ve recovery:
• Main transaction flow:
• Payment veya approval:
• File upload ve processing:
• Sharing ve permission:
• Export ve reporting:
• Account closure:
• Diğer kritik flow'lar:

7. Test yaklaşımı

• Black box, gray box veya white box:
• OWASP WSTG coverage:
• ASVS requirement veya level beklentisi:
• API test kapsamı:
• Business logic test kapsamı:
• Automated ve manual test yaklaşımı:
• Source code review dahil mi:

8. Test data ve erişim

• Test account'ları:
• Test tenant'ları:
• VPN veya IP allowlist:
• API documentation:
• Test payment instrument:
• Synthetic data:
• File sample'ları:
• Secret paylaşım kanalı:

9. Rules of Engagement

• Test window ve timezone:
• Yasak action'lar:
• Request rate sınırı:
• E-mail ve SMS sınırı:
• Payment ve refund sınırı:
• Data download sınırı:
• File upload sınırı:
• Third-party boundary:
• Emergency stop:
• Critical finding notification:

10. Deliverable

• Executive summary:
• Technical report:
• Evidence requirement:
• Severity method:
• Coverage matrix:
• Technical workshop:
• Retest turu:
• Retest süresi:
• Raporlama dili:

11. Limitation ve varsayımlar

• Out-of-scope asset'ler:
• Verilmeyen role'ler:
• Production-staging farkları:
• Test edilmeyen integration'lar:
• Zaman ve efor varsayımları:
• Change freeze kuralı:

Bu form doldurulduğunda teklif veren ekip yalnızca fiyat değil risk coverage'i üzerinden plan yapabilir.

Sonuç: İyi kapsam daha uzun liste değil, daha doğru güvenlik sınırıdır

Web application pentest scope'u domain listesinden ibaret görüldüğünde iki sonuç ortaya çıkar. Ya tester güvenli tarafta kalıp kritik component'lere dokunmaz ya da sınır belirsizliği içinde gereksiz operasyonel risk alır.

Doğru kapsam şu soruların tamamına cevap verir:

1. 1Hangi business function korunuyor?
2. 2Application hangi component ve integration'lardan oluşuyor?
3. 3Hangi host, API, version ve environment test edilecek?
4. 4Hangi role, tenant ve object relationship'leri doğrulanacak?
5. 5Hangi critical flow ve lifecycle state'leri incelenecek?
6. 6Test black box, gray box veya white box hangi depth'te yapılacak?
7. 7Production üzerinde hangi action'lar güvenli biçimde uygulanabilir?
8. 8Third-party boundary nerede başlıyor?
9. 9Tester'a hangi account, documentation ve test data sağlanacak?
10. 10Hangi coverage, evidence ve retest sonucu teslim kabulü sayılacak?

Kapsam net olduğunda daha fazla bulgu garantisi oluşmaz. Daha değerli bir şey oluşur: Testin hangi güvenlik iddiasını desteklediği ve hangi alanlar hakkında hiçbir sonuç üretmediği dürüst biçimde bilinir.

Secnodex, web application pentest kapsamını yalnızca domain ve ekran sayısıyla fiyatlandırmaz. Application architecture, API surface, authentication, role ve tenant modeli, business logic, file processing, integration, test environment ve production riskini birlikte değerlendirir. Test öncesinde coverage matrix ve Rules of Engagement'i netleştirir, çalışma sonunda test edilen alanları evidence ile raporlar. Uygulamanız için doğru kapsamı hazırlamak üzere Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• OWASP Web Security Testing Guide – Stable
• OWASP Web Security Testing Guide – Latest
• OWASP Application Security Verification Standard 5.0.0
• OWASP API Security Top 10:2023
• OWASP API9:2023 – Improper Inventory Management
• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NIST CSRC – Rules of Engagement Glossary
• UK NCSC – Building and Operating a Secure Online Service
• UK NCSC – Penetration Testing
• UK NCSC – CHECK Penetration Testing
• PCI Security Standards Council – PCI DSS v4.0.1