5 Reasons Why a Content Security Policy (CSP) is Becoming Redundant
- Ohad Greenshpan
- February 21, 2019
- 8 min read
Online retailers today are striving to create an optimized customer journey. This starts from building an online brand and bringing in traffic, to fine-tuning the user experience from search all the way to checkout, while polishing all customer retention activities. The limitless options available to consumers today keep retailers on their toes in their efforts to stay ahead constantly evolving expectations.
Moreover, developing a successful online sales funnel while ensuring user security and privacy is at the top of retailers’ minds. Amongst the variety of solutions in the market, a relatively small number of companies opt to use a Content Security Policy (CSP). This methodology, however, has several inherent limitations.
For online businesses, it’s important to understand precisely why a CSP fails to prevent the growing problem of Customer Journey Hijacking caused by client-side injection. But before we dive into the CSP’s shortcomings, it’s important to understand how this security standard works.
Content Security Policy In a Nutshell
A Content Security Policy (CSP) is a security standard introduced to prevent Cross-Site Scripting (XSS) and other code injection attacks driven by malicious content being executed in a trusted web page context.
At least in theory, when a CSP is implemented in whitelist mode, only scripts originating from a verified domain will be allowed to execute, with all other scripts being blocked. However, the limited capabilities of CSPs effectively render them incapable of serving as the last line of defense for modern eCommerce websites.
Let’s take a step back and explain the main use case of CSPs: preventing XSS attacks. XSS allows malicious scripts to run on your site and open up your entire domain to attack. CSPs combat these scripts using the “Same-Origin Policy”. Adding a CSP to your site can potentially protect your customers from XSS attacks and from being hijacked with malware while visiting your site.
But in reality, many parameters need to be aligned perfectly for CSP to work as intended. As we’ll break down later in this article, this is rarely the case in today’s eCommerce space.
5 Main Limitations Identified with a CSP:
As mentioned earlier, while a CSP is designed to prevent certain issues, it’s not a comprehensive solution for rapidly evolving challenges and problems such as Customer Journey Hijacking (Client-Side Injections). In fact, as of May 2018 only around 2.5% of the top 1M websites (according to Alexa) have implemented a CSP, largely due to the following inherited limitations.
1. Challenges Adapting to a Dynamic Environment and Overhead on Resources
Since CSPs work by whitelisting domains, the website operator needs to be aware of every single domain from which images, scripts, iframes, and other elements are being pulled and loaded onto the website. This is not an easy task since most websites today are running dozens of third-party services and working in a dynamic environment (ongoing changes, third-party services which in turn also calling upon other external services, etc.).
Today’s cloud-based third-party services are often updated every few days or weeks. Elements that aren’t whitelisted by the CSP get blocked automatically, raising the risk of undetectable broken functionality. Therefore, implementing a CSP requires additional resources and efforts to monitor every new change impacting your site. Liaising with every third-party service to collect and maintain whitelists adds significant overhead.
Typical websites today contain an average of 75 3rd-party services
2. Lack of Browser Compatibility
Not all web browsers are created equal. eCommerce users today are using Apple, Windows and Linux machines (with different operating systems) with various configurations. On the software front, they have the option of choosing between a wide variety of web browsers, which creates countless setup variations that need to be protected.
Unfortunately, CSP is not supported equally by all browsers, resulting in issues that can either render the CSP useless, or even impact the functionality of the website to various extents.
For more info on browser compatibility, click here
Considering the wide range of desktop and mobile browser versions used today, a CSP does not provide full protection coverage for websites. This means that users using any of these browser types or versions will be at risk of being hit by client-side injections.
3. Error-Prone Manual Processes
Every CSP consists of a set of directives which tell the web browsers of your visitors how to control specific resources in your website. There is also a disposition which tells web browsers whether to enforce the CSP or not. However, these variables need to be configured properly for the CSP to work without hindering the user experience.
Unfortunately, like any processes that are done manually, there is always a risk of human error. This greatly compromises the CSP from a security standpoint. To make matters worse, inaccurate CSP deployment can lead to performance issues and disable crucial parts of the customer journey, which can also have a negative impact on your business metrics.
4 – Limited Client Side Coverage: Add-Ons and Extensions
Browser extensions are installed on the client’s machine and communicate on the browser level. In many cases these extensions and add-ons inject code and HTML elements directly on the client-side, fully bypassing the CSP. These add-ons and extensions can run and inject code into the webpage, while making changes to the browser, DOM, and more.
Example of an unauthorized ad injected by a web extension, bypassing the Content Security Policy
5. Limited Client-Side Coverage: Elements and Code with no Domains
The ability of a CSP to block HTML elements (e.g. div/span elements) that are injected becomes more limited when the code or elements do not reference a domain. Namogoo has recently identified a significant increase in such ‘domain-less’ elements or code snippets that are injected dynamically via malicious software on the customers’ devices — and not blocked by CSPs as a result.
Customer Journey Hijacking: Exploiting Poor Client-Side Coverage
Creating an optimal user experience for customers is not the only responsibility that eCommerce businesses bear today. Client-side injection adds a major factor that often goes unseen while planning the modern user’s online journey — how the users are actually experiencing your site. This often-neglected aspect is the very opening that malicious third parties prey upon for their own benefit.
Customer Journey Hijacking is a rapidly growing client-side phenomenon where unauthorized ads are injected into consumers’ browsers. These unsanctioned promotions and diverts are injected via digital malware that infects browsers and devices when users install software add-ons or program updates, or in other cases, when they connect to public WiFi networks.
Once the digital malware is up and running on the web browser or device, online consumers are interrupted by injected product ads, pop-ups, banners, and in-text redirects while browsing eCommerce sites. Because the malware resides on the user’s browser or device, server-side security solutions — including CSPs — lack visibility or control over the problem.
As per a recent Google report, ad injections impact tens of millions of users globally, and have been cited as the single largest source of frustration amongst Chrome users.
Namogoo’s Customer Hijacking Prevention analyzes hundreds of millions of web sessions on a weekly basis. Here are some key statistics to put the scale and impact of Customer Journey Hijacking into perspective for online retailers:
- 15-25% of all user web sessions are exposed to unauthorized ads throughout the year
- 40-70% of these injected ads feature competitor products or promotions
- Hijackings multiply around peak shopping events such as Black Friday and Cyber Monday, infecting up to 30% of all website visitors.
- Journey Hijacking is costing eCommerce business across verticals up to 5% in annual revenue
Customer Hijacking Prevention: Unique Client-Side Protection of the Online Customer Journey
Namogoo’s Customer Hijacking Prevention solution is based on proprietary machine-learning technology that analyzes billions of web sessions from the server, all the way to the customer’s web browser.
Namogoo’s engine differentiates between legitimate and malicious patterns that negatively impact the intended user experience. Namogoo is autonomous and does not require any human involvement whatsoever – its classifiers are proactive, and collect the data they need in order to reach a decision – translating to immediate action.
Ecommerce executives from leading brands like sports apparel and shoe manufacturer ASICS have already become aware of the devastating impact Customer Journey Hijacking has on their revenue. Nearly 12% of all ASICS web sessions were hijacked in 2017 alone. Virtually all — 98% — of these unauthorized ads led to competitors selling similar products. In other words, ASICS was bleeding revenue and its rivals were directly benefiting from it.
“It’s completely invisible to online retailers like us because these unauthorized ads are only visible on the consumer’s browser,” said Jason LeBoeuf, who was ASICS’ Director of eCommerce at the time of the solution’s deployment.
Brands preventing client-side injections with Namogoo’s Customer Hijacking Prevention solution are reporting annual digital revenue growth of up to 5%. With Namogoo’s client-side platform, it’s now possible to gain enhanced visibility into hijacked sessions and make optimal use of analytics data.
Tackling Customer Journey Hijacking Proactively
To summarize, while a CSP can be useful in specific use cases, and there are instances where it can prevent code injections, it is not capable of preventing Customer Journey Hijacking.
Online retailers looking to protect their customer journeys and provide a distraction-free user experience need to apply a proactive client-side solution that can work in tandem with analytics software, possibly with a CSP as a supplementary solution for monitoring purposes. Either way, the days of the CSP as a standalone client-side security tool are long gone.