A Web App Test Would Not Have Stopped Any of These Retail Breaches

ASOS customers got a push notification this morning telling them the company had been hacked. It came through the ASOS app, which is what made it so public. By early afternoon ASOS had confirmed to the London Stock Exchange that there had been "unauthorised activity involving third-party platforms that we use to communicate with customers", that they had restricted access to those notification platforms, and that names and contact details may have been accessed. The share price fell about 10%.

Somewhere in the UK right now, a retailer's security lead is being asked by their board what we are doing about this. The answer that gets reached for is a penetration test. Usually a web app test, usually this quarter, usually scoped before anyone has worked out what the question is.

We sell penetration tests. I would still rather you didn't buy one that way.

Update, 12 October: how they got in

ASOS has since emailed customers with more detail. The attackers got into an employee's account by "impersonating a trusted contact to obtain log in credentials", then used that login to download customer data from a service ASOS hasn't named. The BBC saw a sample of the data before reporting on 8 October: names, home addresses, phone numbers, email addresses, customer numbers, dates of birth, and the searches customers had made on the site. ASOS says no bank details or passwords were taken.

The attackers told the BBC they reached the data through Simon AI, a platform built on Snowflake. That's still only their claim, and Snowflake has said its own platform wasn't breached.

Further down, I wrote that this might be someone with access to one marketing tool and a talent for publicity. It was more than that. One login to one service was enough to reach a detailed profile of potentially millions of customers.

The way in matches M&S and Co-op: a person was talked into giving access, and the storefront had nothing to do with it. The four checks at the end of this post still stand, but the second one needs widening. Don't stop at the platforms that can message your customers. Add every marketing and personalisation tool that holds customer data, then find out who can log in to each one and whether anyone would notice a full export.

What ASOS has confirmed, and what it has not

Worth talking about this now, because by tomorrow these will have blurred together.

ASOS has confirmed that a notification went out through third-party communications tooling, that they cut access to those platforms, and that basic personal data may have been touched. They have said they do not believe card data or passwords were affected. The site and app stayed up throughout.

What ASOS has not confirmed is everything else. The notification itself claimed the attackers had compromised the company's Snowflake instance. That is an attacker's claim, posted to a Telegram channel that was created the same morning and has no history behind it. No samples have been published. Snowflake has said nothing either way. Dan Bird of Horizon3 pointed out to the BBC that the notification system is separate from the data platform, so sending a push does not demonstrate access to anything else.

It might all be true. It might be someone with access to one marketing tool and a talent for publicity. Anyone telling you which, today, is guessing.

That matters for a practical reason. If you scope a piece of security work this week based on a claim that gets retracted next week, you have spent your budget on the wrong thing and you will not get it back.

None of these retail breaches came through the storefront

This is so important to think about before you just request another bog standard web application penetration test. 

At Marks & Spencer, someone phoned an outsourced IT help desk and talked them into resetting credentials. That was the way in. The attackers went on to steal the Active Directory database and deploy ransomware against VMware ESXi. Online orders were off for around seven weeks. M&S's published figures put the direct cost at £131.3m, with a £310m trading impact and operating profit in Fashion, Home and Beauty down 55.4%.

At Co-op, the same approach worked against their own internal service desk. The attacker answered the security questions and got a password reset. Data on all 6.5 million members was copied. The incident cost £285m in revenue and £107m in profit.

Kering lost customer data from Gucci, Balenciaga and Alexander McQueen through a Salesforce instance, reached via an OAuth application that somebody inside the business authorised after a phone call.

Adidas lost customer contact details held by an outsourced customer service provider. Harrods lost 430,000 ecommerce records through an unnamed third party. CEVA Logistics lost availability across eight European warehouses, and their retail customers suspended data exchanges while it was sorted out.

Count how many of those involved a vulnerability in a storefront. None. A web application test scoped at the checkout flow and the account pages would have found exactly none of it, however good the tester was.

The NCSC reached the same conclusion in May 2025 and published specific guidance for retailers off the back of it. The single item they called out was reviewing help desk password reset processes, and specifically how the desk authenticates a member of staff before resetting anything.

Why the reflex is wrong

Panic-buying a pen test after a headline is not really a security decision. It is a procurement decision made under pressure, and it has a predictable shape: you buy the thing you already know how to buy.

Most organisations have bought a web app test before. There is a template, a rough price, a supplier on the list, a slot in the calendar. Buying one again is low friction. Working out whether your outsourced service desk can be talked into an MFA reset is high friction, involves a conversation with a supplier, and does not have a tidy purchase order attached to it.

So the easy thing gets bought and the hard thing stays unexamined. Twelve weeks later there is a report, the findings get fixed, and the actual exposure has not moved.

It is worth being blunt about who benefits from that. We do. A firm that sells you a web app test you did not need still gets paid. This is why you should be suspicious of any provider whose answer to a breach in the news is the service they happen to sell.

Where a web app test genuinely earns its place

I am not arguing the discipline is pointless, and it would be dishonest to pretend the evidence says that.

ASOS had a second, separate incident in July. Attackers used credentials harvested from somewhere else entirely and replayed them against customer accounts. ASOS detected it on 28 July, confirmed it the following day and forced password resets. Their breach notification lists names, addresses, phone numbers, dates of birth and partial card details among the data exposed.

That is a web and API problem, and it is testable. So are gift card balance enumeration, loyalty point transfer between accounts, order lookup endpoints that leak other people's details, and bot abuse on limited release drops. If you sell trainers on a drop model, that last one is probably costing you money already.

The difference is that these are reasons to test, arrived at by looking at your own business. They are not a reaction to somebody else's bad morning.

Four things to check before you raise a purchase order

None of these cost anything.

Ring your own service desk and try to get your password reset. Use a colleague's name if you want it to be a fair test, with their agreement. See how far you get before anyone asks for something an attacker could not produce. Twenty minutes will tell you more than a scoping call. If the desk is outsourced, this is more urgent, not less.

Write down every third party that can send a message to your customers under your brand. Email, SMS, push notifications, in-app. Then find out who holds the API credentials for each one, where those credentials are stored, and whether multi-factor authentication is enforced on the accounts that can log in.

Work out whether you could revoke that access before lunch. ASOS's first action was restricting access to the notification platforms. If you had to do the same thing on a Tuesday morning, would you know how, and who would need to approve it?

Check your admin accounts for passwords set before your last rotation. When Mandiant investigated the 2024 campaign against Snowflake customers, they found the common factors were credentials stolen long beforehand and never changed, no multi-factor authentication, and no network restrictions on who could connect. Nearly 80% of the abused accounts had credentials exposed in earlier breaches. You can audit for that today without knowing who might come for you.

If those four checks come back clean, book the test with our blessing. If they do not, you have just found something more important than anything a storefront scan was going to tell you.

Then buy the right test

Good security work starts with a question you can articulate. "Our board saw a headline" is not one. "We hold card details for two million customers, our service desk is outsourced to a provider in another country, and we have never tested whether they can be talked into a reset" absolutely is.

If you want help working out which question applies to you, we should talk. If the answer turns out to be that you need something we do not sell, we will tell you that too.