How We Grade a Pentest Report

Certificates do not get you hired; reports you can discuss in an interview do. Here is one finding, first as a typical weak draft, then with the trainer's comments, then rewritten.

This is a synthetic example. We wrote it for this page, against a deliberately vulnerable practice application. It is not a client report and not the work of a real learner.

1. The First Draft

Learner Draft

Finding 3: IDOR. I changed the invoice number and saw other data. Severity: High. Fix: add authorization.

Trainer Comments

  1. Name the asset and the endpoint. "IDOR" is a category, not a finding title.
  2. Show how to reproduce it: the request, which account you used and what came back. A developer should be able to repeat it in five minutes.
  3. Say what is exposed and why it matters to the business: whose data, how much, and whether it could be changed as well as read.
  4. Explain the severity. Give the rating, the reason, and the CVSS v4 vector you scored.
  5. Make the fix specific: where the check belongs and how to test it.

2. The Rewritten Finding

TitleInvoice API returns other customers' invoices (broken object-level authorization)
Affected assetGET /api/v2/invoices/{id} on ShopLab, a deliberately vulnerable practice application
DescriptionThe endpoint accepts any valid session and returns the invoice with the requested ID. It does not check that the invoice belongs to the signed-in customer.
EvidenceSigned in as learner-a, the request GET /api/v2/invoices/10482 with learner-a's session token returned status 200 and the invoice of learner-b: name, address, items and total. IDs 10480 to 10490 all returned data. An ID outside the range returned 404.
ImpactAny signed-in customer can read every other customer's name, address and order history by counting through IDs. In a real system this would be a personal-data breach.
SeverityHigh. The attack is simple, needs only a low-privilege account and exposes the data of every customer. The CVSS v4 vector is recorded in the report; learners score it in class.
RemediationCheck ownership on the server for every invoice request (the invoice's customer must match the session's customer) and return 404 otherwise. Add an automated test that uses two accounts. Do not rely on unguessable IDs as the control.
RetestRepeat the request with learner-a's token for learner-b's invoice IDs. Expected result: 404. The actual result is recorded in the retest section.

3. The Executive Summary That Goes with It

The ShopLab application allows any signed-in customer to read the invoices of other customers. We confirmed this across ten consecutive invoice numbers. The weakness is easy to use and affects the personal data of every customer, so we rate it high and recommend fixing it before the next release. Two lower-severity findings follow in section 4.

How Reports Are Assessed in the Program

Practical lab execution35%
Reports30%
Course practical assessments20%
Technical oral exam10%
Professional conduct and documentation5%

Passing score: 70% overall, and the practical part must be passed. Theory alone never passes. Every report also has a technical oral exam, where you explain and defend each finding, and a retest.

The same structure runs through every report in every course, including the six reports of the Offensive Security Track.

See How We Teach, in a Real Class

Talk to a counselor, choose the right course for your goals, and get the fee, syllabus and next batch dates in writing.

Book Free Trial Classes

By submitting, you agree that Hacking Trainer Academy may contact you about courses by phone, WhatsApp or email. See our privacy notice and refund policy.

WhatsApp