Writing samples
Client work is confidential. These are sanitized samples that show how I report.
Sample
Two-day unauthenticated external assessment of a Next.js SaaS. The report walks from an executive summary through ten findings — including one confirmed-exploited framework denial-of-service issue and an unmitigated login brute-force exposure — to a prioritized remediation roadmap, a verified-clean matrix, and an open write-up of a data-reconciliation conflict between testing passes.
PDF version · All names, domains, identifiers and figures in the sample are fictional or generalized. Nothing in it maps to any real client, product or finding. Reproduction steps are conceptual — no ready-to-run payloads.
Case study
An authorized red-team analysis of a managed-backend web platform whose default authorization posture turned a public client key into full read/write control of unstructured storage: no row-level authorization on two buckets, a reflected cross-origin policy, and identity handling that exposed the escalation path end to end. The work chained nine findings from a single root cause into data exposure, content replacement and an account-takeover route, mapped to their CWE classes, with owner-verified impact reproduction and a prioritized fix path. The target is deliberately not identified here, and the full write-up — findings, access matrix and remediation state — is shared only under NDA.
Unlike the sample above, this entry summarizes real work — so it carries no identifiers, no exploit detail and no vulnerability status. Request it with the NDA button below.
Reporting approach
An executive summary a non-technical stakeholder can act on, then technical findings written for the engineers who will fix them — root cause first, measured impact second.
CVSS v3.1 base scores where a published one exists; qualitative exploitability and business-impact ratings for custom findings, with the rating methodology published inside the report itself.
Every confirmed finding includes enough reproduction context for the client to re-verify — reconstructed conceptually, never as ready-to-run exploit code or payload one-liners.
A single priority-ordered table maps every action to the finding IDs it resolves, including the re-test loop and the scope-gap follow-ups. Fix order is part of the deliverable.
Unverified or conflicting observations are reported as such and tracked separately instead of being silently merged, dropped, or rounded into a confident narrative.
A verified-clean matrix lists every control that was checked with no exploitable result — so reviewers can tell a real "secure" from an untested blank.