Industries
Cyber security for retail & e-commerce.
Storefronts, payment flows and point of sale estates, where downtime and card data both cost real money.
What is actually going on here
Retail security is measured against a clock that somebody else sets. The sale date is fixed, the traffic is a multiple of normal, and every control that adds latency is under commercial pressure to be relaxed. Attackers know the calendar as well as you do.
The technical shape has moved. Card data increasingly sits with a payment provider, which shrinks PCI scope, but the checkout page still runs scripts from a dozen third parties and that is where skimming now happens. PCI DSS v4 responded with explicit script management requirements, and most merchants are not yet meeting them.
We test checkout, loyalty and fulfilment together, because the abuse that actually costs money usually spans them rather than sitting inside one.
Who regulates you, and what they want
Tick the ones that bind you and we will pull together the evidence each of them actually asks for. Nothing is sent anywhere.
Pick one or more above to see what they expect of you.
What goes wrong in this sector
Magecart and checkout skimming
Malicious script injected through a third party tag or a compromised dependency, reading card details from the DOM before your provider ever sees them. Server side security is intact throughout, which is why it goes unnoticed for months.
Account takeover and credential stuffing
Retail accounts hold stored cards, addresses and loyalty balances, and customers reuse passwords. The attack is entirely automated and shows up as a modest rise in failed logins if nobody is watching for it.
Loyalty and voucher abuse
Points and vouchers are money with weaker controls. Race conditions on redemption, discount stacking and enumerable voucher codes each convert directly into loss and rarely appear in a standard test.
Peak season availability attacks
Extortion timed to your busiest hours, or scalping bots that exhaust inventory in seconds. Both are business impact rather than data breach, and both need testing before the season rather than after.
How we work in this sector
- 01
Inventory the checkout page
Every script, its origin and its justification. Most merchants find tags nobody can account for, occasionally from vendors the contract ended with.
- 02
Test the money paths
Checkout, refunds, loyalty redemption and voucher application, tested for race conditions and logic abuse rather than only for injection.
- 03
Rehearse peak before peak
Load and resilience testing scheduled well ahead of the season, so findings can actually be fixed. Testing in November is a report, not a remedy.
- 04
Watch for skimming continuously
Change detection on the payment page, so a modified script raises an alert rather than being found by a customer's bank.
What we actually keep finding here
Not a threat list copied from a report. These are the patterns that recur across our own engagements in this sector, with an honest note on how often. Where we do not have a precise number we say so rather than inventing one.
- Almost every engagement
Scripts on the payment page nobody can account for
Tags from vendors whose contract ended, still loading on checkout. This is precisely how Magecart skimming works, and PCI DSS v4 now requires you to inventory and monitor them.
- Most engagements
Loyalty and voucher logic with no rate limiting
Race conditions on redemption, discount stacking, and enumerable codes. Points are money with weaker controls, and this converts directly into loss.
- Often
Mobile app endpoints the website never calls
Carrying weaker authorisation because nobody expected them to be called directly, and they are trivially discoverable by decompiling the app.
- Most engagements
Testing scheduled too close to peak
An assessment two weeks before the sale produces a list of things you have already decided not to change this year.
Questions worth asking any provider in this sector
Including us. If a provider cannot answer these clearly, that tells you more than any capability slide will. We would rather you asked them than took our word for it.
- 1
Will you inventory every script on our payment page and check for unauthorised change?
- 2
Will you test refunds, loyalty and voucher logic for race conditions and abuse?
- 3
Are the mobile app's API endpoints in scope, separately from the website?
- 4
How far before peak season should we test so findings can actually be fixed?
- 5
We use a payment provider. Can you confirm exactly what remains in our PCI scope?
What we deliver in this sector
- E-commerce & POS system security
- Payment gateway integration review
- Bot, scraping and fraud abuse testing
- Loyalty and wallet platform testing
- Cloud & CDN configuration review
- Third party script and tag audit
- Peak season load and resilience review
- Customer data privacy assessment
Work in this sector
Named engagements where the client has agreed to be named, and anonymised ones where they have not, which is most of them. Named references are available under NDA.
- Client withheld
Marketplace, mobile API exposure
- Scope
- Mobile application endpoints assessed separately from the website, after decompiling the app.
- What we found
- Endpoints the web front end never calls, carrying weaker authorisation because nobody expected direct calls.
- Outcome
- Authorisation unified across channels and the endpoint inventory brought into the release checklist.
- Client withheld
E-commerce platform, pre-peak assessment
- Scope
- Checkout, loyalty and fulfilment tested eight weeks before a major sale so findings could actually be fixed.
- What we found
- Scripts on the payment page from a vendor whose contract had ended, and voucher codes that were enumerable.
- Outcome
- Payment page inventory established with change detection, voucher generation reworked, both live before peak.
- Client withheld
Omnichannel retailer, PCI scope reduction
- Scope
- Card present and e-commerce channels with a flat internal network.
- What we found
- Scope covered most of the estate because nothing was segmented.
- Outcome
- Segmentation designed and tested, moving the assessment from a full Report on Compliance to a materially smaller scope.
Questions we get asked in this sector
Our payment provider handles cards. Are we still in PCI scope?
Yes, and this is the most common misunderstanding in retail. If your page loads the payment form you are responsible for the integrity of that page. PCI DSS v4 made this explicit with the script management requirements. Your scope is smaller, not absent.
When should we test before a big sale?
At least eight weeks out. That gives time to fix what is found and re-test. Testing two weeks before a sale produces a list of things you have already decided not to change.
How do we stop bots without hurting real customers?
Behavioural detection at the inventory and checkout layer rather than a blanket challenge. The aim is to make automation expensive, not to make buying difficult. Any control that measurably hurts conversion will be switched off by the business, so it has to be proportionate to survive.
Do you test mobile apps as well as the website?
Yes, and they routinely differ. Mobile apps often talk to API endpoints the web front end never calls, and those endpoints frequently carry weaker authorisation because nobody expected them to be called directly.
Not sure where to start?
Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.