"Quick note before we dive in: You might notice things look different around here. After a hiatus, I'm back to publishing with a sharper focus, rebranding from the JSdiaries to Frontend Firewall.

It's the same passion for frontend, but now through a security/fullstack lens: tooling, supply chain risks, agentic UI, and protecting what we build. (I'll still cover cool stuff like MCP UI along the way). Appreciate everyone who's been following this journey so far"

Security from a Frontend perspective

I’ve been lucky to work as a software engineer for past decade. For those first 5 years, I’ve focused primary on the frontend. I’ve leaned into full stack in recently but I still primarily view things through a frontend lens.

With doom and gloom consuming a lot of the frontend space (a recent Tailwind story comes to mind!) - I’ve had to reassess what aspects of the role are worth doubling down on.

Thankfully, I’ve been exposed to a lot of the security space in my full time job (Cloudsmith). Tracking the lifecycle of our precious NPM dependencies has really opened my eyes to how vulnerable libraries in our projects truly are.

With that in mind, I want to go over why I’m pivoting to a more security focused view of the frontend role and why I think it’s beneficial to frontend developers career.

Why this, why now?

When I talk about security in the frontend, I’m not exactly talking about cross-site scripting (XSS), session hijacking, unsantized inputs etc. While these are important security fundamentals, security issues are cropping up more generally in a frontend developers workflow.

This could be in:

• NPM packages we pull in
• Visual studio code extensions we install
• CI/CD deployment flows we use
• AI and flavor of the month agentic tools that we use

That list is only a snapshot of vulnerable areas. In a way, it feels like the walls are closing in on us in relation to attack vectors across the whole lifecycle of frontend code.

I want to zone in on a couple of specific incidents that should really highlight how close to home security incidents are becoming for the frontend.

Critical Security Vulnerability in React Server Components

This incident was perhaps unavoidable for any modern FE developer. We most likely all deal with the server app pattern in our projects - whether that’s in Nextjs or otherwise.

The ability to call a server function from the client is a novel piece of functionality, however, if a potential attacker is unauthenticated, they were still able to achieve remote code execution - which is exactly what happened here.

The knock on effect to other frameworks increased the likelihood of your project being affected.

These included:

• Nextjs
• React Router
• React Native

The industry pivot towards the app router pattern increased the complexity of the frontend domain but it also widened the surface area of frontend vulnerabilities. It’s something I’ve taken for granted with new innovations in our space.

NPM supply chain attack (Shai-Hulud)

Perhaps the most significant NPM attack in years, the Shai-Hulud malware attack really made the world take notice.

Essentially, billions of weekly downloads on NPM were at risk because of a malware injection due to a compromised NPM author due to a successful phishing email.

This was such a wide surface area that it should have been absolutely catastrophic, however, the malware targeted crypto wallets and didn’t seem to come away with a massive haul.

Regardless, this left a lot of organization and developers reflect on what dependencies are being pulled into their projects and why.

But take a look at some of these dependencies that were affected:

• chalk@5.6.1
• debug@4.4.2
• ansi-styles@6.2.2

As a frontend developer, these names should seem familiar as they commonly feature in the package.json files of many project.

But they don’t have to be just referenced there, one of your dependencies could just reference any of the above packages as their sub dependencies and your project would be at risk.

This is when it started to unravel for me the endless loop of dependencies pulling sub dependencies really affects a developer’s visibility.

Unfortunately, this was only phase one of the Shai-Hulud wave of attacks. I will cover the subsequent waves in later posts as they were even more sophisticated with a wider impact (Shai-Hulud 2.0).

Visual Studio Code Compromises

I’m also concerned that threat actors are weaponizing the Visual Studio Code (VSC) extension ecosystem.

This is especially egregious as malware has been published via the ESlint Prettier config linting extension, which incredibly common to be installed within a dev’s workspace.

And there seems to be a playbook for malicious actors to create fake Prettier extensions as another entry point for vulnerabilities.

Many developers (including myself at times) would rarely give second thought to installing a VSC extension. The assumption being that the marketplace is curated and there is good quality control. But assumptions like these create the right environment for these incidents to happen.

It’s why I want to learn more about preventive measures and best practices, especially as it relates to frontend tools and deployments.

There has been such a wide ecosystem being created by NPM and with it, so many dependencies being pulled into our frontend projects. A more critical eye is required to avoid security headaches.

I will be leaning into the security side of the frontend, but will continue to cover other interesting topics too. If that interests you, please follow me for more!