How to Mitigate Client-side Supply Chain Threats

When users create or log into an account, complete a transaction or submit a form of any kind, they are trusting you with their sensitive personal data. If your site collects credentials, credit card numbers and other personally identifiable information (PII), you are taking responsibility for protecting a piece of your users’ identity. But did you know that using client-side code from third-party libraries can put you at risk of a data breach and potentially make you noncompliant with data privacy regulations?

Third-party Code Leaves You Vulnerable

Writing code takes time and developer resources — and why reinvent the wheel? Third-party code libraries provide out-of-the-box, client-side scripts that enable common functionality such as social sharing buttons, advertising, payment iframes, chatbots and tracking scripts. Even better, these scripts run in users’ browsers rather than on your web server, speeding up load times and improving user experience. It’s no wonder that 70% of the code on an average website is sourced from third-parties, and most of it is JavaScript. A recent survey found that almost 65% of developers have done extensive development work in JavaScript code.

There’s just one problem. Like any code, JavaScript can contain vulnerabilities that open the door to a cyberattack. However, the fact that it runs on the client side means website owners have limited visibility into how JavaScript is behaving in users’ browsers. Code reviews and scans often miss malicious scripts that load dynamically in browsers, leaving developers in the dark on script activity at runtime. This is far from ideal for website owners looking to prevent supply chain attacks and adhere to compliance regulations.

The Risk of Client-side JavaScript

In order for third-party JavaScript to work, it needs access to your site, apps and data. This means granting it permission to access, modify, create and remove (Read more...)