How we test: our penetration testing methodology

1. Authorization and scope#

We test only systems whose owner has authorized the test in writing. The scope names the hosts, user roles, test windows, actions that are off limits and the people to contact. If something outside the scope looks relevant, we stop and ask.

2. How we test#

We choose from five methods for each application:

• Direct HTTP requests against the web application and API, with each user role.
• Browser-observed tests in Chromium. We prove cross-site request forgery and stored cross-site scripting in a real browser, in addition to reading the raw response.
• Client-side review of the JavaScript bundles your application ships.
• Differential comparison of anonymous, low-privilege and high-privilege callers on the same request.
• Read-back from a second account, to prove that a change or exposure crosses an account or tenant boundary.

We use Incursion, the Excession Labs testing agent, to run these tasks in parallel under tool rules set for your scope. Excession Labs checks the evidence for each finding and writes the report. For more on the agent, read how AI-assisted testing works.

We draw test ideas from public references such as the OWASP Web Security Testing Guide, the OWASP API Security Top 10 and OWASP ASVS. They guide coverage and are not certifications.

3. The evidence standard#

A finding goes in the report as confirmed only when we can show its effect:

• A write is proven by reading the changed record back through another session. A response that says "success" is not proof.
• An exposure is proven by showing the exposed data from a test-owned record.
• A browser attack is proven by the attack working in a real browser.

4. Controls next to every attack#

Each attack request has controls: a nonexistent identifier, the wrong record type, an unsigned or wrongly signed token, another account's token, and an anonymous caller. Controls show whether the first result means what it seems to mean. When a control shows that it does not, we downgrade or drop the finding.

We also report controls that held: protections we tried to break and could not. Your engineers can then avoid weakening them while they fix other issues.

5. Safety limits#

• Destructive proofs use only test-owned accounts and records, marked as test data.
• Tests of uploads, password guessing, email sending and paid third-party services are bounded. The report states what each cost.
• Reproduction scripts are read-only where possible, and must only be run with authorization and test-owned identifiers.

6. Evidence labels#

Open questions go into a "Limitations and open questions" section, not into the confirmed impact.

7. Severity#

We rate each finding on a four-level scale with a written definition for each level. The definitions appear in every report, so a reader can see why a finding is High and not Medium.

We do not add CVSS scores by default. If your program needs CVSS vectors, tell us during scoping.

8. The report#

Each report holds project details and scope, the method, safety constraints, evidence labels, an executive summary with priority actions, findings at a glance, the reproduction environment, a section per finding (description, impact, verified results, reproduction, remediation), controls that held, a remediation plan, limitations and open questions, an evidence index, and reproduction scripts. We deliver it in HTML, PDF and Markdown. See the sample report.

Requests and responses are saved with timestamps. Key evidence can carry a SHA-256 manifest so you can check that it has not changed.