Team of programmers writing software code showing use of third-party scripts

Can Third-Party Scripts Be Labeled Safe or Unsafe?

With client-side security and JavaScript-related attacks staring us in the face these days, a probable question that many business owners or developers may ask is, “Can I truly determine if a third-party script is secure or not?” The answer is a bit complicated – and very contextual.

When developers start to cobble together different services and variations of items on their websites and web applications, it’s clear that scripts that were not initially malicious can become malicious with the correct (or, in this case, unfortunate) set of combinations. This makes looking at individual scripts far less effective because you’re not seeing the bigger picture.

Instead of looking through a pinhole, you need a comprehensive approach to reviewing your website’s security posture. That said, comprehensiveness cannot be a replacement for frequency. Visibility into what client-facing assets you have and what they are doing is vital. And it can’t be a one-time effort. A combination of consistent visibility and deep insight is a true must.

Additionally, online businesses need to ask themselves if they have enough resources to mitigate any issues that they find during their frequent looks into their scripts. In other words, visibility is great, but it must be supported by an always-ready plan that consists of in-house or outside remediation talent as well as pre-planned steps to take to keep the doors open and revenue flowing.

Artificial intelligence and machine learning can be employed to collect and even categorize data, enabling an organization’s IT security personnel to determine the best actions to take – and when to take them. This way, if data has been exposed on the front end, it can automatically generate an alert and provide the information that’s needed to rectify the issue.

Putting aside any of those actual tools used to review your client-side security posture, it’s foundationally important to take an approach that replicates actual user journeys. Simply put, if an organization limits their visibility by simply testing and scanning client-side web applications, they’re looking at their assets through a prism that’s almost certainly making inaccurate assumptions.

Instead, duplicating the actual actions of users to see real-life results is of the utmost importance. Just as employers don’t typically hire employees based on multiple choice questions, they instead prefer interviews that paint a fuller, truer picture of someone’s knowledge and way of thinking.

Thus, user activity replication is the most productive path toward best understanding your client-side security posture.

Unfortunately, the result of such a comprehensive look can be the discovery of a significant breach that’s rooted in third-party scripts. And in some cases, that finding is accompanied by a horrendous decision that must be made. Can your business continue on as usual, or must you make the frightening announcement that it’s better to tell customers to temporarily stop using you instead of continuing to use something that is unsecure.

It’s clear that one will never really know from the onset if a third-party script is “secure” – and it may take ongoing, deep looks to uncover potential trouble. The key is to keep that visibility consistent and constant.

 

Co-Founder and Chief Technology Officer at Feroot Security