Six months after the British Airways disclosure in September 2018, the Magecart pattern has continued to develop in directions that the customer-organisation defensive programmes are only partially keeping up with. The cluster — which research groups including RiskIQ and Group-IB have, by this spring, segmented into at least seven distinct subgroups operating with overlapping techniques but separate infrastructure — has expanded the targeting scope, refined the technical approach, and produced a sustained drumbeat of disclosures through Q1 (RiskIQ Magecart taxonomy report, December 2018 and ongoing tracking through 2019). I want to write up where the pattern is now and what the customer-organisation defensive programmes need to be doing this year that they are not.
The cluster's technical evolution. The original Magecart pattern from 2015-2016 was direct script injection into the e-commerce site's checkout flow — the attacker compromises the site's web server and modifies the checkout pages to include the skimming script. The 2018 evolution moved the attack upstream to the third-party-script supply chain — the attacker compromises a vendor whose script the e-commerce site loads, and the modified script is served to all of that vendor's customer e-commerce sites simultaneously. The British Airways case was the most prominent example of the supply-chain variant. The 2019 evolution has gone further upstream still: in several recent cases, the attacker has compromised the cloud infrastructure (S3 bucket, CDN configuration) on which the third-party scripts are hosted, allowing the modification to propagate without requiring direct compromise of the third-party vendor's primary infrastructure. The S3-bucket variant in particular has been documented across a number of cases (RiskIQ blog post on Magecart cloud-bucket compromises), where the third-party-script vendor has misconfigured an S3 bucket as world-writable and the attacker has modified the script directly in the bucket without needing any other compromise.
The targeting has also evolved. The early Magecart cases were predominantly against high-traffic e-commerce sites with substantial transaction volume — a pattern designed for maximum take per compromise. The 2019 pattern is more diversified — small e-commerce sites, ticketing systems, charity donation pages, and various other payment-receiving web flows are now being targeted alongside the larger e-commerce population. The economics have changed: where the early cases targeted volume, the current cases target ease of compromise. Many small-site Magecart compromises are tractable for the operators because the small sites' security maturity is, on average, low, and the per-compromise take is acceptable in aggregate even if any individual site's transaction volume is modest.
The defensive techniques have, in 2019, partial customer-side adoption. Subresource Integrity is implementable but is operationally awkward when third-party scripts update frequently — the customer organisation has to maintain hash currency in coordination with the third-party vendor's release cadence. Content Security Policy is being more widely adopted, but the restrictive CSP postures that would prevent Magecart-style exfiltration are not yet the default and require careful tuning to avoid breaking legitimate functionality. Server-side checkout architectures (where the payment-card data is collected through a server-rendered form path with the customer-organisation's own infrastructure rather than through browser-side JavaScript collection) are the most defensive but are operationally substantial to implement and require architectural change rather than configuration change. The various commercial offerings in the "client-side application security" space — services like PerimeterX, Tala Security, Akamai's Page Integrity Manager — are gaining customer adoption but are not yet at majority deployment across e-commerce sites of any scale.
For the customer portfolio, the retailer (added October 2017) has been the most exposed to this pattern and has been investing in client-side defence consistently through 2018 and into 2019. The current posture includes SRI on critical scripts, restrictive CSP on the checkout flow, and a planned Q3 architectural change to a server-side checkout posture for the payment step specifically. The pen-testing engagements have included client-side application security as a standard scope item for over a year now; the share of engagements that produce actionable findings in this category has been roughly fifty per cent, which suggests that the broader market is still substantially under-protected.
The wider strategic point is that the third-party-script trust model on the consumer-internet web is not, in 2019, structurally adequate to the threat. Every page in the average e-commerce site loads scripts from many third-party vendors — analytics, customer-engagement, A/B testing, advertising — and each of those vendors is a potential supply-chain entry point for a Magecart-style compromise. The customer organisation's defensive posture has to assume that any of those vendors may, at some point, be compromised, and architecturally protect against the consequences. The defence is not a configuration change; it is an architectural posture. The customer organisations that take this seriously will be in better shape; those that treat it as a tick-box item will produce next year's headline disclosures.
I will write more on this through Q2 as the customer-engagement work develops.