One merchant reaching another merchant's data
Store, order, customer or product IDs that aren't scoped to the merchant, exposing another store's customers and sales.
Industries
Penetration Testing for E-commerce SaaS
E-commerce platforms are attacked for money, accounts and customer data. We test checkout logic, merchant isolation and the scripts on your payment pages.
Why it's different
Security testing for E-commerce SaaS products
E-commerce platforms are attacked because they are worth attacking. They hold shopper accounts with saved addresses and payment tokens, merchant revenue, payouts, gift cards and loyalty balances. Attackers come for money, for accounts they can resell, and for card data they can skim from checkout pages.
If you run a commerce platform for many merchants, there is a second layer of risk. Each merchant trusts you to keep their customers, orders and sales away from every other merchant on the platform, and to keep third-party apps in their lane.
Where e-commerce testing differs
- The checkout is business logic. Prices, discounts, shipping, tax, stock and refunds all need to be calculated and enforced on the server, and to hold up under parallel requests.
- Accounts are a target in themselves. Credential stuffing and weak recovery flows lead to account takeover, fraud and support load.
- The payment page is in scope even when the card form isn’t. Scripts on the pages around checkout can be abused to steal card data, which is why PCI DSS v4.0.1 added specific requirements for them.
- Merchant isolation is the platform’s promise. Testers use separate merchant accounts and staff roles to check that nothing crosses between stores.
We test with staging stores and test payment methods wherever possible, and agree any production testing in writing first.
Common findings
What attackers go after
The issues we look for first in E-commerce SaaS products. Typical severity shown; real ratings depend on your system.
Checkout, price and discount manipulation
Prices, quantities, shipping or tax taken from the client, discount codes stacked or reused, and gift card balances spent twice.
Account takeover at scale
Login, password reset and one-time code endpoints without rate limits, letting attackers test leaked passwords against shopper accounts.
Malicious or unmanaged payment page scripts
Third-party and tag-manager scripts on checkout pages that could be altered to skim card data, without an inventory or change detection.
Staff and app permission gaps
Store staff roles that can export customers or change payouts, and third-party apps granted broader API scopes than they need.
Order and inventory race conditions
Parallel requests that oversell limited stock, redeem single-use offers repeatedly or refund the same order twice.
Exposed admin and integration endpoints
Forgotten admin panels, debug endpoints and old API versions reachable from the internet.
Scope
Recommended scope
Where we usually start. We'll confirm the right scope with you on a scoping call.
Web Application Penetration Testing
Storefront, checkout, merchant admin and staff roles, with pricing and discount logic tested by hand.
API Penetration Testing
Storefront, admin and partner APIs, including app and plugin permissions and webhooks.
External Network Penetration Testing
Internet-facing hosts, admin panels and forgotten subdomains across your platform.
Cloud Security Testing (AWS, Azure, GCP)
Cloud accounts holding customer data, media storage and order databases.
FAQ
E-commerce SaaS testing questions
We use a hosted payment provider. Do we still need testing?
Yes. Hosting the card form elsewhere reduces your PCI DSS scope, but the page that loads it, your accounts, pricing logic and merchant data are still yours to protect. PCI DSS also has requirements for scripts on the page that hosts or redirects to payment.
Can you test pricing and discount logic safely?
Yes. We test in a staging store with test payment methods wherever possible. If testing needs production, we agree in advance which orders can be placed, use test products and cancel anything we create.
Do you test third-party apps and plugins?
We test how your platform authorizes them: the scopes they can request, what data they can reach and whether one app can affect another merchant. Testing third parties' own code needs their permission, which we can discuss during scoping.
How do you handle account takeover testing without locking out real shoppers?
We use our own test accounts and agree rate limits and timing with you. We never test credentials against real customer accounts.
Need a pentest for an audit, a customer, or peace of mind?
Tell us what you need tested. You’ll get a fixed-fee proposal with tester-days and timeline stated, usually within a few days of the scoping call.