Sample report

Sample VAPT report.

A synthetic example. The client, targets and findings are fictional; the structure and depth are what you receive.

Penetration test reportSynthetic example

Ledgerline Retail Pvt. Ltd. (fictional)

Web application, API and external infrastructure

Test window: 14–16 September 2026, Monday–Wednesday; three business days
Report: 25 September 2026; initial report dated 17 September 2026
Retest: 24 September 2026; separate remediation verification
Testers: ZenoCloud security team
Version: 1.1 — illustrative retest edition

SYNTHETIC EXAMPLE — NOT AN ACTUAL CLIENT ENGAGEMENT. The client, engagement, dates, assets, evidence, findings, remediation decisions and retest results are fictional. No testing was performed against these addresses. ZenoCloud is the publisher; its security team attribution illustrates the report format. All target hostnames use the reserved yourstore.com domain, and all IP addresses use the documentation range 203.0.113.0/24.

1 · Executive summarySynthetic example

This fictional assessment illustrates six weaknesses affecting a mid-size ecommerce business. The most serious allowed unauthenticated control of an application server. Other findings enabled access to another customer's orders, account takeover and checkout price manipulation. The initial risk was high and required immediate action on the exposed administration service. The illustrative retest confirmed four fixes; uploaded-file scripting remained open, and management temporarily accepted legacy TLS support. Counts show initial findings. The three-day assessment sampled attack paths and does not establish that other vulnerabilities are absent.

critical1

high2

medium2

low1

info0

2 · Scope and methodSynthetic example

In scope

Tier: Penetration Test; three business days of manual testing supported by automated discovery.
Web application: https://yourstore.com, including account management, catalogue, checkout and store management.
REST API: https://api.yourstore.com; approximately 40 documented endpoints, with all inventoried routes reviewed and risk-based parameter and workflow sampling.
Six external IPv4 addresses: 203.0.113.10, 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 and 203.0.113.15; TCP service discovery and identified service assessment.
Fictional asset mapping: yourstore.com to 203.0.113.10; api.yourstore.com to 203.0.113.11; administration service at yourstore.com:8443.
Authenticated testing with customer, store manager and admin roles; two customer accounts and separate store assignments for authorisation comparisons.
Unauthenticated access checks, synthetic orders and test payment transactions; bounded exploitation using disposable records.
Separate retest of the six reported findings on 24 September 2026; original severity ratings retained.

Out of scope

Other hostnames, IP addresses, internal networks and cloud management accounts.
Third-party payment processing, fulfilment services and identity-provider infrastructure.
Denial-of-service, load testing, destructive exploitation, persistence and bulk data extraction.
Social engineering, physical access, wireless networks and employee devices.
Source-code review, mobile applications and exhaustive testing of every endpoint, parameter and role combination.
Certification, compliance assessment and assurance that the environment is free of vulnerabilities.

Method

PTES engagement scoping, reconnaissance and threat modelling.
Authenticated testing across customer, store manager and admin roles.
Manual testing guided by OWASP WSTG v4.2.
API checks mapped to OWASP API Security Top 10 (2023).
Controlled exploitation, CVSS v3.1 scoring, remediation guidance and targeted retesting.

3 · Findings · 1 of 6Synthetic example

Finding F-01

Public administration service allows server control

Critical CVSS 9.8 WSTG-CONF-05: Enumerate Infrastructure and Application Admin Interfaces

Target: https://yourstore.com:8443/maintenance/run on 203.0.113.10
Summary: An internet-accessible maintenance service accepted operating-system commands without authentication. A benign identity command executed as root on the application server. No destructive commands or persistence were attempted.
Evidence: Synthetic capture, without cookies or authorisation headers: POST https://yourstore.com:8443/maintenance/run HTTP/1.1; body {"command":"id"} → HTTP/1.1 200 OK; {"stdout":"uid=0(root) gid=0(root)"}. The returned identity established privileged command execution.
Impact: An unauthenticated attacker could read application secrets, alter hosted application data or stop services. These broader consequences follow from root privileges; destructive effects were not exercised.
Fix: Immediately block public access to port 8443. Remove the command runner, enforce administrative authentication and network restrictions, and run maintenance tasks without root privileges. Review logs and rotate accessible secrets.
Retest: Fixed External access was blocked; the command runner was removed and administrative access required authentication through the management network.

3 · Findings · 2 of 6Synthetic example

Finding F-02

Customers can read and change other customers' orders

High CVSS 8.1 API1:2023 Broken Object Level Authorization (BOLA)

Target: https://api.yourstore.com/v1/orders/{orderId}
Summary: The order API checked login status but omitted ownership checks on reads and delivery-address updates. A customer could enumerate sequential order identifiers and access orders belonging to other customers.
Evidence: Synthetic capture using customer A's session: PATCH https://api.yourstore.com/v1/orders/48216 HTTP/1.1; body {"deliveryAddressId":"addr-A2"} → HTTP/1.1 200 OK. Customer B owned the order; a subsequent GET confirmed the changed address and exposed B's contact details.
Impact: A customer could collect order histories and personal details across accounts, then redirect unfulfilled deliveries. Predictable identifiers made repeated exploitation practical.
Fix: Enforce object ownership and store boundaries before every order read or mutation. Verify address ownership separately. Add negative authorisation tests across customer accounts, stores and roles; unpredictable identifiers alone are insufficient.
Retest: Fixed Cross-customer reads and updates returned 403; legitimate ownership checks passed across both customer accounts and store assignments.

3 · Findings · 3 of 6Synthetic example

Finding F-03

Guessable reset codes allow customer account takeover

High CVSS 7.4 API2:2023 Broken Authentication

