Staging or production?

Staging, if it genuinely mirrors production including data volume and integrations. Frequently it does not, and a finding that only exists in production is the one that matters, so the choice is made per application rather than by policy. Where production is the only realistic target, destructive test cases are removed rather than the environment being avoided.

How many accounts do you need?

At least two of every role, plus one privileged account, plus the ability to register a fresh one if the product allows self-service signup. Two accounts per role is not a convenience, it is what makes authorisation testable at all.

Do you test single-page applications differently?

The interface changes, the target does not. A single-page application makes the API more visible rather than less, and the testing is against that API. The front-end framework matters mainly for how it handles rendering of untrusted content and how much it leaks about routes the account cannot use.

Service

Web Application Testing

Manual, business-logic-aware testing of the applications your customers touch.

Automated scanning catches injection and misconfiguration, and it catches them well enough that they are rarely the interesting finding any more. What it cannot catch is the class of flaw that comes from how your application is meant to work: an order repriced between steps, a role that can read another tenant's records, a workflow completed out of sequence. Finding those requires understanding what the application is for, which is why this work is manual and starts with a conversation about your domain.

How this works

Two accounts of every role, always

Most authorisation testing is done from one account, which can only ever find missing authentication. The interesting failures need a second account at the same privilege level: fetch object 1041 as user A, then request the same object as user B. Without that second account there is no way to distinguish a record that does not exist from one that exists and should have been refused, and that distinction is the entire test.

The API behind the interface

The front end hides endpoints and enforces rules the server may not. Actions are commonly removed from the interface for users who should not perform them while the endpoint behind the action still accepts the request from any authenticated session. Testing therefore works against the API directly as well as through the browser, including the endpoints no released client version calls any more.

Business logic and state

Multi-step flows are tested out of order, in parallel, and resumed after abandonment. Prices, quantities, discounts and identifiers are modified at each step to see which the server re-validates and which it trusts because an earlier step already did. Anything with a usage limit is tested for the limit itself holding under concurrent requests, which is where a coupon becomes unlimited.

Authentication as a whole system

Registration, login, session issue, password reset, email change, multi-factor enrolment and account recovery are tested as one connected system rather than as separate features, because the reliable way through is usually a seam between two of them rather than a weakness in any one.

What we look for

Object-level authorisation: whether the server checks that a record belongs to the caller, not merely that the caller is logged in
Function-level authorisation: whether an ordinary account can call an administrative route or use a verb the interface never offers
Field-level exposure: response objects carrying tokens, internal scores or personal data the interface never displays
Mass assignment: whether a role, balance or tenant identifier can be set by adding it to a request body
Business-logic abuse specific to your product, worked out from what the product is for
Race conditions on anything with a limit, tested with concurrent requests rather than sequential ones
Session handling: fixation, insufficient invalidation on logout and password change, and tokens that outlive the events that should end them
Injection where user input reaches an interpreter, including template engines, which scanners frequently miss

What you get

Authentication, authorisation and session handling tested end to end
Business-logic and multi-tenancy abuse cases specific to your application
Proof for each finding: the request, the response, and what it exposed
Guidance on the fix that fits your stack, not a generic remediation blurb
A retest once the fixes are in

What this does not include

Load or performance testing
Automated scanning presented as the deliverable: a scanner is used where it helps, but the report is manual work
Fixing the code, though the report says specifically what to change and why
Testing of third-party services you do not control, unless you have written authorisation from them

Questions people ask

Staging or production?: Staging, if it genuinely mirrors production including data volume and integrations. Frequently it does not, and a finding that only exists in production is the one that matters, so the choice is made per application rather than by policy. Where production is the only realistic target, destructive test cases are removed rather than the environment being avoided.
How many accounts do you need?: At least two of every role, plus one privileged account, plus the ability to register a fresh one if the product allows self-service signup. Two accounts per role is not a convenience, it is what makes authorisation testable at all.
Do you test single-page applications differently?: The interface changes, the target does not. A single-page application makes the API more visible rather than less, and the testing is against that API. The front-end framework matters mainly for how it handles rendering of untrusted content and how much it leaks about routes the account cannot use.

Discuss web application testing All services