Illustrative example

What a PentAIx report looks like.

This page shows the structure, evidence standard and tone of a technical report. Every detail is fabricated for demonstration.

Illustrative document

Sample only. The client, domain, endpoints, findings and evidence on this page are invented. Nothing here comes from a real engagement or a real client environment.

Client: Acme Demo (fictional)
Target: app.example.com and API
Engagement type: Web application and API penetration test
Testing window: Five testing days (example)
Report date: Example report (not a live assessment)
Classification: Illustrative sample

Executive summary

The assessment identified one high-severity authorisation flaw, one medium-severity stored cross-site scripting issue and one low-severity information disclosure. The high-severity issue allowed an authenticated user to read invoices belonging to another tenant.

The application’s core authentication was implemented consistently. The most significant weakness was object-level authorisation: the API checked that a user was logged in, but not that the requested invoice belonged to that user’s tenant.

The findings below are prioritised by business impact. Each includes reproduction steps, evidence and a remediation path.

High

Medium

Low

Scope and approach

Web application at app.example.com.
REST API at api.example.com.
Two test accounts: standard user and tenant administrator.
Black-box and authenticated testing.
Out of scope: denial of service, third-party services and modification of production data.

Findings

Ordered by severity and business impact. Each finding includes reproduction detail, evidence and a remediation path.

PT-01HighGET /api/v1/invoices/{id}

Broken object-level authorisation in the invoice API

Description

Any authenticated user can retrieve an invoice belonging to another tenant by changing the numeric invoice identifier. The API verifies that the caller is authenticated and that the invoice exists, but does not verify that the invoice belongs to the caller’s tenant.

Evidence

GET /api/v1/invoices/1042 HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-a-token>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1042,
  "tenant": "tenant-b",
  "customer": "Example Customer B",
  "amount": 18400,
  "status": "paid"
}

Impact

An authenticated user from one tenant can read another tenant’s invoice metadata, including customer name, amount and status. In a multi-tenant product this is a cross-tenant data exposure and may create contractual and regulatory obligations.

Remediation

Enforce object-level authorisation on every invoice read: derive the tenant from the authenticated principal and filter the query by both invoice ID and tenant ID.
Add regression tests that request another tenant’s object with a valid session and expect 403 or 404.
Do not rely on unguessable identifiers as the primary control. UUIDs reduce discoverability but do not replace authorisation.

References

OWASP API Security Top 10 (API1:2023 Broken Object Level Authorization)
CWE-639: Authorization Bypass Through User-Controlled Key

PT-02MediumPOST /api/v1/support/notes → support agent view

Stored cross-site scripting in support notes

Description

Support notes accepted HTML without sanitisation. The payload was stored and executed in the support agent’s browser when the note was opened.

Evidence

POST /api/v1/support/notes HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-a-token>
Content-Type: application/json

{"ticket":"T-2041","note":"<img src=x onerror=alert(document.domain)>"}

HTTP/1.1 201 Created

Impact

An authenticated customer could run script in a support agent’s session, potentially reading ticket data or performing actions as the agent. Exploitation requires a support interaction, which reduces likelihood but not impact.

Remediation

Encode note content on output in the agent view; treat stored text as untrusted.
Sanitise rich text with an allowlist if formatting is required.
Add a Content-Security-Policy that blocks inline script and unexpected origins.

References

OWASP Cross Site Scripting Prevention Cheat Sheet
CWE-79: Improper Neutralization of Input During Web Page Generation

PT-03LowPOST /api/v1/auth/login

Verbose error messages disclose internal implementation details

Description

Malformed JSON returned a stack trace containing framework versions, file paths and internal service names.

Evidence

POST /api/v1/auth/login HTTP/1.1
Content-Type: application/json

{"email":

HTTP/1.1 500 Internal Server Error

SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at /srv/app/dist/auth/login.js:42:18

Impact

The disclosure gives an attacker implementation details that can support targeted exploitation. It does not, on its own, grant access.

Remediation

Return a generic error response for malformed input and log the detailed error server-side with a correlation ID.
Disable framework debug output in production.
Add an error-handling test that asserts internal details are not returned.

References

CWE-209: Generation of Error Message Containing Sensitive Information

Methodology

Testing followed a manual, exploit-led workflow: reconnaissance, application mapping, authentication and authorisation testing, business-logic analysis, injection testing and controlled post-exploitation. Automated tooling supported coverage but did not replace manual verification. Every reported finding was reproduced and documented.

Retest and closure

A retest re-runs the reproduction steps for each finding against the remediated build, confirms the fix and checks for bypasses. Closed findings are listed in a short closure note.

Sample data only

This is an illustrative document. It does not describe a real client, system or assessment. Use it to evaluate report structure and tone, not as security advice for your own environment.

Want this level of detail on your own system?

Bring a target and an objective. I will reply with a scope, a timeline and what the report would cover.

Start a scoping conversation Explore penetration testing