01
Identity and authorisation
We validate boundaries between users, roles and tenants.
- IDOR/BOLA and privilege escalation
- Sessions, MFA, password reset and account recovery
- OAuth/OIDC, SSO, tokens and API keys
OFFENSIVE SECURITY / WEB · API
Web application and API penetration testing
We test the complete path from an entry point to impact on data, money and business operations — not just isolated endpoints.
Automated scanners can identify a subset of technical defects. We also test relationships between roles, tenants, functions and integrations: the places where material vulnerabilities usually emerge.
WEB · API · MOBILE
Test surface
BLACK · GREY · WHITE
Access model
MANUAL FIRST
Finding validation
RETEST
Fix verification
01 / DECISION CONTEXT
When this assessment is useful
- 01Before launching a new application, API or material feature.
- 02Ahead of customer due diligence, funding or entry into a regulated market.
- 03After changing authentication, payments, architecture or the permission model.
- 04When the team needs security evidence rather than another scanner export.
02 / TEST SURFACE
What we actually test
02
Business logic
We model a real attacker rather than stopping at an OWASP list.
- Bypassing limits, state transitions and approvals
- Manipulating price, sequence and resource ownership
- Race conditions and workflow abuse
03
Technical layer
Inputs, integrations and data flows are tested in context.
- Injection, SSRF, XSS, deserialisation and upload
- GraphQL, REST, webhooks and third-party integrations
- Secrets, misconfiguration and data exposure
03 / DELIVERY
How we run the test
- BR / 01
Scope and rules of engagement
We agree assets, test accounts, exclusions, work windows and the urgent channel for critical findings.
- BR / 02
Application mapping
We build a model of roles, data, functions, APIs and trust boundaries before chaining weaknesses.
- BR / 03
Controlled exploitation
Impact is confirmed with the smallest safe proof. We do not retrieve data that is unnecessary for validation.
- BR / 04
Report, workshop and retest
We provide executive and technical layers, review fixes with the team and verify their effectiveness.
04 / EVIDENCE STANDARD
A tenant boundary fails because API authorisation is inconsistent
FINDING MODEL / NO CLIENT DATA
The model demonstrates our reporting standard: confirmed impact first, followed by evidence, conditions and a specific control.
This is a reporting example, not a client engagement or a claim that a specific issue was found.
E-1
An account A request references an account B resource
E-2
The backend validates the session but not resource ownership
E-3
A minimal proof confirms access to one controlled record
E-4
The fix adds object-level authorisation and a regression test
05 / OUTPUT
What your team receives
01
Executive risk summary
Included deliverable
02
Technical findings with evidence and reproduction conditions
Included deliverable
03
Business impact, priority and specific remediation guidance
Included deliverable
04
Coverage and scope limitations map
Included deliverable
05
Technical walkthrough and retest report
Included deliverable
01How long does an application test take?+
Usually from several days to several weeks. Timing depends on roles, endpoints, integrations and access model. We quote after a short scoping call.
02Can testing take place in production?+
Yes when the scope and risk allow it. We use limits, test accounts and agreed rules. Scenarios that could disrupt service move to staging.
03Is the report sufficient for developers?+
The report contains evidence and remediation guidance, but a technical walkthrough is standard. The team can challenge assumptions and agree a safe fix.
BR / NEXT STEP
Have an application or API to assess?
Send a short architecture overview, number of roles and target date. We will return with assumptions, scope and a quote.
NDA · clear scope · direct communication