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. 💪
Top comments (0)