Forem: Sudhanshu Chaubey

Securing Frontend Apps from Lodash Issues

Sudhanshu Chaubey — Sat, 11 Oct 2025 09:23:01 +0000

When working on frontend applications, it’s easy to overlook vulnerabilities hidden inside popular libraries. One common example is Lodash, a widely used JavaScript utility library. Because it’s bundled into many frameworks and dependencies, outdated versions of Lodash can expose your app to security risks such as prototype pollution. Keeping an eye on these vulnerabilities and knowing how to patch them is essential for maintaining a secure frontend.

💡 Note: Our app runs on the Ionic Framework, powered by Angular.

🔍 Which tool is used to detect vulnerabilities?

Our organisation used Purplemet, a security analysis tool designed to scan dependencies and detect known issues. Purplemet works by checking your project’s package versions against public vulnerability databases (like NVD and GitHub Security Advisories).

The best part is that it gives clear insights into:

Which dependencies are affected
The severity of the vulnerability
Recommended fixes or upgrade paths

This makes it much easier to track vulnerabilities early and prevent them from reaching production.

🛠️ What approach I have use to fixed it?

Our frontend application relied heavily on Lodash for data manipulation. To address the vulnerabilities, my approach was to replace Lodash with a custom lodash like utility service.

The challenge, however, was how to build such a utility service quickly without making major code changes and consume less time. Then's what I decided is to leverage AI to generate a Lodash-like utility service that could act as a drop-in replacement.

Of course, there was a catch. The AI-generated utility service wasn’t perfect — it had issues with null handling, data types, and other edge cases. After identifying and fixing these problems, and I was finally able to remove Lodash completely from our application and push the updated code for a security rescan.

❌ Outcomes

The approach I used to fix the vulnerability issues wasn’t fully successful. Even after removing Lodash from our codebase, it was still present in our frontend application.

🤔 So, what did I try next?

🕵️ Back to the Hunt

Since my custom Lodash utility service was working perfectly without any issues, I decided to dig deeper and figure out why Lodash was still showing up, even after I thought I’d completely removed it from our app.

So, I went back to the good old manual search method. After a bit of exploring, I discovered that Lodash was still present inside Angular’s generated folder, i.e., the www directory. Some of the compiled JavaScript files still had Lodash references!

Finding that was a small win — but also the start of a new puzzle.
The real question was: where was Lodash coming from?
The www folder is generated at build time, so it had to be coming from somewhere upstream — likely one of the dependencies.

After some digging, that theory turned out to be correct ✅

To track down which dependency was responsible, I turned to the package.json and package-lock.json files. While package.json contain the lists of main dependencies, it doesn’t give full visibility into nested ones. So, I opened up the package-lock.json, which contains detailed information about dependency chains — and there it was: the culprit dependency still relying on Lodash.

Now that I’d found it, the next question was — what to do next?

⚙️ Two Possible Solutions

1️⃣ Find an alternative dependency

Pros: Faster to implement  
Cons: Might introduce minor new vulnerabilities

2️⃣ Build a custom replacement

Pros: Fully secure — custom-built with no known vulnerabilities  
Cons: Time-consuming and requires extra effort

So, I decided to go with the first option — replacing the affected dependency with a secure alternative. After updating it, I ran a few unit tests to ensure everything worked smoothly with the new setup

✅ Outcomes

On my second attempt, the solution was successful!
All Lodash-related vulnerabilities were completely removed, along with other dependency issues. Even better — the application’s performance improved noticeably after the cleanup. 🚀

🧩 Conclusion

Fixing vulnerabilities isn’t always a straight path — and this experience proved that for me. What started as a simple Lodash cleanup turned into a deep dive through dependencies, build files, and even some AI-assisted coding experiments.

While my first attempt didn’t quite hit the mark — Lodash was still hiding inside the build. But on the second try, after tracking down the root dependency and replacing it properly, everything finally came together. 🎉

The biggest lesson? Every failed attempt brings you closer to truly understanding your system — and helps you build more secure, reliable, and maintainable applications in the long run. 💪

Setup NVM in your organization/admin system's like a pro

Sudhanshu Chaubey — Sat, 07 Dec 2024 11:17:03 +0000

NVM is an incredibly useful tool for developers, and we owe a big thanks to Corey Butler for creating a version of NVM specifically for Windows users, as the original NVM was designed for Linux/Unix systems. This tool allows developers to manage multiple Node.js versions effortlessly. In professional environments, whether you're working in an organization or as a freelancer, it's common to handle multiple projects—each potentially requiring a specific Node.js version. This is where NVM becomes invaluable, simplifying the process of switching between Node.js versions as needed.

After installing NVM on my organization's Windows system, I noticed some key points worth sharing.

This post focuses on Windows users, but you can explore similar setups for Mac or Linux/Unix systems.
From what I’ve observed, these issues are unlikely to occur on Mac or Linux/Unix systems.

After completing the installation, I started using NVM commands like nvm install, nvm ls, and others to manage Node.js versions.

nvm ls
nvm install <node-version>

