eCommerce penetration test report with scope, OWASP, APIs, checkout, severity, remediation and retest

Penetration testing for eCommerce: what a serious report must contain

Reading time: 6 minPublished on 10 July 2026By BitHubTopic Cyber Security

A penetration test for an eCommerce store shouldn't end with a PDF full of incomprehensible acronyms. It should help you understand what you're risking, what to fix first and how to verify that the problem has genuinely been solved.

Plenty of security reports look technical but aren't operational: a list of generic vulnerabilities, screenshots with no context, severities assigned at random, no business priorities, no reproducible evidence and no remediation plan.

For an eCommerce store that isn't enough. An online shop has a checkout, customer accounts, orders, payments, coupons, shipping, APIs, feeds, a CRM, ERP systems, marketplaces, forms and personal data. A serious report has to speak that language.

Before the report: the scope has to be clear

The first sign of seriousness is the scope. Before testing, you have to know what's in and what's out.

Main domain and subdomains.
Environment tested: production, staging or a dedicated copy.
Public area, customer area, checkout, back office, APIs.
Test accounts available.
User roles: customer, agent, admin, staff, B2B.
Payment gateway and whether methods are live or dummy.
Integrations with ERP, CRM, couriers, feeds and marketplaces.
Operational limits: time windows, rate limits, destructive tests excluded.
Emergency contacts.

Without a scope, a penetration test risks being either too superficial or too dangerous. On a live eCommerce store you have to test properly, but without breaking sales, orders or data.

Executive summary: it's for the people who approve budget too

A good report needs a summary that a non-technical reader can follow.

The executive summary should explain:

the overall risk level;
the most exposed areas;
possible impacts on sales, data and continuity;
the number of vulnerabilities by severity;
immediate priorities;
recommended remediation timescales;
residual risks once the work is done.

If the report doesn't help you decide what to do on Monday morning, a fundamental piece is missing.

Findings: every vulnerability has to be reproducible

Every finding has to contain clear data, not just a title.

Title: an understandable name for the vulnerability.
Severity: critical, high, medium, low or informational.
Asset involved: URL, endpoint, function, role or module.
Description: what happens and why it's a problem.
Impact: what an attacker can obtain.
Reproduction steps: how to verify the problem.
Evidence: screenshots, request/response pairs, logs or sanitised payloads.
Recommendation: how to fix it in concrete terms.
References: OWASP, CWE, CVE or technical documentation.
Remediation status: open, mitigated, fixed, to be retested.

A finding that can't be reproduced is hard to fix. A developer has to be able to open the report and understand where to act.

The critical areas of an eCommerce store

An eCommerce test has to go beyond automated scanning.

The areas to include are:

Customer accounts: registration, login, password reset, email change, addresses.
Checkout: cart, coupons, shipping, payments, order confirmation.
Orders: visibility, editing, IDOR, access to other people's orders.
APIs: authentication, authorisation, rate limiting, exposed data.
Back office: roles, permissions, uploads, exports and admin actions.
Catalogue: search, filters, parameters, image uploads, import/export.
Forms: contact, newsletter, reviews, tickets and attachments.
Integrations: ERP, CRM, couriers, marketplaces, feeds.
Sessions: cookies, logout, lifetime, account protection.
Personal data: exposure, downloads, logs and permissions.

That's exactly where a generic test and an eCommerce test part ways: understanding the sales flows and the real data moving through the system.

OWASP, APIs and business logic

OWASP is an important baseline, but ticking off a list isn't enough.

An eCommerce store can have the classic technical vulnerabilities:

SQL injection;
XSS;
CSRF;
IDOR;
insecure file upload;
weak sessions;
misconfigurations;
badly exposed APIs.

But it can also have business logic bugs:

coupons that stack beyond what was intended;
prices that can be manipulated client-side;
shipping costs that can be bypassed;
an order visible by changing an ID;
a return or refund that can be triggered without authorisation;
stock or cart altered with modified requests;
B2B roles or agent price lists that aren't properly isolated.

These problems often don't surface in an automated scan. You have to understand how the shop works.

Severity: saying "critical" isn't enough

Severity has to be justified. A critical vulnerability on an unreachable endpoint is a different matter from a medium vulnerability exploitable by any authenticated customer.

A serious report weighs up:

ease of exploitation;
privileges required;
impact on personal data;
impact on orders and payments;
whether it can be automated;
public exposure;
existing mitigations;
real likelihood in that specific context.

The priority has to support a decision: what gets fixed today, what within 7 days, what in the next development cycle.

Remediation: the report has to say how to fix it

Saying "sanitise input" or "improve security" isn't enough.

Remediation has to be concrete:

the file, function or endpoint involved;
the missing control;
the recommended pattern;
the test to add;
the configuration to change;
a temporary measure if the fix takes time;
the expected impact on UX or performance;
the criterion for considering the finding closed.

The report has to be usable by the technical team, not just filed away in a folder.

Retest: without a final check, half the work is missing

Once the fixes are in, a retest is needed. It isn't a formality.

The retest verifies whether:

the vulnerability has genuinely been resolved;
the fix hasn't created regressions;
the mitigations are effective;
the findings can be closed;
residual risks remain to be accepted or planned for.

A report with no retest leaves the client wondering: "did we fix it, or did we just change something?"

What a serious supplier has to deliver

Scope and methodology.
Executive summary.
List of assets tested.
Detailed technical findings.
Risk matrix.
Reproducible evidence.
Remediation priorities.
Guidance for developers.
List of exclusions and test limitations.
A retest report once the fixes are in.

If all you get is an automated PDF with a hundred generic alerts, you don't have a penetration test: you have a scan.

How we handle it at BitHub

In eCommerce tests we start from the real flows: catalogue, search, cart, checkout, accounts, orders, APIs, integrations and back office.

The output has to be useful to three different people:

the owner, who needs to understand risk and priorities;
the technical team, who need to fix things without ambiguity;
whoever runs the business, who needs to know which processes to protect.

This ties into our services for eCommerce penetration testing, vulnerability assessment and cyber security for websites.

Useful sources

For the structure of the report and the checks we drew on the OWASP Web Security Testing Guide, OWASP ASVS and the OWASP API Security Project.

FAQs

How long does an eCommerce penetration test take?

It depends on scope, complexity, APIs, roles and integrations. A serious test requires scope definition first, then execution, report, remediation and retest.

Is an automated scan enough?

No. Scans help, but they don't find many business logic bugs, broken authorisation, checkout problems or vulnerabilities tied to real flows.

Should the test be run in production?

Not always. You can work on staging if it's a faithful copy of production. Some checks, however, do need controlled verification in the live environment.