# Sample report: what a DXCL report looks like

Canonical page: https://dxcl.tech/trust/sample-report/

A sample DXCL penetration test report for a fictional company. All names, hosts and data are invented. The matching sample certificate is DCL-DEM0-2026-0001 (verify at https://dxcl.tech/trust/?id=DCL-DEM0-2026-0001).

## Cover
- Client: Sample Company Pvt Ltd (fictional)
- Report ID: DXCL-RPT-2026-SAMPLE, version 1.0, classification: sample, public
- Testing window: 14 to 25 September 2026. Report date: 28 September 2026.
- Prepared by: DrishtiX Cyber Labs testing team

## 1. Managerial summary
Overall risk: moderate. One access control flaw let any logged-in customer read other customers' invoices. Two high-severity issues were fixed within a week, and both fixes held at the fix check on 3 October 2026.

Findings by severity: Critical 0, High 2, Medium 3, Low 2, Informational 3.

Fix first:
1. Check ownership on every object the API returns (H-01).
2. Limit login attempts and add a second factor for admin users (H-02).
3. Stop returning stack traces from the API in production (M-02).

## 2. Scope and method
- In scope: web app at app.example.com and REST API at api.example.com, two customer roles and the admin role.
- Out of scope: third-party payment provider, denial-of-service testing, social engineering.
- Environment: staging with production-like data.
- Approach: automated attacks with best-of-market tools, then manual testing of every page and endpoint in scope.
- Standards: OWASP Web Security Testing Guide, OWASP ASVS, OWASP API Security Top 10.

## 3. Findings
| ID | Finding | Severity | CVSS 3.1 | After fix check |
|---|---|---|---|---|
| H-01 | Broken object level authorisation on the invoices API | High | 6.5 | Fixed and verified |
| H-02 | No limit on login attempts for admin accounts | High | 7.5 | Fixed and verified |
| M-01 | Session tokens stay valid after password change | Medium | 5.4 | Open, scheduled |
| M-02 | Stack traces returned by the API in production mode | Medium | 5.3 | Fixed and verified |
| M-03 | File upload accepts SVG files with scripts | Medium | 5.4 | Open, scheduled |
| L-01 | Software versions shown in response headers | Low | 3.7 | Accepted risk |
| L-02 | Password reset links valid for 72 hours | Low | 3.1 | Open, scheduled |
| I-01 | Content Security Policy could be stricter | Informational | None | Open |
| I-02 | Cookies missing the SameSite attribute | Informational | None | Fixed and verified |
| I-03 | Unused API version still reachable | Informational | None | Open |

## Finding H-01: Broken object level authorisation on the invoices API
- Severity: High. CVSS 3.1 base score 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), raised to High because the data covers every customer, the IDs are guessable and exploitation needs only a free account.
- Endpoint: GET https://api.example.com/v1/invoices/{id}
- References: OWASP API Security Top 10, API1 Broken Object Level Authorization; CWE-639.
- Evidence: logged in as customer A, a request for an invoice belonging to customer B returned 200 OK with that invoice.
- Impact: any logged-in customer could read every other customer's invoices, including names, addresses and GST numbers; a reportable breach under India's DPDP Act.
- Fix: check ownership on the server for every object lookup; take the account ID from the session, never from the request; add an automated test expecting a 404 for another account's invoice.
- Fix check: fixed and verified on 3 October 2026.

## After the report
Both reports arrive by email and the certificate is issued on the day of the report. The testers walk your developers through every finding, answer questions while they fix, then re-test the fixes and record the fix check on the certificate.