With constant pressure on web application and software development teams to churn out code for new website tools/features, it makes sense to leverage code depositories and JavaScript libraries to expedite the development process. In fact, code depositories, like GitHub, are so important to the web development process, that the vast majority of organizational websites use them. But code depositories and libraries—whether their internal or external—can hide a danger known as shadow code.

In today’s world, businesses, economies, and lives are connected by a complex spider web of code and software applications. This code and these applications drive e-commerce, financial transactions, and data input. They impact our ability to quickly transfer money from one account to another, to fill out an online mortgage application, and to order supplies from a vendor. The code that drives these systems is complicated. If something can go wrong, it will.

What happens when the software, scripts and code snippets that your business uses on your website and network have been compromised at the source? The compromise could be unintentional—perhaps the coders simply made a mistake. Or the compromise could be intentional—maybe hackers wrote a malicious script and promoted it as legitimate on a third-party library source to encourage users to download and install.

CAPTCHA and reCAPTCHA are an ever-present component on any website that requires user interaction. But the risks of embedding CAPTCHA/reCAPTCHA plugins on a website can outweigh the benefits. Flawed code can increase the threat of client-side attacks. Who hasn’t encountered a CAPTCHA?

In my decade working in the cybersecurity industry, I’ve developed quite a few fond memories learning from talented security professionals. In 2015, I found myself working with Andy Pendergast at ThreatConnect. (As a little background, Andy is one of the fine folks who developed the Diamond Model for Intrusion Analysis. He is considered to be a veritable cybersecurity encyclopedia among his peers.) At the time, I was new to cyber threat intelligence (CTI).

​​In a world in which commerce, business, and information are driven almost exclusively by the internet, protecting both consumers and data is critical. Over the past few months I’ve spent a significant amount of time researching front-end and client-side security to understand the pitfalls of the JavaScript programming language and how businesses can protect themselves from JavaScript-based cyber attacks.

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.