Web Application and API Penetration Test Report

About This Document

This is a redacted sample from a real engagement, published in full. The client, Acme SaaS Pvt. Ltd., is fictional. The company, domains, addresses, identifiers and findings are illustrative and do not describe any real client or assessment.

The engagement covered a web application and its API backend. They were tested as two separate scopes, because the effort, the test cases and the threat surface differ between them, and they are reported in one document because they share authentication, session handling and the same authorisation model.

Section 4 of the source report carries complete write-ups for four of the 12 findings: a representative finding in each priority band and across the severity range. All 12 findings appear below. The eight the source redacts carry every field it publishes for them and no more.

Email me the PDF if you want the typeset original.

Document Control

Table of Contents

1. Executive Summary Overall risk, key statistics, business impact
2. Scope and Methodology In-scope assets, standards, tools, risk ratings
3. Findings Summary All 12 findings, priorities, root cause themes
4. Detailed Findings 4 of 12 written up in full in this sample
5. Test Cases TC-01 to TC-12, target, DPP section, result
6. Compliance Evidence Package Positive controls, DPP, SOC 2, ISO 27001:2022
7. Programme Appendix Finding to DPP control mapping
8. Appendix Testing team, distribution, glossary
9. Disclaimer Limitations of testing, scope of findings

Executive Summary

Cybersecify performed a grey-box authenticated web application penetration test of Acme SaaS's multi-app commerce platform, covering the OMS, WMS and CarrierHub applications served under a shared single sign-on. The engagement supports Acme's Amazon SP-API Data Protection Policy (DPP) submission for restricted buyer PII. Testing ran across the staging environment using two organisations (Org A, Org B) and three roles (Owner, Admin, Member).

The assessment identified 12 findings. The dominant theme is a set of application-layer weaknesses that expose or endanger Amazon-derived buyer PII: an SQL injection in the order-search API that reads buyer data across organisations, a stored cross-site scripting flaw in the admin console, a server-side request forgery reaching internal services, and a buyer-PII read replica that is not encrypted at rest. These four Critical findings are the highest-priority items for the DPP submission because they directly contradict the secure-coding, network-protection, data-attribution and encryption attestations a provider makes to Amazon.

Key Statistics

Business Impact Summary

The Critical findings each provide a direct or reliable path to Amazon-derived buyer PII or to the platform holding it. The order-search SQL injection alone lets one authenticated account read the order and customer datasets across every organisation; the stored XSS, the SSRF and the unencrypted PII replica each independently endanger that same data or the systems around it. The Medium and Low findings, spanning MFA enforcement, transport encryption, data retention and deletion, logging, and dependency hygiene, weaken specific controls Amazon requires but do not on their own block the submission. Every P1 finding below must be remediated and retested before the Letter of Attestation is issued.

Scope and Methodology

This was a grey-box authenticated web application penetration test. Testing was performed on the staging environment only, using synthetic data across two organisations and three roles. No production data was accessed.

In-Scope Assets

Out of Scope

Denial of service and volumetric testing; rate-limiting and throttling testing; social engineering; physical security; sustained load or availability testing beyond single non-destructive proof-of-concept requests. State-changing testing was performed only where explicitly authorised.

Methodology and Standards

Tools

Testing Approach

Grey-box authenticated testing using two organisations (Org A, Org B) across three roles (Owner, Admin, Member). All actions were performed on staging only, with synthetic data. No production data was accessed. Injection, XSS and SSRF findings were confirmed with an intercepting proxy; transport, configuration, authentication and data-lifecycle findings were confirmed via targeted probes and authenticated in-browser instrumentation, staying non-destructive except where state-changing testing was explicitly authorised.

Risk Rating Definitions

Severity is assigned from the CVSS v3.1 base score. Ratings describe the risk the condition presents in this environment, not a generic product rating.

Deliverables and Retest

This v1.0 report is the report of record for its scope. A full retest of every finding is carried out within 30 calendar days of delivery. The v2.0 retest report, showing each finding as closed, partially closed, or accepted as a documented risk, is issued within 3 business days of the retest completing. A Letter of Attestation, signed by the OSCP-certified lead tester, follows the retest and confirms that an independent manual penetration test was performed to Amazon's requirements. The Letter is supporting evidence for the SP-API Data Protection Policy submission and is not a certification.

Amazon Required Report Elements

This report is structured to cover the elements Amazon expects of a penetration test report submitted in support of SP-API DPP approval: an executive summary with an overall risk rating and severity breakdown (Section 1); testing methodology and scope coverage (Section 2); findings classified by severity using CVSS v3.1 and v4.0 (Sections 3 and 4); tool output and manual verification evidence (Section 4); remediation guidance with status tracking (Section 4); and compliance mapping to the applicable control domains (Section 6). Amazon reviews and decides on the submission; this report is independent, third-party evidence and not an approval.

DPP and AUP section numbers used throughout reference the published Amazon SP-API Data Protection Policy and Acceptable Use Policy, and should be confirmed against the current published versions before submission.

Findings Summary

