The Risks of Ex-domain Re-use as an Active Connection to Your Website

The risks of Ex-Domain Re-use and how to protected your website
Share article
twitter linkedin medium facebook

Article updated on June 2022

Have you ever considered what risks a third-party domain opens up for your business? Read on to get an understanding of the key challenges this issue can cause, and how to protect your website data.

Understanding the Risks of Third-party Domains with a Script to Your Website

Today’s websites have a lot of digital components. Businesses rely on third-parties to handle back-end and front-end functionality, to enhance the browsing experience for users, and to access the data necessary to track activity, take payments, integrate with other services, and more. 

To make this happen, the third-parties use scripts. These scripts give them access to your website environment so that they can complete their tasks. The average company might have a large number of remote domains linked to their website, 50+ third-party applications and hundreds of scripts that all communicate with your website using those scripts.  

But what happens when these remote domains expire or become inactive? This means the vendor is no longer in control of these domains, and yet they still have an active connection to your website. If a hacker gains control over the domain, they have an open door to your customer’s data. 

How can ex-domain reuse happen?

In some cases, human error might cause the domain to stay connected to your website, for example if you stop working with a specific vendor, and don’t remove the script. In other cases, a problem like an expired domain might have occurred on the vendor side, and you don’t even realize the connection is no longer to the third-party. In this case, a hacker could buy the expired domain legitimately, and with it – your website environment on a silver platter. 

Either way, if your digital team doesn’t remove the third-party code from your website, there are a number of issues to be aware of: 

Confidentiality and privacy risks: The installed technology is still sending requests to load the script to the remote domain. That’s your customer’s data being sent to a vendor with whom you no longer do business. 

Data leakage: Personal data, cookies, and other confidential information can be sent directly to third-party entities through requests to this remote domain, without the consent of the user. With new privacy regulations like GDPR and CCPA, fines and legal penalties can swiftly follow. 

Keylogging and formjacking: If an attacker has control of the domain, they can replace the genuine script with a malicious one. One example is a script that records the keystrokes made by users, in order to steal credentials and passwords. Magecart is one of the most famous attack groups who use this method.

Phishing attacks: By using a malicious script, hackers can also create false forms on your website, and encourage users to enter their information. This could be anything from financial data to medical information. As this is truly your website, with the correct URL, your visitors are likely to fall for this scam. 

Defacement: In some cases, it might be the plan of the attacker to replace the script in order to destroy your website and therefore impact your brand or reputation. In that case, they will use their newfound access to change the language on the site, or perhaps to promote a political agenda. 

What can I do to avoid the risks of ex-domain re-use?

One of the greatest challenges of this kind of attack is its impact on visibility and shadow IT. Most IT teams simply verify a script and its associated domains when they integrate with a new third-party, and then leave it to run without any oversight or controls. Here are some top tips for approaching this vulnerability for your own website: 

  1. Minimize the number of remote domains: Make sure you only have relationships with third-party domains that you absolutely need, and check their validity at a regular cadence. This isn’t just best-practice, in many cases it’s your compliance mandate.
  2. Host scripts locally where possible: Locally stored scripts will be on your own servers, using your own domains. While these can still communicate with remote domains, this reduces your risk. 
  3. Use a robust CSP: Content Security Policies can limit your risk, blocking unplanned requests on your website pages. However, this will be a heavy manual task, and you’re likely to need additional controls
  4. Consider SRI: Subresource integrity can be used for very sensitive scripts. The way it works is using a cryptographic hash, which the script in question needs to match in order to be allowed to run. 
  5. Onboard a monitoring tool: Continuous monitoring of all third-party scripts is the only way to ensure that all domains are behaving as they should. Reflectiz provides a real-time dashboard of all third-party digital applications, uncovering what data they are accessing, where they are sending it, and any activity that deviates from a pre-set defensive baseline. 

Subscribe to our newsletter

Stay updated with the latest news, articles, and insights from Reflectiz.

Your Website looks great!

But what’s happening behind the scenes?

Discover your website blind spots and vulnerabilities before it’s too late!

Try for free