The challenge behind the engagement.
Web application penetration testing examines your applications the way an attacker with and without an account would. We test across every role you provision, following an established, chapter-by-chapter methodology for web application security. Work is manual, with automated tools supporting coverage rather than producing it. We exercise access controls to see whether one user can reach another user’s data or an administrator’s functions, then probe authentication and session handling, including ways to bypass multi-factor prompts or hijack a logged-in session. We test injection and input-handling flaws, business-logic abuse, unsafe file uploads, and the single sign-on flows behind the login. Findings arrive with reproduction steps, severity ratings, and fixes written for your developers. You receive an executive summary and a retest after you remediate.
For product owners and engineering managers shipping web applications that hold customer or regulated data. Common before a SOC 2 audit window, ahead of a major launch, or when a customer security review asks for a recent application test.
What we do.
What you can use.
Provision roles and environment
We ask for test accounts across every role, a stable staging or production-like environment, and any interface documentation. We agree the in-scope domains and subdomains, whether to allow our testing through a web application firewall, and how any live data touched during testing is handled and returned.
Test every role by hand
We work an established, chapter-by-chapter web testing methodology by hand: access controls for cross-user and privilege-escalation flaws, authentication and session weaknesses, injection and input-handling flaws, business-logic abuse, and unsafe file uploads. We test the single sign-on flows behind the login and chain issues into full attack paths.
Report to developers and retest
Findings arrive with reproduction steps, severity ratings, and fixes written for the developers who own the code, each tied to the category of weakness it represents. You receive an executive summary, and we retest remediated findings and issue a shareable attestation letter.
Who it’s for.
When you need it.
- Product and engineering teams shipping web applications that hold customer or regulated data
- SaaS providers whose customers ask for evidence of recent application testing
- Organizations with role-based access and complex user journeys across an application
- Teams adding authentication, payments, or sensitive workflows to an existing application
- A major release, redesign, or new feature is scheduled in the next quarter
- A customer security review or SOC 2 audit window asks for an application test
- New roles, tenants, or third-party sign-in flows were added to the application
- The application has never had an independent, manual penetration test
What the scope can include.
- 01
Test access controls across roles for cross-user and privilege-escalation flaws
- 02
Exercise authentication and session handling, including multi-factor bypass and session hijacking
- 03
Probe injection and input-handling flaws across the application’s inputs
- 04
Abuse business logic and unsafe file uploads across real user journeys
- 05
Review the single sign-on and login flows behind the application
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and reporting, plus a retest of your fixes, included. Find the size closest to yours.
One application with one or two user types and a simple sign-in
About 24–40 hoursOne business application with three to five user types, payments or integrations
About 48–72 hoursMulti-customer software platform with many user types, single sign-on, and admin tools
About 80–120 hours- Number of user types and permission levels
- Number of screens and forms that accept input
- Separation between customers on a shared platform
- Payments, file uploads, and third-party sign-in flows
Ranges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Findings grouped by category of weakness with clear reproduction steps
- Severity ratings and fixes written for the developers who own the code
- Executive summary and a retest of remediated web application findings
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
Do you test in staging or production?
Usually a staging or production-like environment that mirrors production, so we can safely exercise destructive-looking actions. We can test production when that is the only realistic option, with rules that protect data and availability agreed first. Either way we need stable test accounts for every role and coordinate any action that could affect live users.
How many roles should we provision, and is the API included?
Provide at least one account for every distinct permission level, including an administrator, so we can test authorization between roles rather than guessing at it. The application’s own interfaces are tested as part of the flows behind the pages. A standalone interface with its own consumers is better booked as a dedicated API penetration test, which goes deeper on object-level and function-level authorization.
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- OWASP Web Security Testing Guide
- OWASP Top 10 API Security Risks – 2023
- Common Vulnerability Scoring System version 4.0: Specification Document
- NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
- Penetration Testing - Amazon Web Services (AWS)