How We Test: Our Penetration Testing Methodology

Manual-first, because scanners only see half the picture

A scanner is excellent at breadth: it fingerprints software, flags missing headers, and matches known CVE signatures across thousands of requests. It is poor at judgment. It cannot tell that a `200 OK` returning another tenant's invoice is a critical broken-access-control flaw, because syntactically nothing looks wrong. Business-logic abuse, authorization boundaries, chained low-severity issues, and race conditions all live in exactly the blind spot automation cannot reason about.

We use automation deliberately — Burp Suite Professional, nuclei, and targeted scripts — as a force multiplier for coverage and regression, never as the test itself. A human tester forms hypotheses, manipulates state, and confirms real impact. That is the difference between "the tool reported it" and "we proved it."

• Scanners find known patterns; humans find the logic that was never a pattern.
• Authorization, tenancy, and workflow abuse are effectively invisible to signature-based tools.
• Automation gives us coverage and speed; manual testing gives us proof and context.

Phase 1 — Pre-engagement: scoping, authorization, rules of engagement

No packet is sent before a signed authorization is in place. In pre-engagement we agree the exact scope (in-scope hosts, domains, apps, APIs, and explicit exclusions), the testing window, the account tiers we test with, and the escalation contacts. We capture the Rules of Engagement in writing: what is permitted, what is off-limits (for example no denial-of-service, no destructive payloads against production data), source IPs for allow-listing, and a break-glass channel if we suspect a live compromise or a genuinely fragile system.

We define the objective in the customer's language — protect customer PII, prevent account takeover, satisfy an ISO 27001 or SOC 2 control — so testing effort is spent where the business risk actually is, not spread evenly over noise.

• Signed authorization and written scope before any traffic is generated.
• Rules of Engagement: permitted techniques, exclusions, testing hours, notification path.
• Named emergency contacts and a stop-work trigger for high-risk conditions.

Phase 2 — Reconnaissance & mapping

We build a complete picture of the attack surface before probing it. Passive recon (DNS, certificate transparency logs, public code and metadata) is followed by active mapping: enumerating hosts, ports and services, spidering the application, and cataloguing every endpoint, parameter, authentication flow, and role. This aligns with OWASP WSTG Information Gathering (WSTG-INFO) and Configuration Management (WSTG-CONF).

The deliverable of this phase is an internal map: which components trust which, where data crosses a boundary, and which endpoints handle sensitive objects. A test you never thought to run is a vulnerability you will never find, so coverage of the surface is treated as a first-class quality metric.

Phase 3 — Threat modeling

With the map in hand we reason like an attacker with goals. We identify the assets that matter, the trust boundaries around them, and the realistic threat actors — an unauthenticated internet user, a low-privilege customer, a malicious insider. We enumerate abuse cases per component (STRIDE-style: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) and rank them by likelihood and business impact.

This produces a prioritized test plan. Rather than testing everything shallowly, we spend the deepest manual effort on the paths where a successful attack does the most damage — payment flows, authentication, multi-tenant data access, and administrative functions.

Phase 4 — Manual testing & safe exploitation

This is the core. We execute the plan against the OWASP WSTG test cases and OWASP Top 10 categories, verifying each candidate issue by hand. Authentication and session management (WSTG-ATHN, WSTG-SESS), authorization and IDOR/BOLA (WSTG-ATHZ), input handling — injection, SQLi, XSS — (WSTG-INPV), business logic (WSTG-BUSL), and cryptography (WSTG-CRYP) are all covered systematically, and mapped against ASVS controls where a maturity view is useful.

Exploitation is always safe and proportionate. We prove a vulnerability with the minimum action needed to demonstrate it: reading one record we should not be able to read, obtaining a benign proof token, showing a controlled `alert(document.domain)` for XSS. We never exfiltrate real customer data, never run destructive payloads, and never degrade availability. Every step is logged with timestamped requests and responses so the finding is fully reproducible.

