Web application penetration testing, and every app in between.

1. 01

   Scoping and access

   We agree scope, environments and test accounts up front. Testing against a staging environment that genuinely mirrors production is the single biggest factor in whether findings translate, so we would rather have that conversation before the engagement than explain a gap afterwards.

2. 02

   Mapping the application

   Every route, parameter, upload, integration and authentication flow gets mapped before exploitation begins. Automated scanning has a place here, but it is the starting point of the work rather than the deliverable.

3. 03

   Authenticated testing across every role

   Most real breaches begin with a valid session rather than an anonymous request. We test as each user role you have, and specifically test whether one role can reach another's data — the broken access control that tops the OWASP Top 10 and that unauthenticated scanning cannot see.

4. 04

   Business logic and chained attacks

   Scanners find injection. They do not find that a discount code can be applied twice, or that an ID in a request can be incremented to read another tenant's records. Chaining low-severity findings into something that actually matters is the part that needs a person.

5. 05

   Reporting and developer debrief

   Findings arrive with reproduction steps, evidence, severity and a concrete fix — written for the developer who has to make the change, not just for the security team commissioning the test. We walk the engineering team through it live.

6. 06

   Fix window and free retest

   Fix the findings and we retest at no extra cost, so the engagement ends with proof the issues are closed rather than a list of things to do.

Common questions

What is web application penetration testing?

Web application penetration testing is a hands-on security assessment of an application, its front end, APIs, authentication, and business logic, to find the vulnerabilities an attacker could exploit: broken access control, injection, authentication bypass, and logic abuse like account takeover. Unlike an automated scan, it tests the flows and edge cases a real attacker would, across roles and states, and proves what data or actions they could actually reach.

Do you test APIs and mobile apps as well as web applications?

Yes. SubRosa tests web applications, REST and GraphQL APIs (against the OWASP API Top 10), and iOS and Android mobile apps, plus source code review and thick-client testing. Most modern applications share logic across all of these, so we test them together to catch flaws that only appear when the layers interact.

How is application penetration testing different from a vulnerability scan?

A vulnerability scan is automated and finds known, signature-based issues. Application penetration testing is performed by security engineers who test business logic, authorization, and chained conditions that scanners cannot understand, such as account takeover, privilege escalation, and IDOR/BOLA, and prove real, exploitable impact rather than a list of potential issues.

How long does an application penetration test take?

Typically one to three weeks of active testing for a single application, driven by the number of user roles, the size of the authenticated surface and how many integrations are in scope. An application with four distinct permission levels takes materially longer than one with a single user type, because each role has to be tested against every other.

Do you test against production or staging?

Staging, where it genuinely mirrors production — same code, same configuration, representative data. Where a staging environment does not exist or differs meaningfully, we will test production under agreed constraints rather than give you findings from an environment that does not reflect what your users touch.

How is this different from a vulnerability scan?

A scanner finds known patterns: injection, outdated libraries, missing headers. It cannot tell that a discount code can be applied twice, that an object ID can be incremented to read another customer's data, or that three low-severity findings chain into account takeover. Those need a person who understands what your application is for, and they are consistently where the real risk sits.

What do developers actually receive?

Findings with reproduction steps, evidence, severity and a concrete remediation, written for the engineer making the change rather than only for the security team commissioning the test. We debrief the engineering team directly, and retest at no extra cost once fixes are in.