What the European Space Agency Attack Teaches Security Leaders About Client-Side Risk

In late 2024, extending into 2025, the European Space Agency was forced to take its online store offline following a Magecart-style attack that compromised customer payment data. The incident was not the result of a traditional breach, stolen credentials, or a failure of perimeter security.

It happened quietly, inside users’ browsers, through malicious JavaScript injected into the ESA site.

For security leaders, that distinction matters.

Following the compromise, an external domain was introduced to load and exfiltrate sensitive data. While that domain represented third-party infrastructure, the underlying issue was broader: there were no effective controls or visibility over what code could execute in users’ browsers, or what that code was able to do once it was running.

This incident is a clear example of a class of risk that many organisations still underestimate: client-side attacks involving third-party code executing on production websites. These attacks don’t require access to your infrastructure and don’t trigger many of the controls security teams rely on today. Yet the organisation remains fully accountable for the outcome.

Why this type of attack is different

Modern websites rely heavily on third-party JavaScript. Analytics, payments, chat tools, A/B testing, marketing services, consent managers — all of them execute directly in users’ browsers. Once running, that code often has access to sensitive data, authenticated sessions, and trusted brand context.

In the ESA incident, malicious JavaScript was used to skim payment card data directly from the checkout page and exfiltrate it to attacker-controlled infrastructure. There was no need to breach backend systems. The damage was done entirely on the client side.

From a governance and risk perspective, this creates a problem. Traditional security controls are largely focused on servers, networks, and infrastructure. Client-side behaviour often falls between the cracks, even though it has direct access to customer data and business-critical processes.

For readers who want a deeper technical breakdown of how the attack worked and how it could have been detected earlier, our founder, Scott Helme, has published a detailed analysis here.

The accountability gap

A common misconception is that third-party code shifts responsibility elsewhere. It doesn’t. Regulators, customers, and boards hold organisations accountable for data exposure regardless of where the failure originated.

That’s what makes incidents like this particularly uncomfortable for CISOs and Heads of Security. Many organisations can’t confidently answer basic questions such as:

• What third-party code is running on our sites today
• When that code changes, how do we know
• Whether a change represents normal behaviour or malicious activity
• Where sensitive data is being sent from the browser

Without that visibility, organisations are effectively carrying unquantified risk.

Why this matters beyond compliance

Client-side attacks are often first addressed through compliance requirements such as PCI DSS. For many organisations, that’s where attention begins — and ends. But the underlying risk doesn’t disappear once a box is ticked.

The attack surface remains, and attackers continue to exploit it because it is effective, difficult to detect, and often poorly monitored. The ESA incident is a reminder that this is not a niche or theoretical problem. It affects high-profile, well-resourced organisations with mature security teams.

The difference between those that detect these issues early and those that don’t often comes down to visibility, not intent or effort.

The decision security leaders need to make

The question isn’t whether third-party code should be used. It’s whether you have continuous visibility into what’s executing in users’ browsers and how that behaviour changes over time.

Security leaders who treat the browser as part of their attack surface, rather than a blind spot, are far better positioned to reduce risk, respond quickly to incidents, and have credible conversations with regulators and boards when things go wrong.

If you can’t see what’s running in your users’ browsers, you can’t fully understand the risk your organisation is carrying.