If you run an online store, the short answer on ecommerce penetration testing is yes, you need it, provided you take payments online. Still, the longer answer is more useful. Most quotes you get back will not actually test the part of your store most likely to be attacked. Ecommerce penetration testing is a hands-on assessment of your storefront, checkout and payment integrations. A tester tries to break in the way a criminal would. A large share of what gets sold under that name barely touches the checkout at all.
That gap matters. In January 2026, researchers at Silent Push exposed a skimming campaign that had run since 2022. It injected obfuscated JavaScript into checkout pages, harvesting card data across six major payment networks. A store running that malicious script would have passed a routine vulnerability scan without issue. The scan was never looking in the right place.
Table of Contents
What a Proper Ecommerce Penetration Test Should Include
Before you accept a quote, check the scope covers these points, not just a generic web application checklist with “ecommerce” in the title:
- Payment page script analysis: what third-party code loads at checkout, where it comes from, and whether it can be tampered with.
- Checkout business logic: whether prices, discounts, quantities or shipping costs can be manipulated to your disadvantage.
- Customer account security: authentication, password reset flows, and whether one account can view or edit another’s data.
- APIs behind the storefront, if you run a headless build, mobile app or expose stock and pricing endpoints.
- Plugins and extensions, particularly on WooCommerce or Magento, where the third-party ecosystem is large and unevenly maintained.
A tester who cannot describe how they will assess your payment page scripts has not scoped an ecommerce penetration test. They have scoped a website test and added a label. Want the fundamentals first? Our guide to how penetration testing works covers the basics this article builds on. Everything here sits on top of, not instead of, a standard web application penetration test.
Where PCI DSS Fits, and Where It Does Not Save You
PCI DSS v4.0.1 Requirement 11.4 already requires internal, external and segmentation penetration testing. This must happen at least annually and after any significant change, carried out by a qualified, independent tester, with fixes retested afterwards. Since March 2025, the PCI Security Standards Council’s guidance on Requirements 6.4.3 and 11.6.1 has gone further. It expects merchants to authorise and monitor the integrity of scripts on the payment page specifically. That is the exact control that would have flagged the Silent Push campaign years sooner.
But being PCI compliant is not the same as being tested properly. Compliance sets a floor: annual testing, a documented methodology, retesting of fixes. It does not guarantee the ecommerce penetration testing itself was thorough, because a cut-price provider can tick every compliance box while never seriously trying to break your checkout. Our PCI DSS penetration testing checklist covers what to ask for beyond the bare minimum.
SaaS Platforms Do Not Cover Everything You Have Built
If your store runs on Shopify, BigCommerce or a similar platform, the vendor secures its own core infrastructure. It also does not test your custom apps, the third-party scripts your marketing team has added, your checkout customisations, or any API you have exposed. That is a genuine gap. Merchants routinely assume it is somebody else’s problem. Most platform vendors also require sign-off before you start testing anyway.
Aardwolf Security scopes ecommerce penetration testing around exactly that line: what you have actually built and control, rather than duplicating work the platform already does, as part of our wider penetration testing services. Not sure where that line sits for your setup? Get in touch and we will talk it through before you commit to a scope or a price.
What to Ask a Provider Before You Buy
A handful of direct questions separate serious ecommerce penetration testing from a relabelled generic test:
- Will you specifically examine our payment page scripts and third-party tags?
- Will testing attempt to manipulate checkout pricing and business logic, not just scan for known vulnerabilities?
- How do you handle testing on a live, trading store without disrupting customers?
- Is a retest of fixed issues included, or billed separately?
- Does the report rank findings by real-world exploitability, or just by generic severity?
If a provider hesitates on the first question, keep looking. A test that cannot describe how it treats the payment page is not built for an online store.
What a Weak Test Looks Like in Practice
The easiest way to spot a relabelled generic test is to look at the deliverable. A weak test produces a report dominated by missing security headers and outdated software versions, the output of an automated scanner with a human signature at the bottom. There is little or no mention of the checkout flow. Nobody tried to manipulate pricing. Nobody discusses what scripts the payment page loads.
A stronger report reads differently. It names the specific business logic the tester tried to break and shows evidence of what was attempted against the checkout. The payment page gets treated as a distinct area of focus, not one more page in a site-wide crawl. If your last ecommerce penetration testing report did not mention the checkout by name, it is worth asking why before you renew.
How Often Should You Run an Ecommerce Penetration Test?
Annually at minimum where PCI DSS applies, but test again after anything that changes your attack surface: a new payment provider, a platform migration, a checkout redesign, a new plugin with elevated access, or any change to what scripts your payment page loads. Online stores change their stack more often than most businesses. Testing tied only to the calendar tends to leave the newest change unchecked for the longest. Get the scope of work right before you request a quote. A vague scope is the most common reason a test misses the thing that later gets exploited.
Frequently Asked Questions
How is ecommerce penetration testing different from a general web application test?
It puts specific weight on the checkout flow, payment page scripts, and PCI DSS scope. A generic web application test may not prioritise, or even cover, any of those.
Does PCI compliance mean my store has already been properly tested?
No. Compliance sets a minimum bar: annual testing by a qualified tester, with retesting of fixes. So it does not guarantee the test was thorough.
What is the difference between a PCI ASV scan and a penetration test?
An Approved Scanning Vendor scan is automated, external and runs quarterly. But a penetration test is human-led, tries to exploit findings, and covers business logic a scan cannot assess.
Can a test run against a live, trading store?
Yes, with the right scope. Testers use test transactions, avoid destructive actions against live payment processing, and schedule higher-risk work outside peak trading by agreement.
Do I need testing if my checkout is fully hosted by my payment provider?
Usually yes, though your PCI scope narrows. The rest of the store, accounts, admin access and any APIs, still needs testing.
Should the same provider run our annual PCI test and our broader security testing?
Not necessarily. What matters more is independence. Whoever you use should have no role in building or maintaining your store, and should be able to show evidence of manual checkout testing, not just a scan report with a signature on it.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
