Ecommerce penetration testing is a controlled attack on your online shop, run by a qualified tester, to find the flaws that could expose customer data, card details or your takings before a criminal does. If you take payments on your own site, it is one of the most useful security checks you can buy. If you hand the whole checkout to a payment provider, you still have a smaller but real attack surface to test.
This guide explains what gets tested, how it differs from a vulnerability scan, what the card industry rules say, and how to scope a test so you pay for the right thing.
Table of Contents
What does ecommerce penetration testing cover?
In ecommerce penetration testing, the tester behaves like a patient attacker. They map your shop, then try to break it using the same tools and tricks a criminal would. The aim is to prove what is actually exploitable, not to produce a long list of theoretical issues.
For a typical online shop, the work usually covers four areas:
- The storefront and checkout: login, basket, discount codes, payment flow and order history.
- The admin area: who can reach it, how it is protected, and what a stolen staff password would allow.
- APIs and integrations: the connections to stock systems, payment gateways, shipping and marketing tools.
- The hosting and network: exposed services, outdated software and weak server settings.
Testers often work from several viewpoints. They start as an anonymous visitor, then as a normal customer with a test account, then as a low-privilege staff member. Each view shows a different set of weaknesses.
Why are online shops such a common target?
Shops hold two things criminals want: personal data and payment cards. They also run a lot of third-party code, from plugins to analytics scripts, and that code changes often.
The UK’s National Cyber Security Centre has seen the result. In 2021 it contacted the owners of around 4,000 small online shops whose checkout pages had been compromised, according to Computing’s report. Attackers had planted small pieces of JavaScript that copied card details as customers paid. Because the shop kept working normally, many owners had no idea.
Which flaws do testers find most often?
The OWASP Top 10:2025 is the industry’s reference list of web application risks. Several entries map directly onto how shops get hurt.
| OWASP category | What it looks like in a shop |
|---|---|
| Broken Access Control | A customer changes an order number in the address bar and sees someone else’s order |
| Security Misconfiguration | An admin panel left open to the internet, or debug pages showing server details |
| Software Supply Chain Failures | A compromised plugin or third-party script on the checkout page |
| Injection | A search box or coupon field that lets an attacker query your database directly |
| Insecure Design | A checkout that trusts the price sent from the browser, so a basket can be changed to cost £1 |
| Authentication Failures | No lockout on login, so stolen passwords from other breaches can be tried at scale |
Because of that, business logic flaws deserve a special mention. A scanner cannot tell that a refund can be claimed twice or that a discount code stacks without limit. A human tester can, because they understand how the shop is meant to work. Our guide to the OWASP Top 10 2025 changes covers what to ask your tester about each category.
Is a penetration test the same as a vulnerability scan?
No, though both matter for ecommerce penetration testing plans. A scan is automated. It checks your systems against a database of known problems and reports what it finds. A penetration test adds a person who chains weaknesses together and shows what an attacker could really do with them.
Both have a place, so use them together. Scans are cheap and frequent, so they suit routine checking. A pen test is deeper and slower, so it suits an annual review and any big change. The NCSC makes a similar point in its penetration testing guidance: a test is a core tool but “not a magic bullet”, and it should check your own vulnerability management rather than replace it.
What do the card industry rules require?
If you handle card data, the PCI DSS standard applies. You can find the current version in the PCI Security Standards Council document library. Requirement 11.4 covers penetration testing, and the summary below reflects how compliance specialists such as Bastion describe it.
- Ecommerce penetration testing is needed at least every 12 months and after any significant change to the environment.
- Both internal and external tests are expected, covering the application layer and the network layer.
- If you use segmentation to keep systems away from card data, that segmentation must be tested too.
- Critical and high findings must be fixed and retested before you can validate compliance.
- The tester must be qualified and independent of the systems they test.
Which self-assessment questionnaire you complete matters. Shops that fully outsource payment pages (SAQ A) are not formally required to run a pen test, though it is still sensible. Shops that host their own payment page or collect card data (SAQ A-EP, C or D) are required to. Quarterly vulnerability scans do not satisfy the pen test requirement. If you are unsure which applies, ask your acquirer or assessor. Our write-up of common PCI DSS penetration testing mistakes goes into more detail.
How do you scope ecommerce penetration testing?
Good ecommerce penetration testing starts with a specific scope. The NCSC suggests involving the risk owners, the technical staff who know the system and a representative of the testing team. Between them they should settle the technical boundaries, the test types, the timeframe, any compliance needs and the reporting format.
For a shop, the practical checklist looks like this:
- List every domain, subdomain and API the shop uses, including the staging site if it shares data with live.
- Decide whether the payment gateway page is yours or hosted by a provider. Third-party systems usually need separate permission.
- Prepare test accounts at each privilege level: customer, staff and administrator.
- Agree testing windows, and avoid your peak trading weeks.
- Say whether you want a retest included once fixes are made.
A vague scope is the usual reason a test misses something important or overruns its budget. So, our piece on writing a penetration testing scope of work explains how to avoid that.
How often should an online shop be tested?
At least once a year, because that is also the PCI DSS minimum. Test again after a major change: a replatform, a new payment provider, a redesigned checkout or a large plugin update. A shop that ships changes weekly may want lighter, more frequent testing in between.
What happens after ecommerce penetration testing?
You receive a report that ranks each finding by severity, explains how it was exploited and says how to fix it. Your developers or agency then work through the list, starting with the critical and high items. Once fixes are in, a retest confirms they worked. Skipping that last step is a common mistake, so our guide to remediation and retesting shows why it matters.
If you would like a scoped test of your own shop, Aardwolf Security can help. You can read about our penetration testing services or get in touch for a no-pressure conversation about what your shop needs.
Frequently asked questions
How much does it cost to test an online shop?
Price depends on size and complexity: the number of user roles, how many integrations you have and whether the work includes APIs. A small single-platform shop costs far less than a custom marketplace. Our UK penetration test cost guide explains what drives quotes.
Will testing take my shop offline?
It should not. Testers agree rules of engagement first and avoid techniques that could crash live systems. Many teams test a staging copy for the riskiest checks and run lighter checks on production.
Do I need a test if I use Shopify or another hosted platform?
The platform provider secures its own infrastructure. You are still responsible for your theme, custom code, apps, staff accounts and any APIs you build. Those are what a test would focus on.
Can my developer run the test?
Not for compliance, because PCI DSS expects testers to be independent of what they test, and the people who built the shop will naturally miss their own blind spots.
Is a clean report a guarantee of safety?
No. It shows the shop was in good shape on the days it was tested. New code, new plugins and new attacks appear all the time, which is why regular testing beats a one-off check.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
