An e-commerce platform is one of the most complex targets for a pentester. Within a single architecture, it concentrates the business logic of order processing, integrations with payment gateways, account management mechanisms for hundreds of thousands of customers, API interfaces for mobile applications, and often an administrative panel with full access to the product and transaction database. Each of these components can contain vulnerabilities that cybercriminals are actively willing to seek out — because the gains from online stores are measurable and immediate.
In practice, I observe that online stores are attacked in a layered manner: first reconnaissance and technology identification, then automated attempts (credential stuffing, scanning for known CMS vulnerabilities), and finally manual exploration of business logic — where automated scanners are helpless and an attacker can apply creativity. This guide describes how to approach penetration testing of an e-commerce platform methodically: from defining the scope, through attack scenarios, to interpreting the report and planning the testing cycle.
Why does an e-commerce platform require regular penetration testing?
An e-commerce platform is a particularly exposed environment for several reasons that, in other types of applications, do not overlap with such intensity. First, it processes payment card data or initiates financial transactions — even if the actual card data is stored by an external gateway, any vulnerability enabling interception of requests during checkout can redirect a payment or modify the amount. Second, the e-commerce customer database is itself a valuable asset: addresses, phone numbers, order history, and often passwords — data that has a specific price on the dark web market.
Regularity of testing is key here because an e-commerce platform is rarely static. New features (loyalty programs, subscriptions, coupons), marketplace integrations, CMS plugin updates (WooCommerce, Magento, PrestaShop) — every change potentially introduces a new attack surface. A one-time pentest conducted a year ago says nothing about the security of the system after a new payment module has been deployed.
Furthermore, regulations create a concrete obligation. PCI DSS (Payment Card Industry Data Security Standard) requires penetration testing at least once a year and after every significant change in the CDE (Cardholder Data Environment). Failure to meet this requirement can result in losing the ability to accept payment cards — which for most stores means the end of operations. GDPR, in turn, imposes an obligation to implement appropriate technical measures for protecting personal data, and regular pentests are one of the tools for documenting this due diligence.
Key principle: For e-commerce, we do not ask “whether pentests are worthwhile”, but “how often and with what scope”. Every platform processing transactions or customer data is a target with a measurable value for attackers.
It is also worth looking at the real costs of an incident. A data breach at an online store is not only fines from the data protection authority — it is loss of trust, customer attrition, the obligation to notify all affected parties, regulatory audits, and PR crisis management costs. Industry estimates indicate that the average cost of a data breach in retail exceeds 3 million dollars, and for SMEs it can be existential. Investment in a regular pentest is a fraction of that risk.
What vulnerabilities do pentests of online stores most commonly reveal?
In practice, e-commerce platform pentests reveal a recurring set of vulnerability categories, although specific implementations are always unique. At the top, access control issues invariably feature — particularly IDOR (Insecure Direct Object Reference), where changing an order identifier in a URL or API request allows viewing other people’s orders. In one of the missions I carried out, changing the parameter order_id=12345 to order_id=12346 exposed the complete order data of another customer: delivery address, phone number, cart contents.
Second place goes to business logic vulnerabilities that no automated scanner will detect. Examples include: the ability to apply a discount code multiple times (lack of server-side validation), manipulation of a product price by modifying hidden form fields or JSON parameters in a checkout request, placing an order with a negative product quantity (resulting in a negative amount payable), or bypassing the limit on single-use coupons through parallel HTTP requests (race condition). These errors arise because developers focus on the “happy path” and rarely think about what will happen when a customer sends unexpected data.
API vulnerabilities constitute a growing category, because modern e-commerce platforms increasingly rely on an API-first architecture with a React or Vue frontend. The API for a mobile application often has different (weaker) authorization mechanisms than the web interface, or exposes more fields in JSON responses than necessary (mass assignment, excessive data exposure). Burp Suite allows full inspection of API communications and modification of requests in real time — this is a core element of every e-commerce pentester’s toolkit.
Typical e-commerce vulnerability categories: IDOR in order and account resources, business logic errors (coupons, prices, limits), weak authentication and session management, XSS and CSRF vulnerabilities in review/comment components, unsecured API endpoints, errors in payment gateway integration, weak password management and lack of credential stuffing resistance.
Injection — SQL Injection, NoSQL Injection, template injection — still appears in older or less well-maintained platforms. In stores based on popular CMSs such as WooCommerce or Magento, vulnerabilities often lurk not in the core, but in third-party plugins and extensions. Scanning for known CVEs for installed plugins is a mandatory element of every e-commerce pentest. Tools such as WPScan for WordPress or mageaudit for Magento automate part of this work, but always require manual verification.
What does the scope of penetration testing for e-commerce look like — application, API, infrastructure, payments?
Defining the scope is one of the first and most important stages of any pentest. For an e-commerce platform, the scope is typically broader than for a typical web application, because it encompasses several layers that must be tested together, not separately.
The web application layer is the customer-facing frontend: the homepage, product listings, product pages, shopping cart, checkout, customer panel (order history, addresses, preferences), review and rating module, contact forms. Here we test OWASP Top 10 vulnerabilities for web applications: XSS in search fields and reviews, CSRF in forms, access control errors, session management issues (fixation, lack of invalidation after logout), security of password reset mechanisms.
The API layer covers both the API used by the frontend and dedicated APIs for mobile applications or B2B integrations. We test authorization (does every endpoint require a valid token?), authenticity (is the token correctly validated?), permission scope (can a customer call endpoints reserved for the admin?), query limits (rate limiting), error handling (do error messages reveal implementation details?), and also the security of webhooks from payment gateways.
The administrative panel deserves separate attention. Access to the admin panel gives an attacker full control over the platform: management of products, orders, user accounts, payment settings. We test the strength of admin authentication mechanisms (MFA, IP whitelist), resistance to brute force attacks, XSS vulnerabilities in product editing fields (stored XSS executed in the admin context is a critical vulnerability), and the separation of privileges between different employee roles.
E-commerce pentest scope should include: the web application (frontend + backend), APIs (web and mobile), the administrative panel, payment gateway integrations (in sandbox mode), network infrastructure (if self-hosted), and in advanced projects — the mobile application and CDN/WAF mechanisms.
Infrastructure — servers, load balancers, CDN, databases — is within the scope of infrastructure pentests, which can be part of a broader engagement. For cloud platforms (AWS, GCP, Azure) we test S3/Cloud Storage configuration (public access to private buckets), IAM policies, exposure of services on the public network, and the security of Docker/Kubernetes containers. Tools such as ScoutSuite or Prowler automate part of the cloud configuration audit, but require appropriate read permissions on the configuration.
How to test the security of payment gateway integrations?
Testing payment gateway integrations is one of the most difficult and most critical elements of e-commerce pentests. Most difficult — because it requires understanding payment protocols, tokenization, and webhooks. Most critical — because errors here lead directly to financial losses or theft of card data.
The first rule: tests of payment integrations are always conducted in the gateway’s sandbox environment, never in a production environment with real cards. All major gateways (Stripe, PayU, Przelewy24, Tpay, Adyen) provide a full test environment with test card numbers. The client must provide access to the sandbox environment or a dedicated staging environment that mirrors the production configuration.
The main scenarios we test in payment gateway integration:
Webhook signature verification. Payment gateways send webhooks (HTTP POST notifications) about changes in transaction status. The platform should verify that the webhook genuinely originates from the gateway — typically by verifying the cryptographic signature (HMAC-SHA256) of the header. The absence of this verification allows an attacker to send a forged webhook informing of a “successful payment” without an actual transaction. In Burp Suite, you can intercept the original webhook and send a modified version with a different amount or status.
Amount manipulation after payment initialization. Some integrations initialize a payment session on the gateway side with an amount taken from client request parameters. We test whether changing the amount in the POST request initializing the payment (e.g., amount=1 instead of amount=29900) is validated server-side by the platform before passing it to the gateway, and after returning from the gateway — whether the platform verifies that the paid amount corresponds to the order amount.
Race condition in payment processing. If the webhook confirming payment is not idempotent, sending it multiple times in a short period can cause multiple order fulfillments or the application of a discount multiple times. Burp Suite Turbo Intruder allows sending dozens of parallel requests in “race window” mode, which is the standard technique for testing race conditions.
Key scenarios in payment testing: lack of webhook signature verification, amount manipulation before/after payment session initialization, race condition in webhook handling, reuse of a payment token, lack of currency validation, ability to reverse/cancel an order after payment while retaining the funds.
Payment token security. Modern integrations use tokenization — instead of processing card data, the platform operates on tokens issued by the gateway. We test whether tokens are single-use (can the same token be used for multiple transactions?), whether they are bound to a specific customer (can customer A’s token be used by customer B?), and how the platform responds to attempts to use expired or revoked tokens.
How does a pentester simulate an attack on the cart and checkout process?
The cart and checkout are the heart of the e-commerce platform from a security perspective — this is where the actual financial transaction occurs, so errors have direct economic consequences. In practice, I test this area with particular thoroughness, combining automated techniques with manual exploration of business logic.
The first step is a complete map of the checkout flow from an HTTP perspective. Burp Suite allows interception of all HTTP requests during checkout and displays them as a sequence in History. I identify all points where the client sends data to the server: adding a product to the cart, changing quantity, selecting the delivery address, selecting the payment method, confirming the order. Each of these points is a potential place for manipulation.
Price manipulation in the cart — a classic test. I add a product to the cart, proceed to checkout, and in Burp Suite I intercept the cart update request. I modify the value of the price or unit_price field and check whether the server accepts the modified price. A well-secured platform ignores the price sent by the client and retrieves it from the database based on the product ID. A poorly secured one — processes the price from the client’s request.
Modifying quantity to negative values or unrealistically large ones. A negative quantity can result in a negative order total. A very large quantity can cause arithmetic overflow (e.g., Integer overflow when multiplying price by quantity). I test boundary values: -1, 0, 999999, 2147483647 (INT_MAX), and even floating-point values where an integer is expected.
Bypassing coupon validation. Single-use coupons or those with usage limits are a common target. We test: is the coupon code validated server-side at the moment of order finalization? Can it be used multiple times by the same user? Is there a race condition — if I send 50 parallel order finalization requests with the same coupon, how many times will it be applied? Burp Suite Intruder and Turbo Intruder are excellent for testing this type of scenario.
Attack scenarios on checkout: product price manipulation, negative cart quantity, multiple use of a single-use coupon, race condition in order finalization, changing payment method to a free one, changing the delivery address after payment, manipulation of shipping cost calculation.
Simulating an abandoned cart and replay attack. If the platform generates a session token for the checkout process, we test whether the token can be used multiple times. A token that is not invalidated after a successful payment can be used to “complete” an already paid order again — which can lead to double delivery without double payment. I also check whether checkout tokens have an appropriate expiry time and whether expiration is enforced server-side.
Delivery method manipulation. Shipping costs are often calculated client-side or passed as a request parameter. Modifying the value shipping_cost=0 or shipping_method=free can result in free shipping without authorization. I also test whether the selection of a more expensive delivery method and its change during checkout is handled correctly — whether the discount for the originally selected option does not persist in the session.
How to test account security against attacks — credential stuffing, account takeover?
Customer account security is an area that has unique importance in e-commerce — accounts contain order history, saved addresses, payment methods, and often wallet balances or loyalty points. Account takeover is itself a goal for attackers.
Credential stuffing is an attack consisting of automatically testing login:password pairs taken from public data breaches (breached credential databases). The attacker assumes that a significant portion of users use the same passwords across different services. In tests, we check the platform’s resistance to this scenario: is there rate limiting on the login endpoint? After how many failed attempts is the account locked or CAPTCHA required? Does the rate limiting mechanism operate at the account level, the IP address level, or both?
Burp Suite Intruder with a list of test login:password pairs allows simulation of credential stuffing in a test environment. A key aspect here is agreeing with the client on which test accounts can be used — we never test on real customer accounts. We also check whether the application reveals whether a given login (email) exists in the system by differentiating error messages: “Invalid login or password” (correct) vs “No user found with the provided email address” (reveals the account exists).
Protections against credential stuffing: rate limiting per IP and per account, CAPTCHA after N failed attempts, account lockout with email notification, IP address verification when logging in from a new device/location, MFA requirement for accounts with saved payment methods, integration with breach databases (HaveIBeenPwned API).
Account takeover via password reset is the second popular vector. We test the password reset mechanism for: whether the reset link/token is single-use and has an appropriate lifetime (max 15-30 minutes); whether the token has sufficient randomness (min 128 bits of entropy) and is not predictable (sequential, timestamp-based); whether the old token is invalidated after use or after a new reset request; whether resetting the password logs the user out of all active sessions.
Account takeover via email change. If the platform allows changing the email address without additional verification (confirmation sent to the old address, or password re-entry), an attacker who gains brief access to an account (e.g., through a borrowed device) can permanently take it over by changing the email address. We test whether changes to sensitive account data require re-authentication.
User enumeration. Beyond the login form, we check other vectors that reveal account existence: the “forgot password” form (difference in response time or content), the registration endpoint (message “this email is already taken”), the API (/api/users/check-email). User enumeration allows an attacker to build a list of existing accounts before a credential stuffing attack.
Session management verification. After the client logs in, we test the quality of session management: does the session token have sufficient entropy? Is it httpOnly and Secure? After logout, is the token invalidated server-side (server-side invalidation)? Does the session expire after a period of inactivity? Does logging in from a new device notify the user? Tools such as Burp Suite and jwt_tool (for JWT) allow analysis and attempted manipulation of session tokens.
How to interpret a pentest report for e-commerce — repair priorities?
An e-commerce pentest report typically reaches several recipients simultaneously: the development team, which must fix the vulnerabilities; the CISO or CTO responsible for prioritizing resources; and sometimes the board requiring a business risk assessment. A good report is useful for each of these groups.
Each vulnerability in the report should contain: a unique identifier, a technical description (what it is and how it works), steps to reproduce (step-by-step, reproducible by a developer without pentesting expertise), proof of exploitation (Proof of Concept — a screenshot from Burp Suite, a modified HTTP request, tool output), a risk assessment (severity) according to the CVSS scale or the pentester’s own scale, business impact (what the attacker can achieve, what data they can obtain, what financial losses they can generate), and concrete remediation recommendations together with a code or configuration example.
Repair priorities in the context of e-commerce should account not only for technical severity, but also for the business specifics of the platform. An IDOR vulnerability in order history (theoretically Medium according to CVSS) in an e-commerce platform with a million customers is effectively critical — the scale of the potential data breach is enormous. A logic error in discount calculation (technically Low) can, at a scale of a thousand transactions per day, generate real financial losses.
Prioritization framework for e-commerce: Fix immediately — vulnerabilities enabling account takeover, payment manipulation, or access to all customer data. Fix within a week — IDOR in customer resources, XSS in the admin panel, lack of webhook signature verification. Fix within a month — weak session management, user enumeration, lack of rate limiting. Plan on the roadmap — overly detailed error messages, missing security headers, outdated libraries without known exploits.
Good practice dictates that the report contains an Executive Summary — a 1-2 page section describing the overall security posture of the platform, the number of vulnerabilities found by severity, the most important business risks, and general strategic recommendations. This section is intended for the board and does not require technical knowledge. Detailed vulnerability descriptions go into the Technical Details section, intended for developers and administrators.
After delivering the report, it is worth scheduling a Q&A session with the development team. In our projects, we always offer a technical briefing during which we discuss each vulnerability, answer questions about recommendations, and help establish realistic repair priorities taking into account the team’s backlog and resources. A report without interpretive support is a document — a report with a briefing is a tool for action.
How often should penetration tests of an e-commerce platform be conducted?
The frequency of pentests should be a function of several variables: the dynamics of platform changes, regulatory requirements, the maturity of the security program, and the available budget. There is no single answer for everyone, but good practices can be identified for different contexts.
The minimum standard arising from PCI DSS is a penetration test once a year (external and internal) and after every significant change in the CDE environment. “Significant change” is a term requiring interpretation — deploying a new payment gateway, adding a new card handling module, migrating infrastructure to the cloud. This means that an actively developed platform may require several pentests per year due to PCI DSS alone.
The recommended standard for e-commerce platforms with traffic above 100,000 sessions per month or order values above 1 million PLN per month is: a full application pentest every six months, a narrower pentest after every major release (quarterly?), and security regression testing (automated security testing) in the CI/CD pipeline. This model allows for maintaining continuous security at manageable costs.
E-commerce pentest cycle: Full pentest (full scope) — every 6-12 months. Focused pentest (new features, new integrations) — after every significant release. Automated vulnerability scanning (DAST) — in CI/CD pipeline, with every deployment to staging. Red team exercise (simulation of a real attacker) — once every 2 years for mature security programs.
Additional pentest triggers regardless of the schedule: deploying a new payment gateway or changing providers, migrating to a new CMS or e-commerce platform, launching a loyalty program with customer wallets, integrating with a new marketplace (Allegro, Amazon), and — importantly — the appearance of reports of vulnerabilities in used components (e.g., critical CVE for WooCommerce or Magento).
For startups and small stores, where the budget is limited, the recommended minimum is a pentest of the application before launching the platform and then an annual pentest. Between full pentests, it is worth investing in automated vulnerability scanning (tools like OWASP ZAP in CI mode or commercial solutions like Detectify) — a cheaper form of continuous monitoring that does not replace manual pentesting, but significantly reduces the attack surface between full engagements.
What does the e-commerce pentest process look like from engagement to report?
The table below presents the full course of the e-commerce pentest process — from first contact through delivering the report and verifying the fixes.
| Phase | Duration | Activities | Results | Tools |
|---|---|---|---|---|
| 1. Scoping and preparation | 2-5 days | Defining scope (in-scope/out-of-scope), signing NDA and test authorization, preparing the environment (test accounts, gateway sandbox access), establishing schedule and test window | Scope document, test authorization, test environment, emergency contact | — |
| 2. Reconnaissance and OSINT | 1-2 days | Analysis of public information about the platform (technologies, libraries, subdomains), fingerprinting the technology stack, analysis of robots.txt file, sitemap, HTTP headers | Technology map of the platform, list of subdomains and API endpoints, known CVEs for used components | Nmap, Wappalyzer, Shodan, theHarvester, WPScan, Nuclei |
| 3. Application analysis | 3-5 days | Manual exploration of the entire application, mapping the checkout flow, identification of all API endpoints, analysis of authentication and authorization mechanisms, inspection of client-side JavaScript | Complete application map, list of endpoints for testing, preliminary identification of potential vulnerabilities | Burp Suite, browser DevTools, Postman, FFUF |
| 4. Vulnerability testing | 5-10 days | Manual testing of all identified vulnerabilities, business logic tests (cart, checkout, coupons), payment integration tests in sandbox, credential stuffing simulation, API tests, race condition tests | List of confirmed vulnerabilities with Proof of Concept, severity assessment of each vulnerability | Burp Suite Pro, SQLmap, Hydra, Turbo Intruder, jwt_tool, custom Python scripts |
| 5. Exploitation and impact assessment | 2-3 days | Demonstrating the actual impact of critical vulnerabilities (without data destruction), assessing post-exploitation paths, combining vulnerabilities into attack scenarios (attack chains) | Exploitation evidence (screenshots, recordings, modified requests), business risk assessment, attack scenarios | Burp Suite, Metasploit (in limited scope), custom scripts |
| 6. Reporting | 3-5 days | Documentation of all vulnerabilities with reproduction steps, preparation of Executive Summary, prioritization of recommendations, report review by senior pentester | Final PDF report (Executive Summary + Technical Details + Appendix), presentation of results to client | Markdown/LaTeX + custom report template |
| 7. Remediation support and re-test | 5-30 days (depending on client) | Q&A with development team, support in implementing fixes, re-testing of fixed vulnerabilities, updating the report with fix statuses | Updated report with fix confirmation (re-test certificate), list of vulnerabilities remaining open | Burp Suite, manual verification |
The total duration of a typical project is 3-6 weeks, of which 2-4 weeks are active testing, and the remaining time — scoping, reporting, and remediation support. Projects with a wider scope (application + API + infrastructure + mobile application) may take longer.
How does nFlo conduct penetration tests for e-commerce companies?
At nFlo, we carry out penetration tests of e-commerce platforms as structured projects, in which we combine deep technical knowledge with an understanding of the business specifics of electronic commerce. We work with both platforms based on popular CMSs (WooCommerce, Magento, PrestaShop) and with custom solutions written for specific client requirements.
Our team of pentesters has experience in testing the full e-commerce stack: web applications, APIs (REST and GraphQL), mobile applications (iOS and Android), integrations with payment gateways (Stripe, PayU, Przelewy24, Tpay, Adyen, Blue Media), and also cloud infrastructure (AWS, Azure, GCP). OSCP, CEH, and eWPT certifications in our team guarantee methodical approach and up-to-date knowledge of attack techniques.
Every project begins with detailed scoping — we do not accept standard scopes without a conversation about the specifics of the platform. For a store with a loyalty program and customer wallets, the scope and priorities will be different from a simple B2C store without saved payment methods. This conversation allows us to plan tests that deliver maximum value within the client’s budget.
What an nFlo e-commerce engagement includes: a written scope covering the storefront, the checkout flow, the APIs behind the mobile app and the admin panel; a named test team; agreed stop conditions for testing against a live store; and a report with reproduction steps and remediation guidance per finding, followed by a retest of what was fixed.
Our reports are written with three audiences in mind simultaneously: the board (Executive Summary with business risk assessment), CISO/CTO (Risk Matrix with priorities and remediation costs), and the development team (detailed reproduction steps with remediation code examples). After delivering the report, we organize a Q&A session with the client’s technical team — at no extra cost, because we believe that a report without knowledge transfer has half the value.
For clients with actively developing platforms, we offer a continuous security model: regular, smaller tests after each release, supplemented by automated DAST scanning in the CI/CD pipeline. This is a more cost-effective approach than one large pentest once a year, and at the same time much better suited to the dynamics of modern e-commerce, where new features are released every week.
FAQ — Frequently asked questions about e-commerce pentests
Can penetration tests disrupt the operation of an online store?
A well-conducted pentest does not disrupt the store’s operation. We work in a dedicated test environment (staging) or, if tests must be on production, we avoid destructive actions and agree on a test window (e.g., night, weekend). Before each project, we establish with the client the exact rules — what is permitted and what is not.
How long does a pentest of an e-commerce platform take?
A typical project takes 3-6 weeks: 1 week for scoping and preparation, 2-3 weeks for active testing, 1 week for reporting. For narrower scopes (e.g., only the API), the time is shorter. Projects covering the web application, API, mobile application, and infrastructure may take 6-8 weeks.
Does PCI DSS require e-commerce pentests?
Yes. PCI DSS requirement 11.4 imposes an obligation to conduct penetration tests at least once a year and after every significant change in the CDE environment. Tests must cover both the network and application layers, and must be carried out by a qualified internal or external tester.
What is the difference between a pentest and vulnerability scanning?
Vulnerability scanning is the automatic detection of known vulnerabilities based on signatures — fast, inexpensive, but limited to known issues and generating many false positives. A pentest is a manual simulation of an attack with vulnerability verification, exploitation, and assessment of actual business risk — slower and more expensive, but providing a significantly more complete picture of security. For e-commerce, both approaches complement each other.
What should a good e-commerce pentest report contain?
Executive Summary (business risk, overall assessment), Risk Matrix (vulnerabilities by severity and repair priority), detailed descriptions of each vulnerability with reproduction steps and Proof of Concept, remediation recommendations with code or configuration examples, information about the scope and methodology of testing, and — after re-testing — confirmation of fixed vulnerabilities.
Related concepts
Explore the key terms related to this article in our cybersecurity glossary:
- Penetration testing — Penetration testing (pentests) is a controlled process of simulating an attack on a system…
- Credential stuffing — Credential stuffing is an attack consisting of automatically testing login:password pairs…
- IDOR — Insecure Direct Object Reference is a vulnerability enabling access to resources…
- PCI DSS — PCI DSS is a security standard for companies processing payment card data…
- Burp Suite — Burp Suite is an integrated platform for security testing of web applications…
Learn more
Read related articles in our knowledge base:
- Penetration testing of web applications — OWASP methodology
- Security audit vs penetration test: what is the difference and when to use each?
- Automation vs manual penetration testing — when to use each method?
- Source code vulnerability analysis
- Infrastructure penetration testing — external vs internal
Check our services
Do you need cybersecurity support? Check out:
- Penetration testing - identification of vulnerabilities in infrastructure and applications
- Security audits - comprehensive assessment of security posture
- Red Team - advanced APT attack simulations
Need expert support? nFlo team can help secure your organization:
