E-Commerce & Retail Penetration Testing

An e-commerce site is a payment system with a storefront attached, and attackers treat it accordingly. Every checkout handles card data, every account holds a saved payment method, and every third-party script on the page is a potential thief. E-commerce and retail penetration testing focuses on exactly where the money and the card data move, because that is precisely where attackers concentrate.

Why online retail is a standing target

Three properties make e-commerce uniquely exposed:

It processes payments directly. Card data flows through checkout on every order. That puts you in scope for PCI DSS and makes you a target for anyone who wants card numbers, which is a large and well-organized population.

It runs on a stack of third parties. Payment gateways, analytics, chat widgets, tag managers, marketing pixels, review platforms, a typical checkout page loads scripts from many external domains. Each one executes in the same page as the payment form, and each is a potential entry point. This is the mechanism behind Magecart.

Traffic and seasonality invite abuse. High volume hides malicious activity, and peak periods, the sale, the launch, the holiday, are exactly when attackers strike and when you can least afford downtime.

PCI DSS is the baseline

If you accept card payments, PCI DSS applies, and it requires penetration testing, annually and after significant change, covering both the network and application layers, including any segmentation you rely on to reduce scope. How your integration works changes your obligations: a fully hosted/redirect checkout reduces (but does not eliminate) scope, while any setup where card data touches your own pages pulls the full requirement onto you. Your PCI compliance level and SAQ type decide what you submit each year. Our PCI DSS penetration testing page details what the assessment must cover, our guide to PCI DSS penetration testing requirements breaks down each part of Requirement 11.4, and the PCI compliance checklist walks the broader requirements.

Note the trap: even a “hosted” checkout does not make you safe. If an attacker can modify your pages, they can swap or wrap the hosted payment form, which is exactly what the next section is about.

Magecart and client-side skimming, the defining e-commerce threat

The signature attack against online retail is client-side skimming (Magecart): the attacker injects malicious JavaScript into your checkout, directly or, more often, through a compromised third-party script, that quietly copies card details as the customer types and sends them to the attacker. The customer completes their purchase normally; nothing looks wrong; the theft is invisible to both of you for months.

Because it rides in through a trusted external script, this attack defeats defenses aimed only at your own code. Testing has to examine the third-party scripts on your payment pages, your controls over what those scripts can do (Content Security Policy, Subresource Integrity), and your ability to detect unexpected script changes. This is a scope item generic web tests routinely miss.

PCI DSS 6.4.3 and 11.6.1: the payment page script rules

Two requirements aimed squarely at Magecart became mandatory on March 31, 2025, after starting as best practices in PCI DSS v4.0:

• Requirement 6.4.3 covers every script loaded and executed in the customer’s browser on the payment page, including scripts from third and fourth parties. You need a method to confirm each script is authorized, a method to assure its integrity, and an inventory of all scripts with a written justification for why each one is necessary.
• Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts your staff to unauthorized changes to the payment page’s security-impacting HTTP headers and script contents, as the customer’s browser receives them. It must run at least weekly, or at the frequency your targeted risk analysis sets.

In January 2025 the PCI Security Standards Council removed both requirements from SAQ A, the questionnaire for merchants that fully outsource the payment page, and replaced them with an eligibility check: the merchant confirms its own site is not susceptible to script attacks that could affect its e-commerce systems. The underlying requirements did not go away, and SAQ A-EP, SAQ D, and Report on Compliance merchants still carry both.

A checkout penetration test checks the controls rather than the paperwork. Does the script inventory match what the page actually loads? Do Content Security Policy and Subresource Integrity block a script that is not on the list? Does an injected change to the payment page trigger the 11.6.1 alert? The report gives your QSA evidence for both requirements alongside the Requirement 11.4 test.

What to scope

• The checkout and payment flow end to end, the single highest priority. Card handling, payment-gateway integration, and every script running on those pages.
• Business logic, the e-commerce-specific abuse cases: manipulating prices or quantities, abusing discount and coupon logic, bypassing payment steps, exploiting refund and store-credit flows, gift-card fraud. Scanners never find these.
• Accounts and authentication, saved payment methods, addresses, and order history make account takeover lucrative. Test login, registration, password reset, and defenses against credential stuffing.
• APIs, modern and headless commerce is API-driven; the mobile app and storefront both lean on them. See API penetration testing.
• The platform and its plugins, Magento, WooCommerce, Shopify apps and their extensions. Third-party plugins are a leading source of e-commerce vulnerabilities.
• Infrastructure and cloud, the hosting, CDN, and cloud configuration behind the store.

See web application penetration testing for how the storefront itself is tested. If you also take cards in person, at a hotel front desk or a restaurant table, our page on hotel and restaurant PCI testing covers the on-premises side.

What these tests typically find

• Business-logic flaws, price and quantity manipulation, coupon and refund abuse, payment-step bypasses.
• Vulnerable third-party scripts and plugins, the Magecart entry point, and outdated extensions with known flaws.
• Weak client-side controls, missing Content Security Policy and Subresource Integrity on payment pages, leaving skimming undetectable.
• Account-takeover exposure, weak authentication and no defense against credential stuffing.
• Broken access control in APIs, exposing orders, customer data, or account functions.

What an e-commerce penetration test costs

Our prices are published and fixed in writing before work starts. Web application testing, which covers the storefront and checkout, starts at $5,200. API testing starts at $4,000. A full PCI DSS scope adds external network testing from $4,200 and internal network testing from $6,000. Every penetration test includes a free retest of the findings you fix. The full list is on our penetration testing pricing page.

Frequently asked questions

Do I need penetration testing for my e-commerce site? If you accept cards and validate with a Report on Compliance or SAQ D, yes: Requirement 11.4 calls for internal and external testing at least once a year and after significant change. SAQ A-EP, for sites that affect the payment page without receiving card data, calls for the external test, plus segmentation testing if segmentation reduces your scope. If you fully outsource the payment page under SAQ A, the standard does not require it, but acquirers, marketplaces, and business customers may still ask, and account takeover and discount abuse cost money whether or not PCI applies.

How often should an online store be tested? At least once a year, and again after a significant change such as a replatforming, a new payment provider, a checkout redesign, or a new mobile app that shares the storefront’s API.

Will testing disrupt sales? It should not. We test against staging wherever one exists. When production is the only option, we agree written rules first: no denial-of-service techniques, no real orders beyond agreed test transactions, and windows outside your peak hours.

The short version

E-commerce penetration testing concentrates where retail actually bleeds: the checkout, the payment flow, the third-party scripts on your payment pages, and the business logic around prices, discounts, and refunds. PCI DSS makes testing a baseline requirement, and the defining threat, Magecart client-side skimming, rides in through trusted external scripts, so it has to be tested for specifically, now backed by Requirements 6.4.3 and 11.6.1. In online retail, the payment page is the crown jewel; test it like one.

Evaluating a test rather than reading up? The e-commerce penetration testing services page covers what we test in this sector, which frameworks apply, and the fixed starting prices.

Running an online store and need testing that satisfies PCI DSS and actually checks your checkout for skimming and logic abuse? Scope an e-commerce assessment and we will center it on your payment flow.