Skip to content
bughunter.pro
Passer en français : EN FR Request an audit

What does a pentest report look like? A complete example.

Nobody should buy an audit without knowing what the deliverable looks like. This page follows the exact structure of the PDF we hand over at the end of an engagement: same sections, same level of detail. Only the content changes, since here it is rebuilt and anonymized.

Request a quoteSee one finding in full

At a glance

  • FormatA PDF, delivered in English or French, encrypted if you wish.
  • Two readersA summary your leadership can read without a technical background, and technical detail your developers can act on.
  • Per vulnerabilityThe real impact, step-by-step replayable proof, and the expected fix.
  • After the fixThe retest updates the status of every vulnerability, within 60 days.

One report, two readers.

Leadership wants to know what is at risk and where to start. The tech team wants the request to replay and the line to fix. Write a report for only one of them and the fixes stall.

That is why the executive summary is written without jargon, with a glossary when a term cannot be avoided, and the technical detail comes after, in full, with the raw requests. Both are in the same document.

Severity, for its part, is not a score out of a tool. Every vulnerability carries a vectored score, but the priority accounts for what the flaw allows in your context. A critical on an isolated pre-production environment is not handled like a high on the service that carries your payments.

One document. The summary is for leadership, the technical detail is for developers.

The eight sections, in order.

The table of contents is always the same, whatever the engagement. You know where to look before you open the document.

  1. 01

    Engagement framework

    The exact target, the written authorization covering the test, the dates, the length, the method and the tooling used. It also states what was touched: test accounts created then deleted, reversible changes, third-party data masked. Nothing is left behind.

  2. 02

    Executive summary

    What is well protected, what is a problem, the main risks and the recommended order of action. Written to be read by leadership without a technical background, with a glossary for the terms that cannot be translated.

  3. 03

    Findings summary

    The overview table: a number, a severity, the affected component, the vulnerability, the impact and the status. One page to see everything, and the way into the detail.

  4. 04

    Vulnerability details

    For every flaw: severity and vectored CVSS, a precise description of the defect, reproduction proof with the raw requests, demonstrated impact, prerequisites, numbered remediation and status.

  5. 05

    What holds

    What stands up. Many reports list only problems, which gives a false picture of a system that is sometimes sound overall. Knowing what is already solid avoids questioning what does not need it.

  6. 06

    Non-blocking recommendations

    Hardening that does not make the vulnerability list but reduces the surface: headers, configuration, logging, rate limiting. Kept apart so they do not drown the priorities.

  7. 07

    Retest

    The result of replaying the tests after your fixes, for every flaw, with the date and what was observed. It is the section that turns a list of problems into a closed file, and it is added in version 1.1 of the report.

  8. 08

    Appendices

    The full requests and the evidence, gathered separately so the body of the report stays readable. Screenshots and sensitive access are kept apart and sent over an encrypted channel, never pasted into the document.

The findings summary.

A rebuilt extract. Each line points to the flaw's full detail in the next section of the report.

bughunter.pro3. Findings summary, v1.1
Sample findings summary table
No.SeverityComponentVulnerabilityImpactStatus
4.1Criticalapi.example.com/v1/orders/{id}Missing object-level access control (BOLA) on reading ordersAny customer's order can be read from its identifier aloneFixed
4.2Highapi.example.com/v1/accountrole field accepted on write (mass assignment)A standard account promotes itself to administrator in one requestFixed
4.3Highwww.example.com, password resetReset token that never expiresAn intercepted link still works weeks laterFixed
4.4Mediumwww.example.com, loginNo limit on login attemptsCredentials from public breaches can be replayed at scaleFixed

One vulnerability, in full.

Here is the full detail for line 4.1 of the table above. It is the level of detail your technical team gets, for every flaw.

bughunter.pro4. Vulnerability details

4.1Reading any customer's orders without authorization

Critical
Severity

Critical, : 6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Component

GET /v1/orders/{id} on api.example.com

Description

The API checks that the caller is authenticated, but not that the requested order belongs to them. The identifier is a sequential integer passed in the URL. An authenticated customer who replaces their own identifier with someone else's receives the full order: name, shipping address, phone, order lines and amount. The server answers 200 in both cases.

Proof of reproduction
GET /v1/orders/4172 HTTP/1.1Host: api.example.comAuthorization: Bearer <test account token> HTTP/1.1 200 OK{"id":4172,"customer":"test account","total":"149.90", ...} GET /v1/orders/4173 HTTP/1.1Host: api.example.comAuthorization: Bearer <the same token> HTTP/1.1 200 OK{"id":4173,"customer":"another customer","total":"318.00", ...}
Impact

Impact demonstrated on reads. With sequential identifiers, enumeration is trivial and can be automated: the entire order history can be retrieved with a single legitimate customer account. The data concerned is personal data under the GDPR (article 4). A confirmed exploitation would be a breach to notify to the supervisory authority within 72 hours (article 33). No write was attempted.

Prerequisites

A standard customer account, created freely from the site. No prior privilege escalation, no victim interaction.

Remediation
  1. On the server, on this route and on every route that takes an object identifier, check that the requested object belongs to the user of the session.
  2. Handle access control in a shared layer rather than in each route, so the omission can no longer happen.
  3. Replace sequential identifiers with unguessable ones (). A defense-in-depth measure, not a fix on its own.
  4. Review the access logs for past enumeration on this route.
Status

Fixed by the client, then verified at the retest. The retest is part of the engagement: no vulnerability is marked "fixed" until it has been checked.

Fixed and retested

What the report leaves out.

As much as what it contains, what is deliberately left out is part of the commitment.

  • No real customer data

    Evidence is truncated and masked, and extracted data sets are never copied into the document.

  • No live credentials

    Anything that must be passed on goes over an encrypted channel, separately from the report. And if real credentials of your accounts have leaked and we come across them during the engagement, we warn you right away so you can change them.

  • No padding

    No raw tool output pasted in, no unverified theoretical vulnerability to inflate the count.

  • No disclosure

    The report is yours. We share it with nobody and never name a client.

Read further.

The report is what the method produces, and what you buy with the research time.

Our methodology

The six phases that produce this report, and the rules that frame the engagement.

See the page

What a pentest costs

What a report like this costs: our pricing, and what is always included.

See the page

All services

The five services that end with this report.

See the page

Pentest or vulnerability scan

Why a scan report looks nothing like this one.

See the page

A report like this one, for your company.

Describe the scope and we will come back with a scoping proposal and a quote. The first call commits you to nothing.

Request a quoteSee pricing