• Systematic coverage of OWASP WSTG categories and OWASP Top 10.
• Proof of impact with the least intrusive action — no data theft, no destruction.
• Full request/response evidence captured for byte-for-byte reproduction.

Phase 5 — Post-exploitation: measuring real impact

Finding a foothold is not the finding — the finding is what that foothold means. In a controlled way and strictly within the Rules of Engagement, we assess how far a proven vulnerability actually reaches: what data becomes readable, whether privileges can be escalated, whether one weakness chains into another to reach a crown-jewel asset. A reflected XSS is one thing; a reflected XSS that steals an admin session and pivots to full tenant control is a different business conversation.

We quantify blast radius without ever realizing it destructively. The output is an impact statement in plain business terms — 'an unauthenticated attacker could enumerate and read every customer's invoices' — that a non-technical decision maker can weigh.

Phase 6 — Risk rating with CVSS v3.1

Every finding gets a CVSS v3.1 base score and the full vector string, so the rating is transparent and independently verifiable rather than a subjective label. We assess Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the Confidentiality/Integrity/Availability impacts, and where relevant we add Temporal and Environmental metrics to reflect the client's real context.

CVSS is the baseline, not the whole story. We reconcile the numeric severity with genuine business impact and exploitability, so a technically 'medium' issue that enables account takeover is escalated in the narrative and prioritized accordingly. The report ranks issues so remediation effort follows real risk.

Illustrative example finding — IDOR in the invoice API

The following is an illustrative example to show how we document a finding. It is not a real client and describes no real system.

Title: Insecure Direct Object Reference (IDOR) exposing cross-tenant invoices. Severity: High — CVSS v3.1 8.1 (vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Category: OWASP Top 10 A01:2021 Broken Access Control; WSTG-ATHZ-04 (Insecure Direct Object References).

What we found: the endpoint `GET /api/v2/invoices/{id}` returned invoice objects by sequential integer ID and authorized the request only by valid session, never checking that the invoice belonged to the caller's tenant. Authenticated as a low-privilege user in Tenant A, we changed `{id}` from our own `50432` to `50431` and received another organization's invoice — customer name, billing address, line items, and amount. Incrementing the ID walked the entire table.

Business impact: any authenticated customer could enumerate and read every invoice across all tenants — a mass confidentiality breach of personal and commercial data, with clear GDPR exposure and contractual/reputational fallout.

The fix: enforce object-level authorization on the server for every request — verify the requested invoice's `tenant_id` matches the authenticated principal's tenant before returning it, and return `404` (not `403`) to avoid confirming existence. Replace sequential integer IDs with unguessable UUIDs as defense-in-depth, and add an automated access-control test to the CI pipeline so the regression cannot return silently.

• Severity: High — CVSS v3.1 8.1, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
• Root cause: authentication present, object-level authorization absent.
• Fix: server-side tenant ownership check + UUIDs + CI access-control regression test.

Phase 7 — Reporting, retest, and quality assurance

The report is the product. It opens with an executive summary a board can read, followed by technical findings each carrying a CVSS score and vector, reproduction steps, timestamped evidence, business impact, and specific remediation guidance — not 'patch it' but the concrete control to add. Findings are ranked so the first fix removes the most risk.

Quality is enforced before delivery: every finding is peer-reviewed by a second tester who independently reproduces it, which is how we keep false positives near zero — we don't report what we can't prove. After you remediate, we run a free re-test to confirm each fix actually closes the issue and introduces no regression, and we reissue the report with updated status. Throughout, the engagement is covered by an NDA; evidence and customer data are encrypted at rest, access-controlled, retained only as agreed, and securely destroyed on schedule.

• Peer review with independent reproduction — near-zero false-positive rate.
• Actionable, ranked remediation guidance, not generic advice.
• Free re-test after fixes; NDA, encryption, and scheduled data destruction throughout.

FAQ