Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Few programming languages generate the same love-hate relationship as JavaScript. For many websites, JavaScript (JS) is a critical coding component that drives client-side programming. Yet JS is also extremely vulnerable to attack since it is easy for hackers to input query strings into website code to access, steal, or contaminate data. Knowing whether your JavaScript is secure is crucial to maintaining a safe user experience for your clients and customers.

I recently spoke to a Chief Information Security Officer (CISO) who explained that he disliked marketing and saw it as a risk and cost center to his business. He seemed to believe that everything his company’s marketing team did on its website was a risk and even called some standard marketing practices “reckless.” I get it. To those who are unfamiliar with marketing, a lot of what marketers do can seem strange and intimidating.

Imagine it’s December—the biggest sales time of the year. Your e-commerce site is up and running, complete with a robust and diverse inventory for buyers. A few days into the shopping season, you notice an unusually high number of cart abandonments and quite a few customers leaving after viewing a couple of different web pages. You check the web pages. They look fine—in fact, better than fine. (You spent a little extra this year improving the graphic design.) Everyone is stumped.

On November 1st, 2021, a public disclosure of a paper titled Trojan Source: Invisible Vulnerabilities described how malicious actors may employ unicode-based bidirectional control characters to slip malicious source code into an otherwise benign codebase. This attack relies on reviewers confusing the obfuscated malicious source code with comments.

Today, businesses live or die by their digital presence. Crafting the best digital experience means putting the end user first, which requires a delicate balance of technology and innovation. To achieve this balance, businesses make use of third-party code, tools, and cloud services combined with their own technology to drive down time to market. As a result, most modern web applications are a culmination of first-party and third-party technologies delivered from the cloud.

There’s a natural tension within most companies: marketing wants to get stuff out, while IT and security are focused on protecting the business. These waters between marketing and security can be treacherous, and a recent challenge we observed in a large U.S.-based northeastern bank, illustrates the issue well. Like many financial institutions, mobile and web banking are a critical and core component of the business model.

I might assume that you found this blog while conducting research on how to protect your business from skimming breaches. Let me guess… you just survived a Magecart-type, cross-site scripting (XSS), formjacking, skimming, or other client-side attacks? Now your CISO, CEO, or board are asking you to figure out how to ensure this doesn’t happen again?

Welcome back to our five-part series on client-side security approaches. For those of you who are new to this series, there are five approaches to client-side security: In this blog I’m going to cover the use and limitations of vulnerability scanning for client-side security. Let’s start with the absolute basics. First, let’s take a deeper dive into a few key questions.