Overview

We test the way an attacker would: against the running application, with real accounts, in the environment you actually ship to. Authentication, authorisation, business logic, and the APIs sitting behind the interface.

There is no account-manager layer and no junior bench. The engineer who finds the bug writes the report, and findings arrive in your channel as they are discovered rather than as a PDF on the last day.

What is covered

• Authentication, session handling and multi-factor flows

• Access control across roles, tenants and objects

• Business-logic and workflow abuse

• Injection, deserialisation and file-handling paths

• The REST, GraphQL and webhook surface behind the UI

• Third-party integrations, OAuth and SSO flows

How it runs

Five stages: Scope, Recon, Exploit, Report, Retest. Anything critical is reported within the hour it is confirmed. The retest is included, not quoted separately.

What you get

• A working proof for every finding

• A report written around fixes, not findings

• A retest and a letter of attestation once the fixes land

• Direct access to the engineer who did the work

Method and standards

The engagement is structured against the public methodologies your reviewers already recognise, so the report maps onto whatever framework you report into without translation.

• OWASP Web Security Testing Guide and the OWASP Top 10

• OWASP API Security Top 10 for the API surface

• PTES for the shape of the engagement, CVSS alongside impact-reasoned severity

• Rules of engagement, test accounts and an abort path agreed in writing before day one