01 / Scope
Agree targets and a safe approach
Targets, identities, time windows and prohibited actions are agreed before authorised testing starts.
Authorised penetration testing
Evidence within agreed boundaries
Testing has clear boundaries and evidence for each finding. Retesting can follow remediation when included in the proposal.
02 / Evidence
Document verifiable results
Each finding connects prerequisites, steps and minimal evidence with impact. Testing is a bounded engagement.
03 / Retest
Retesting can follow remediation
Where included, retesting verifies original conditions and identifies residual risk or new limitations.
Access to other customers' orders through the API
- Affected asset
- Orders API, endpoint /api/orders/{id}
- Impact
- An authenticated user changes an order number to read other customers' data.
- Evidence
- Reproduction steps and shortened request and response without sensitive data.
- Recommendation
- Verify record ownership on the server for every request.
- Verification
- Retest fixes within the proposal's agreed scope.
# logged in as account A
GET /api/orders/1044 HTTP/1.1
Authorization: Bearer ••••••••
HTTP/1.1 200 OK
{ "order": 1044, "owner": "account B" }Manual verification beyond scanner output
A penetration test is an authorised, controlled simulation of an attacker's approach. Tools assist with mapping, but we assess each finding's severity and exploitability manually in the context of your environment.
We can test web applications, APIs and infrastructure. For applications, we focus on authentication, authorisation, session management and business logic. For infrastructure, we first distinguish the external and internal network perspectives.
- Precisely defined targets, roles, environments and exclusions.
- Manual verification of significant findings and potential attack chains.
- Safe demonstration of impact with minimal interference with data and operations.
- Deliverables that support remediation, rather than a score alone.
Methodology provides a framework; scope defines the commitment
We draw on OWASP, PTES and OSSTMM when designing a test. They are methodological frameworks, not certifications or promises of complete coverage.
For web applications, we can agree coverage using OWASP ASVS controls and OWASP WSTG testing procedures. The actual scope, exclusions and limitations are always stated in the brief.
Preparation
Scope, technical prerequisites, authorisation, contacts and Rules of Engagement.
Delivery
Testing within the agreed boundaries, documenting evidence and escalating findings according to the brief.
Handover
A report, explanation of findings, priorities and recommended fixes for the technical team.
Verification
Optional retesting of original findings within the agreed scope and timeframe.
What a useful report contains
- The test scope, dates, assumptions and limitations.
- A summary of impact and priorities for management.
- Affected assets, reproduction steps and evidence without unnecessary sensitive information.
- A justified severity assessment in context, rather than an automated score alone.
- Recommended remediation and, when retesting, the current status of each finding.
What determines scope and price
Factors include the number and complexity of targets, user roles, API operations, IP addresses and business processes. The available test environment, information you provide and required deliverable format also matter.
We therefore determine the price and schedule for your specific scenario. We do not offer a universal package without defining its scope.
