You wouldn't let a marketing contractor fly an airliner

Digital security firm RiskIQ published a break down of the recent customer data theft from the British Airways website yesterday. The breach used a customised version of the Magecart attack commonly targeted at payment forms.

In short, the attack originated from a modified version of the Modernizr JavaScript library. The attackers had appended some code that used jQuery to set up DOM events on payment form submit buttons. The event handler for these then sent serialised form input values to a domain owned by the attackers using an Ajax POST request.

How could something so blatantly simple get past BA’s security governance?

When news of this breach first broke, I assumed that a third-party tag management system like Google Tag Manager would turn out to be the weak point.

But RiskIQ’s analysis instead implicates an internal CMS capable of deploying assets to the primary BA domain. The compromised script’s URL is of the form

What we don’t know is how the attackers were able to gain access to the CMS.

I’ve worked at large organisations with ‘CMS’ systems similar to this. They are often used as simple static asset management platforms for convenience. This might not be a big problem for images, but it’s a different matter altogether for JavaScript.

Whether you’re using a tag manager or a CMS, the upshot is the same: the convenience of broadening publication access to other teams too often means that security and quality governance practices are circumvented.

Using browser-based features like Content Security Policy and Subresource Integrity could have mitigated the issue, but that’s missing the point if a bad actor has the ability to publish arbitrary static assets on your primary domain.

It should be obvious from breaches like this that JavaScript must be treated as a high-threat vector. For me that means all code changes should be subject to the same publishing authorisation, review practices, automated testing, security monitoring and release gating.

It’s easy to throw mud here. Big companies like BA suffer issues like this because their giant array of systems allow things to fall between the cracks. They are constantly trying to balance the need to allow staff to do day-to-day work with the need to keep bad actors out. Fixing security holes before they become a problem requires the kind of proactive work that enterprises find difficult.

If there’s something about your system that makes you nervous, now’s a good time to talk to a senior manager about it :-)

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.