However, the headache began with the nvm use command, as it requires Admin Access to create a Node.js folder on the organization's system.

nvm use <node-version>

At that point, the nvm use command would throw errors like
exit status 1: Access denied or exit status 5: Access denied.

After extensive research, I discovered how the nvm use command works behind the scenes. In a nutshell, it internally calls the mklink command, which is used to create symbolic links between directories. On both admin and non-admin systems, the mklink command is executed, and the full command looks something like this:

mklink /D nodejs <node-version-folder path>

The command mklink uses the /D option to create symbolic directories, which requires full admin privileges. This is where the issue arises—on non-admin systems, nvm use works fine, but on admin-protected systems with additional security layers, it fails.

In short, this is a drawback of NVM on admin-protected systems: every time you run nvm use, it prompts for admin privileges.

The Solution:
After some research, I found a way to tackle this issue. Instead of using the /D option with mklink, which requires admin rights, you can use the /J option. This creates a symbolic junction between directories and does not need admin privileges. However, it comes with some limitations below are attached images for limitations.

Image from stackoverflow

Let start setup NVM in our Organization/Admin system's

Step 1:

create folder of nvm4w or any name you like in any drive which you have right to read-write or full access. And there are two options

Option 1: Let’s say if you have only one drive i.e. C: or any character drive. And it that C:/Users/<your_name> create folder of nvm4w or any name you like.
Option 2: If you have two or more drive let say C: and D: drive or any character-based drive. Then it better for you to create folder on D: drive i.e. D:/nvm4w or any name you like.

Step 2:

After creating a folder with full control access then download the latest nvm-noinstall.zip file from this link
After downloading done extract zip file and name the folder “nvm” and paste that folder or dir into the folder which you have create from Step 1

Step 3:

One step 2 done then configure environment path for you nvm. Add below path and variable both in user and system variable

NVM_HOME: Drive_name:\<folder_name>\nvm  (i.e. D:\SOFTWARE\nvm4w\nvm)
NVM_SYMLINK: Drive_name:\<folder_name>\nodejs (i.e. D:\SOFTWARE\nvm4w\nodejs)

Click on new button to add above variables name and it value for both user and system variables

And register the above two name into the path both in user and system variables section and save it:

NB: Reset the system which is optional in most case.

Step 4:

Once it done open command prompt and run nvm -v to check whether it is working or not. Now need a final touch in order to make nvm install or ls command work in your system. Create a settings.txt file where your nvm folder reside in nvm4w or any name you have mentioned which you have created from Step 1 and add below contents.

root: Drive_name:\<folder_name>\ nvm4w\nvm  (i.e. D:\SOFTWARE\nvm4w\nvm)
path: Drive_name:\<folder_name>\ nvm4w\nodejs  (i.e. D:\SOFTWARE\nvm4w\nodejs)
arch: 64
proxy: none

Congratulation you have done with your NVM setup fully🎉

Now, you might wonder: "We've set up and configured NVM, but how do we actually use it? The default nvm use command still won’t work without admin privileges. Was all this setup pointless?"

Here’s where the magic happens! I created an alternative mklink command using the /J option to override the default nvm use command.

There are two ways to use this new approach:

Manual Process: Run the mklink command manually each time you want to switch Node.js versions from command prompt.

mklink /J nodejs <your_folder_path>\<node-version>

e.g. mklink /J nodejs D:\SOFTWARE\nvm4w\nvm\v18.20.4

Automated Process: Create a nvm-use.bat script and add below code to automate the task, making it easier to execute from the command line. This ensures you can work with NVM on admin-protected systems without hitting privilege issues. _NB: Put this nvm-use.bat file into nvm4w folder which you have from Step 1.

@echo off
setlocal

:: Set NVM and Nodejs path from environment variables
set myNVMPath=%NVM_HOME%
set myNodeJSPath=%NVM_SYMLINK%

:: Get list of installed nodejs version in nvm directory
echo List of installed nodejs version:
nvm ls

:: Prompt the user for the new nodejs directory path
set /p newVersion="Enter the full version (e.g. 20.15.0) for nodejs: "

if "%newVersion%"=="^C" (
    exit /b 1
)

:: Check if the newVersion is not empty
if "%newVersion%"=="" (
    echo You must enter a version.
    exit /b 1
)

if exist "%myNVMPath%\v%newVersion%\" (
    :: Remove the existing nodejs directory
    echo Removing existing nodejs directory...
    rd /s /q "%myNodeJSPath%"

    :: Create the symbolic link
    echo Creating symbolic link to %newVersion%...
    mklink /j "%myNodeJSPath%" "%myNVMPath%\v%newVersion%"

) else (
    echo "%newVersion%" version does not exist.
    exit /b 1
)

:: Check if the mklink command was successful
if errorlevel 1 (
    echo Failed to create symbolic link.
    exit /b 1
) 

echo Operation completed successfully.
endlocal

Then configure bat file path into environment user variables.

And register NVM4W variable name into path field

After setting up nvm4w path then open command prompt and run nvm-use to check it working or not.

PS: I'm open for questions, information, correction and new thoughts