Proof
What an engagement produces, what the findings are measured against, and the parts you can check before paying for anything. No logos, no invented statistics — the artifacts are the proof.
Sample report excerpt — synthetic target, illustrative data
DGX-EX-014 — Order API exposes other customers' orders
- Severity
- Medium — CVSS 3.1 6.5
- Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N- Component
GET /api/v1/orders/{id}— Order API- Target
example-store.test— synthetic test tenant- Status
- Fixed — retest passed 2026-09-18
Summary
An authenticated customer can read any other customer's order by changing the order identifier. The API authorizes the caller as a signed-in user but never checks that the order belongs to them.
Reproduction
- Sign in as test account A, then as test account B. Note the order ID each account shows.
- While signed in as A, request B's order ID using A's token.
- The API answers 200 with B's order: shipping address, items, and card metadata.
GET /api/v1/orders/8842 HTTP/1.1
Host: example-store.test
Authorization: Bearer <token-of-user-a>
HTTP/1.1 200 OK
{"id":8842,"owner":"user-b","shipping":{"name":"...","address":"..."},"payment":{"last4":"..."}}
Identifiers and values are synthetic; no customer data appears in this sample.
Impact
Order IDs are sequential, so the exposure is the whole order table — names, addresses, and payment metadata — not a single record. Scored for confidentiality only: no write path was reachable from this endpoint.
Remediation
Bind the lookup to the authenticated principal (WHERE id = ? AND user_id = ?) and return 404 on mismatch so identifiers cannot be probed — enforced in one shared authorization helper rather than patched per endpoint.
Retest
Re-run with the same test accounts after the fix: A requesting B's order returns 404, A's own order returns 200. Finding closed.
Client names, hosts, and tokens are replaced in every excerpt. The engagement report adds full request/response evidence, your scope table, and the affected-versions matrix.
What every report contains
- Scope, method, and exclusions stated before the findings
- One entry per finding: CVSS 3.1 vector and score, affected component, reproduction, impact, remediation
- Redacted proof — requests, responses, and screenshots with customer data masked
- A fix order ranked by what an attacker reaches, not by scanner severity alone
- Retest status per finding, with the request that proves the fix
- An engagement log: dates, test accounts, environment, and anything that changed mid-test
Standards the work is mapped to
- Web & API
- OWASP Top 10 (2021), OWASP API Security Top 10 (2023), WSTG
- Mobile
- OWASP MASVS & MASTG
- LLM & agents
- OWASP LLM Top 10 (2025), MITRE ATLAS
- Red team
- MITRE ATT&CK, PTES
- Scoring
- CVSS v3.1, re-scored with your environment on request
Every report states which items were tested, which were skipped, and why — coverage you can audit, not a checklist with ticks next to nothing.
How findings are graded
- CVSS 3.1 as the baseline; environmental context applied on request, because a score in a vacuum is a claim, not a measurement.
- No informational padding. A report with 400 low-severity rows hides the three that matter.
- Business-logic findings are ranked by what an attacker reaches and what it costs you, even where CVSS underrates them.
- False positives are labeled and removed, not buried. The report is a document your team acts on, not a win counter.
Handling terms
- Written authorization and rules of engagement before the first request.
- NDA on request, before scoping details change hands.
- Data minimization: stop at proof of exposure — no copying of records, no movement outside scope.
- Nothing published without written approval. Coordinated disclosure; your name stays out of it unless you opt in.
- Reports delivered over the channel you name, shared with nobody else, deleted on request when the engagement closes.
- Retest of fixed findings within 30 days, at no extra cost.
What this page does not show
- No client names or logos — naming a client without written approval is the behaviour you should run from, not hire.
- No testimonial quotes or "trusted by" wall. When clients agree to be named, their words and the engagement date go here.
- No fabricated CVEs, bounty totals, or ratings. Absent data stays absent until there is something real to show.
Check before you pay
Two things are available before any money changes hands: the full sample report in the format you would receive, and a scoping call with the person who does the testing. If the sample is not specific enough for your team to act on, do not hire me.