The assessment produced 12 findings: 4 Critical, 6 Medium and 2 Low. The four Critical findings are application-layer and data-protection weaknesses grouped as P1 (blocks the submission); the remainder are P2 (DPP-relevant, not submission-blocking) and P3 (lower-priority hardening).

Findings Identified by Severity

Severity Distribution

All Findings

This is a redacted sample. The table above lists the full finding set by title; Section 4 gives complete write-ups for a representative finding in each priority band (P1, P2, P3) and across the severity range, so the reader can see the exact format, evidence, and Amazon DPP mapping without reproducing every finding. A real engagement report details every finding in full.

Priority Definitions

Findings are grouped by remediation priority for the Amazon SP-API Data Protection Policy submission. P1 findings block the submission and must be remediated and retested before the Letter of Attestation is issued. P2 findings are DPP-relevant but not submission-blocking; they strengthen the attestation and should be remediated on the stated timeline. P3 findings are lower-priority hardening items that improve the overall security posture and are addressed in the normal hardening cycle.

Root Cause Themes

The Critical findings do not share a single root cause, but three themes recur. First, input is trusted at the boundary: the order-search filter concatenates request parameters into SQL, and the admin console renders seller-supplied HTML without encoding, so injection and stored XSS are both possible. Second, server-side requests and internal data stores are under-guarded: the webhook field fetches attacker-chosen URLs, and a reporting read replica holding buyer PII was provisioned without encryption at rest. Third, several Medium and Low findings show controls that were applied to the primary surface but not carried to every host or lifecycle stage, deprecated TLS on the billing edge, MFA left optional for privileged roles, and no retention, deletion or audit-logging path for buyer PII. The systemic fixes are parameterised queries and consistent output encoding, server-side allowlisting of outbound URLs, encryption at rest on every store touching PII, and a control-parity review so transport, authentication and data-lifecycle policies apply uniformly across all in-scope hosts.

Detailed Findings

All 12 findings appear below. Four carry the complete write-up the source report publishes: one per priority band, across the severity range. The other eight carry every field the source publishes for them, which is the severity, both CVSS scores, the test case, the target and the Amazon DPP mapping.

P1: Findings That Block the Amazon SP-API Submission

GET /v1/orders/search?
status=open&sort=created_at%29%20UNION%20SELECT%20email,phone%20FROM%20customers--
→ HTTP 200   buyer email and phone rows returned across organisations

P2: DPP-Relevant Findings (Not Submission-Blocking)

$ testssl billing.staging.acmesaas.io
 TLS 1.0   offered (deprecated)
 TLS 1.1   offered (deprecated)
 cipher    TLS_RSA_WITH_AES_128_CBC_SHA   (no forward secrecy)

GET /app/orders?before=<retention_cutoff>
→ HTTP 200   orders with buyer name, address and phone still returned

P3: Lower-Priority Hardening Findings

action: GET /app/customers/<id>    →  no audit-log entry written
action: POST /app/customers/export →  no audit-log entry written

Test Cases

Each test case maps to the assessment scope, the control evaluated, and the finding that resulted. Every case below returned a FAIL and corresponds to a confirmed finding; controls confirmed working are recorded in the Compliance Evidence Package.

Compliance Evidence Package

This section maps findings and positive controls to the Amazon Data Protection Policy control domains, the SOC 2 Trust Services Criteria, and ISO 27001:2022 Annex A. This penetration test is separate-evaluation evidence produced by a party with no role in building or operating the systems under test. Cybersecify is not a CPA firm and does not perform the SOC 2 examination, is not ISO 27001 or SOC 2 certified, and does not approve the DPP submission; Amazon approves the submission and the client's auditor decides, under their own professional standards, what to do with this evidence.

A. Positive Controls Confirmed

Controls confirmed operational during the assessment; these support the DPP attestation and the provider's responses on the applicable published DPP control domains.

B. Amazon DPP Control Domain Status

C. SOC 2 Trust Services Criteria Coverage

D. ISO 27001:2022 Annex A Coverage

DPP and AUP section numbers reference the published Amazon SP-API Data Protection Policy and Acceptable Use Policy, and should be confirmed against the current published versions before submission.

Programme Appendix

Finding-to-DPP control mapping and priority-band coverage for the SP-API Data Protection Policy submission programme.

Appendix

A. Testing Team and Authorisation

Certification verifiable via the assessor's Credly badge issued by OffSec.

B. Report Distribution

C. Glossary

Disclaimer

Limitations of Testing

Penetration testing is inherently limited by the scope, time, and resources allocated to the engagement. No individual or organisation can guarantee identifying all security issues. The testing performed is conducted on a best-effort basis, and the findings reported herein are specific to the environment provided for testing.

Scope of Findings

The reported findings apply exclusively to the tested environment and configurations during testing. Information systems rely on human factors and can be inherently vulnerable to human error. While Cybersecify has endeavoured to identify significant security vulnerabilities in the analysed systems, it is impossible to assure that all potential vulnerabilities have been discovered. This document does not constitute legal advice.

Continued Vigilance

Security is an ongoing process. Regular assessments and updates to security measures are essential to maintaining a strong security posture. Cybersecify recommends periodic penetration testing and continuous monitoring to adapt to new threats and vulnerabilities.