A web application penetration test is a manual, authorised assessment of your application's security by someone trying to break it the way an attacker would. A typical small-to-mid-size application takes 5 to 15 consultant-days and costs roughly 4,000 to 20,000 US dollars depending on complexity and who performs it.
What gets tested
A competent test follows the OWASP Web Security Testing Guide and covers, at minimum:
Authentication — password policy, credential stuffing resistance, MFA implementation and bypass, password reset token strength and reuse, account enumeration, brute-force protection.
Session management — token generation, expiry, invalidation on logout and password change, cookie flags, session fixation, concurrent session handling.
Authorisation and access control — vertical escalation (user reaching admin functions), horizontal escalation (user reaching another user's data), tenant isolation, insecure direct object references, forced browsing to hidden endpoints. This category produces the highest-impact findings in most engagements.
Input handling — SQL and NoSQL injection, cross-site scripting (stored, reflected, DOM-based), template injection, command injection, XML external entities, deserialisation flaws.
Business logic — price and quantity manipulation, race conditions, workflow bypass, coupon and referral abuse, replaying signed requests.
File handling — upload validation, path traversal, unrestricted file types, storage exposure.
Server-side request forgery and cloud metadata access.
Client-side security — CSRF protection, CORS configuration, clickjacking, postMessage handling, third-party script exposure.
Configuration and infrastructure — TLS configuration, security headers, exposed admin panels, verbose errors, outdated components with known CVEs, forgotten staging environments.
Cryptography — sensitive data at rest and in transit, token signing, secret management.
What drives duration and cost
- Number of distinct roles and tenant types, not number of pages.
- Number of unique workflows and API endpoints behind the interface.
- Complexity of business logic — payments, trading and healthcare workflows take longer.
- Whether the tester gets documentation and credentials on day one.
- Whether a retest and attestation letter are included.
Rough guide: simple single-role application 5-8 days; multi-role SaaS with an API 10-15 days; large platform with several products 15-25 days.
Preparing for the test
Provide accounts for every role and at least two tenants.
Share an architecture diagram and any API documentation.
Test against production if you can safely, or a staging environment that genuinely mirrors it — including the WAF, rate limiting and third-party integrations.
Allowlist the tester's IPs or make a deliberate decision to test through the WAF.
Freeze major deployments during the testing window so results stay valid.
Tell your on-call team, so a test does not become an incident.
What you should receive
An executive summary written for non-technical readers, a technical findings section with severity based on real business impact, reproduction steps, evidence, specific remediation guidance, a retest report once fixes land, and an attestation letter for customers and auditors.
How often to test
Annually at minimum. Additionally after any major architectural change, a new authentication system, a new public API, a significant third-party integration, or before a major enterprise contract or funding round. Between tests, run automated dependency and configuration scanning continuously — it is cheap coverage against known issues.
---
Need a second opinion on your security posture?
I'm Michael Adeyanju, a penetration tester and security consultant working with companies globally — web app, API, mobile and network security. Based in Lagos, Nigeria, available for remote and on-site engagements worldwide.
Book a 15-minute call: cal.com/michaeladeyanju/15min
See what an engagement covers: michaeladeyanju.com/security-engineer