Matthew Gast
By Matthew Gast
Posted On October 11, 2018

Defending Against Magecart with CSP

Content Security Policy | Data Breach


The current trendy attack against retailers is the use of scripts to skim credit card information, best known as a series of attacks by the Magecart group (believed to be behind the British Airways and Newegg breaches). This begs the question of why retail is so bad at application security, and what can be done to defend against this type of breach.

How can you defend against these attacks? HTTP’s Content Security Policy is a flexible tool that enables application administrators to control what browsers are allowed to connect to while using the application.

In brief, a Magecart-style attack works by inserting a script into the victim’s site, whether by compromising a third-party component (as in the Ticketmaster breach), or by compromising the code for the victim’s site itself. Once loaded and executed, a script can take any information off the page, including a component frame, and send data to a server controlled by the attacker. The flow looks something like this:

  1. Breach either a victim’s web site or a third-party they depend on. Don’t actually exploit the vulnerability yet, just know that there’s a victim in waiting.
  2. Set up the infrastructure to collect compromised data: register a domain and set up a server. This is shown in the picture below as, a newly registered domain where our attackers can set up a server to receive skimmed data. In practice, attackers will try to set up a domain that looks “normal” - even though they had no affiliation with Newegg, they registered the innocent-looking
  3. Insert a malicious script into the relevant page, either by exploiting a vulnerability in the web server or a third-party component. Now the attack begins, and the script takes data from the payment page, and sends the skimmed data to


CSP interrupts the attack when the skimmed data is communicated. In theory, it would be possible to work to defeat the attack at either of the previous steps, but it’s safe to assume that most security departments already expend maximum effort defending their web site (step 1) and that security departments have no special knowledge of what domain registrars do (step 2).

What can be done in an application is prevent the skimmer script from reporting data, which is done by setting a Content Security Policy on the web application to control where it is allowed to connec. A CSP can be set to allow connections only to known sites that you control (or, in the case of third-party components such as chat scripts, purchase services from). For example, if you saw your web page trying to send data to, you would probably be suspicious and disallow that.


It is not enough to set up a CSP policy. Applications are dynamic, and developers can add new web site components. As part of its browser security components, tCell includes a managed CSP solution that automatically inserts a Content Security Policy header and then collects reports from browsers to assist with configuring the right policy.

Browsers send CSP reports indicating when the web application tries to connect to servers outside the configured policy. Here is a screenshot from our demo system, showing a demo web application that is trying to connect to,, and 

tCell Application Security


So, as a security administrator, you start from knowing what the application is trying to do. In most cases, you know if you’re using Google Ads or APIs, and would add those domains into the CSP configuration. When new domains pop up, they’ll be listed with a reputation score. The reputation score can tell you quite a lot about whether a domain is part of an attack because it aggregates various signals of trust into one score. (See this list of reputation services.)

For example, let’s consider the collection domain used in the Newegg attack, It’s clearly meant to evoke something trustworthy for the site administrators, and to be added to filtering rules somewhere without much thought. (It’s easy to imagine somebody at a security console saying “I guess we might have registered (our-domain) …”) Reputation services guard against this level of complacency by quantifying risk.

Rather than just seeing the newly registered domain’s name, a reputation score will take into account other factors, like:

  • Newly registered domains are more suspicious because it is unclear how they are being used
  • Less used domains are more suspicious
  • Domain-validated certificates are more suspicious than extended-validation certificates because there is less robust checking

If we look at the domain in the Brightcloud reputation service, it’s shown as high risk because it’s a newly registered domain with low popularity that has hosted one attack.

So, there you have it. To protect against skimming attacks, enable CSP, look through CSP reports to see where the application is connecting to, and use reputation services to understand whether those sites are risky.