Security spend for eCommerce companies grows year on year, and according to data researched by BigCommerce, 77% of businesses bought new security tools in the last year, and 69% have added security headcount to their teams.
However, is this security being targeted in the right direction? In particular – how much attention do you put on the client-side, rather than the server-side?
What is the client-side?
The client-side refers to anything that happens on the end-user’s side, including what your shoppers and visitors see when they open up your website. Client-side applications use custom HTML, CSS, and JavaScript code, and often work without the oversight of an eCommerce business’ security teams, and without controls from their security tools and technologies.
You might ask, why do we allow third-party applications to run on our websites in the first place? The truth is, that today’s businesses can’t run without the use of third-party digital apps. Common use cases are tracking and analytics tags, social media widgets, payment processing, advertising banners, and more. When the visitor enters your website environment, these digital apps often look like any other part of your website and are indistinguishable from the elements that are within your control.
As digital applications generally function outside of your security environment, they aren’t monitored by Web Application Firewalls or DAST solutions, and they can be modified continuously and dynamically. Great for business continuity. However, if there is a vulnerability with one of these third-party applications, this provides an open door into your environment, and to your customer’s most sensitive data, from financial details to passwords, personal information, and more.
How common are these kinds of attacks?
Client-side risks are leading to an increasing number of cyberattacks and data breaches. In fact, the risk is great enough that the OWASP foundation is releasing a new top 10 cyber risks this year, specifically dedicated to client-side risks. In addition, PCI-DSS have included new regulations for implementing a “change and tamper detection mechanism” on payment pages, specifically to inhibit this kind of attack.
One of the most prevalent attacks that use third-party application vulnerabilities is web skimming, also known as Magecart attacks. One Magecart attack recently hit more than 350 eCommerce stores with malware in a single day, through a vulnerability in the QuickView plugin, a tool meant to make it easier for shoppers to see product information at a glance.
Another example is Gocgle campaign, impersonating Google web products such as Google Analytics and Google Tag Manager to steal credentials from shoppers. 4 out of 5 websites use Google Analytics, giving the attack huge potential for harm. By working from malicious remote domains with very similar domain names to the real analytics product, hackers then obfuscated this with a base64 encoding. This makes it less likely that the attackers would be spotted, either by manual reviews or with static code analysis. As this attack happened totally on the client-side, there’s almost no way for security tools to pick up on it until it’s too late.
How are businesses addressing the threat of the client-side?
There are a number of partial solutions that businesses are incorporating to solve the problem of client-side risk.
One of the most common is to implement a Content Security Policy header. This is a web security standard where you implement an HTTP header to the webpage to control what resources your visitor is able to load. The main issue with this approach is that it involves a lot of manual work to create the right policies for the pages in question. Additionally, you need to trust your third-party applications and allow visitors to load information and dynamic media from their sources. If the “trusted” domain is in the hands of an attacker thanks to an unknown vulnerability – this whitelisted domain can inject a malicious script, and a CSP would let it walk right in.
Today’s businesses need to think hard about how to gain greater visibility and control over their third-party applications, to stay secure against web skimming and other client-side risks, as well as to remain on top of compliance regulations. Ask yourself:
Do you know which third- (and even fourth-) party applications are running on your website?
Can you see what behaviors of them are violating your compliance needs?
Are you tracking what data your third-party scripts collect, and where that data is being sent?
If the answer to any of these is no – it’s time to implement a change.