Target: https://api.yourstore.com/v1/auth/password-reset/confirm
Summary: Customer password resets used four-digit codes valid for 15 minutes, without attempt limits. An attacker could initiate a reset and enumerate codes before expiry. The timing requirement increases attack complexity.
Evidence: Synthetic capture: POST https://api.yourstore.com/v1/auth/password-reset/confirm HTTP/1.1; body {"email":"customer-a@yourstore.com","code":"7314","newPassword":"Synthetic-Only!42"} → HTTP/1.1 204 No Content. A bounded run against the designated account succeeded after 7,315 attempts within seven minutes; subsequent login succeeded.
Impact: An unauthenticated attacker could take over customer accounts, read saved personal information and modify account or order details. No email-account access was required.
Fix: Use cryptographically random, single-use reset tokens with at least 128 bits of entropy. Enforce expiry and per-account attempt limits. Invalidate existing sessions after reset and notify the account holder.
Retest: Fixed High-entropy tokens replaced numeric codes; expiry, single use, attempt limits and session invalidation passed targeted checks.

3 · Findings · 4 of 6Synthetic example

Finding F-04

Checkout trusts customer-supplied prices and discounts

Medium CVSS 6.5 WSTG-BUSL-01: Test Business Logic Data Validation

Target: https://api.yourstore.com/v1/checkout
Summary: Checkout accepted unit prices and coupon discount amounts supplied by the customer. We created a synthetic order below the catalogue price, with the reduced amount carried into the test payment request.
Evidence: Synthetic capture: POST https://api.yourstore.com/v1/checkout HTTP/1.1; body {"sku":"ITEM-104","quantity":1,"unitPrice":100,"couponDiscount":99,"currency":"INR"} → HTTP/1.1 201 Created; {"payable":1}. The catalogue price was INR 2,499; the test payment request also used INR 1.
Impact: A customer could purchase goods for arbitrary reduced amounts, causing revenue loss and corrupting order values. Financial exposure warrants prompt remediation despite the medium technical score.
Fix: Calculate prices, discounts, taxes and totals server-side from trusted records. Accept only product identifiers, quantities and coupon codes. Enforce coupon eligibility and redemption limits atomically; reconcile payment amounts before fulfilment.
Retest: Fixed Tampered prices and discounts were rejected; server-calculated totals matched test payment amounts and coupon eligibility rules.

3 · Findings · 5 of 6Synthetic example

Finding F-05

Uploaded images execute scripts in manager previews

Medium CVSS 5.4 WSTG-BUSL-08: Test Upload of Unexpected File Types

Target: https://yourstore.com/account/returns/attachments and /manager/returns
Summary: Customers could upload SVG files containing scripts as return attachments. A store manager opening the preview executed the script under the shop origin. Testing demonstrated limited record access and note modification.
Evidence: Synthetic capture: GET https://yourstore.com/uploads/return-proof.svg HTTP/1.1 → HTTP/1.1 200 OK; Content-Type: image/svg+xml. In the manager preview, the harmless marker executed; follow-up checks read one assigned return and changed its disposable internal note.
Impact: A customer could induce a manager to run browser code that reads assigned return information or changes notes using the manager's session. Opening the attachment was required.
Fix: Reject SVG and HTML attachments. Decode and re-encode permitted raster images. Serve uploads from a separate, cookieless origin with restrictive content policies, correct MIME types and nosniff; force downloads where previews are unnecessary.
Retest: Open New uploads were restricted, but an existing SVG still executed in manager previews; stored attachments require remediation.

3 · Findings · 6 of 6Synthetic example

Finding F-06

Legacy TLS remains enabled on the storefront

Low CVSS 3.7 WSTG-CRYP-01: Testing for Weak Transport Layer Security

Target: https://yourstore.com:443 on 203.0.113.10
Summary: The storefront accepted TLS 1.0 with a CBC cipher suite. Legacy-client traffic could face conditional cryptographic attacks. Successful protocol negotiation was confirmed; plaintext recovery was not demonstrated.
Evidence: Synthetic capture: GET https://yourstore.com/ HTTP/1.1 → HTTP/1.1 200 OK over TLSv1.0 using TLS_RSA_WITH_AES_128_CBC_SHA. The same listener also accepted TLS 1.2 and TLS 1.3.
Impact: Under specific legacy-client and network conditions, an attacker could recover limited encrypted information. Supporting TLS 1.0 alone does not demonstrate exposure of modern-client sessions.
Fix: Disable TLS 1.0 and TLS 1.1 on the public listener. Require TLS 1.2 or TLS 1.3 with modern cipher suites, and verify protocol negotiation after updating the load balancer.
Retest: Accepted Still reproducible; fictional management accepted the risk until 9 October 2026 for legacy-client migration, with infrastructure ownership assigned.

4 · Retest and attestationSynthetic example

Retest summary

Illustrative retesting confirmed F-01 through F-04 fixed. F-05 remains open; F-06 remains present under temporary risk acceptance. Original counts and scores are unchanged. Retesting covered reported weaknesses and related checks, not a complete reassessment.

Letter of Attestation

SYNTHETIC LETTER OF ATTESTATION. In this fictional engagement, ZenoCloud security team performed penetration testing for Ledgerline Retail Pvt. Ltd. on 14–16 September 2026, covering yourstore.com, approximately 40 REST API endpoints at api.yourstore.com and six external addresses, 203.0.113.10–203.0.113.15. Retesting occurred on 24 September 2026. This sample records an illustrative assessment only; no actual testing occurred. It provides no certification, compliance assurance or guarantee of security.

Get your pentest scoped.

Tell us what needs testing, your deadline and who needs the report.

+91 99991 08033 · sales@zenocloud.io