It has been reported that analysis of the Alexa top 1000 websites revealed that there is a lack of security controls to prevent customer data theft. The main threat vectors are Magecart attacks, formjacking, cross-site scripting, and credit card skimming aim to exploit the vulnerable JavaScript integrations running on 99% of the world’s top websites.
The fact that sites are pulling in assets from third parties that they might not have vetted is a bigger concern than whether or not they use javascript. Those vendors can be used to display ads, track analytics, improve website functionality, and use third-party website plugins. I think it\’s often the case that website operators don\’t even consider whether some integration uses javascript or not. Javascript is so ubiquitous that many businesses don\’t even factor it in. That can allow malicious javascript to go undetected. I don\’t think javascript is inherently insecure, but it can be used for malicious purposes such as drive-by downloads. We just need to do a better job of vetting assets loaded from third party sources. Javascript is so common that trying to use a web browser without it makes for a significantly less convenient experience. Ideally, browsers would block javascript by default and give users the option to allow it on a site-by-site basis. This can be done with plugins like NoScript but it\’s not the way browsers work by default, because browser makers want to reduce friction and retain users. The average browser user probably doesn\’t understand javascript and, if it was disabled, wouldn\’t know why all of their favorite websites aren\’t working, so they would be more likely to switch to a different, less secure browser.
Opening your platforms to such a large number of third parties will, of course, introduce more risk to your organization – especially in the context of privacy laws like GDPR from the European Union and CCPA out of California. With privacy being the main focus these days, security teams need to properly evaluate the security post of any third-party integrator before giving them access to customer data. On the flip side, integrators understand that they need proper security controls in place if they want to succeed in such a climate. In addition to making sure third-party platforms are secure, you should also make sure your own platforms are as well. Whether it’s the web interface or the mobile app, security has to be built into the customer experience to ensure that the public-facing risk is mitigated.
Like any other programming language, Javascript is as secure as each developer makes it. If the development team is using some of that code to also build part of its mobile app through a framework, it’s even more important to make sure the source code is secure as it will reach a broader range of customers. This whole conversation centers around visibility, and it’s no different during the build process. Building the first line of defense against stolen personal data is the responsibility of the organizations that build the platforms. Organizations can do this by building security into the customer experience while simultaneously securing the back-end infrastructure that supports that customer-facing interface.
While Magecart is a rudimentary tactic, it’s a perfect example of how malicious actors can exploit the assumption consumers have that their experience is secure. This is why they are willing to share so much personal data with healthcare systems, financial institutions, and government bodies over the web.
Balancing security and end-user experience has always been tricky. It’s not so much about locking down what they display, but more about visibility into the potential risk of what’s built. This applies to any web platform, whether it’s accessed through the web or mobile devices, to ensure a safe but enjoyable experience for the user.
Proactive efforts to secure the customer experience on mobile and web as well as comprehensive evaluations of third-party vendors are basic actions organizations should be taking to protect customer data. In addition, in-depth evaluations of guidelines and compliance parameters of GDPR and CCPA should be conducted. This will make sure your security teams understand the risks involved and give the platform developers a better context of why security needs to be part of the build and maintenance processes.
Unfortunately, these findings do not come as much of a surprise. With some estimates suggesting up to 90 percent of an application can consist of third party components, many of which are open-source. This is not an issue that can be fixed easily or quickly without an overhaul in the way applications are developed wholesale. Back in 2016, we saw how one programmer briefly broke the internet by deleting 11 lines of code. Therefore, organisations should consider putting in place tools and procedures that can help them identify and fix any security issues that may be present. This means organisations need to consider all aspects of security through their physical and software supply chain, identifying where vulnerabilities are, and applying the appropriate countermeasures where necessary.
Businesses need to better monitor the code they use, especially that provided by third-party vendors. While using ready-made packages is convenient, it leaves companies and their customers open to being victimised by any security flaws present in the third-party code. JavaScript has a number of security vulnerabilities including Cross-Site Scripting, Server-side JavaScript injection, Cross-Site Request Forgery attacks, and many more. Developers need to make sure they program around these issues, taking advantage of the browser\’s SSL capabilities, using secure cookies, and more. Browsers and websites were not originally developed with security in mind. While both have seen major security improvements over the years, the online user experience is still the major consideration by developers when security should be their main concern.