Web Application & API Penetration Testing

What we test

Testing is aligned to the OWASP Web Security Testing Guide and Application Security Verification Standard, but the methodology is a floor rather than a ceiling. Checklists find checklist bugs. The findings that matter usually come from understanding what your application is for and then abusing that.

Access control and authorisation

Consistently the most damaging category and the one automated tooling handles worst. We test with multiple user roles and accounts to find horizontal and vertical privilege escalation — one customer reading another's data, a standard user reaching admin functionality, an API returning fields the UI never shows.

Authentication and session management

Password reset flows, multi-factor implementation, session fixation and invalidation, token handling, account enumeration, and the rate limiting that is supposed to stop credential stuffing but usually does not.

Business logic

The flaws unique to your application. Negative quantities in a basket, skipping a step in a multi-stage workflow, replaying a request to apply a discount twice, manipulating a price client-side. No scanner has any concept of these because they require knowing what the correct behaviour was supposed to be.

Injection and technical vulnerabilities

SQL injection, cross-site scripting, server-side request forgery, XML external entities, insecure deserialisation, template injection, file upload handling and path traversal — verified manually and demonstrated with proof of impact rather than reported as theoretical.

APIs

REST, GraphQL and SOAP. Broken object-level authorisation, mass assignment, excessive data exposure, missing rate limits and undocumented endpoints. If you have a mobile app or single-page front end, the API behind it is very often the softer target and deserves testing in its own right.

What you need to provide

A test environment, or written authorisation to test production.
Credentials for each user role — ideally two accounts per role so we can test cross-account access.
Any API documentation, Postman collections or OpenAPI specs you have.
A named technical contact for the duration.

Grey-box testing with credentials and documentation finds substantially more in the same number of days than black-box testing. Withholding information does not make the test more realistic; it just means you pay for time spent on reconnaissance an attacker would have spent for free.

Common questions

Do you test single-page applications and modern frameworks?

Yes. React, Angular, Vue and similar front ends shift most of the meaningful attack surface to the API layer, which is where the majority of testing effort goes. Client-side issues such as DOM-based cross-site scripting and insecure client-side authorisation are covered as well.

Can you test behind a WAF?

We usually ask to be allowlisted, or to test a staging environment without the WAF in place. A web application firewall is a mitigation, not a fix — if testing only proves the WAF blocks our traffic, you learn nothing about the underlying application and you are one bypass away from exposure.

How many days will our application need?

It depends far more on the number of user roles and distinct features than on page count. A brochure site with a contact form is a short job; a multi-tenant platform with several roles, an API and a payment flow is a substantially longer one. We give an honest estimate after a scoping call rather than quoting blind.

Will you test our third-party integrations?

We will test your application's handling of them — how it validates responses, stores tokens and fails safely. We cannot test the third party's own systems without their written authorisation, and neither can anybody else legitimately.