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.

A web developer’s ultimate goal is to not only develop a website or an app that is aesthetically and functionally stunning but highly secure as well. Cybersecurity is inevitable and no end-user would want to have an app that could breach or compromise their data security and integrity (no matter how useful the app is). With hackers and middlemen working on creative ways to explore vulnerabilities, it is on developers like us to take charge and be a step ahead of them.

Writing secure code in a way that prevents code injection might seem like an ordinary task, but there are many pitfalls along the way. For example, the fact that you (a developer) follow best security practices doesn’t mean that others are doing the same. You’re likely using open source packages in your application. How do you know if those were developed securely? What if insecure code like eval() exists there? Let’s dive into it.

JavaScript is a very useful programming language. Netscape developers invented JavaScript in 1995, and it revolutionized the web. Before JavaScript, webpages could pretty much only contain text, images, and hyperlinks. JavaScript empowered web developers to make webpages interactive, dynamic rather than static. Think of picture menus that animated when your mouse cursor went over it, and applets that could give you your local weather forecast or tell you which web browser you’re using.

Manipulating data is a core skill for any developer. In an API-driven environment, so much of the data you receive is formatted in a way that doesn't directly match the way that your application or UI needs it. Each web service and third-party API is different. This is where the ability to sort, normalize, filter, and manipulate the shape of data comes in. In this article, we'll explore some common ways to work with data in Javascript.