Security Tip: Replace Simple Dependencies

[Tip#45] The more dependencies your project has, the higher your risk of supply-chain attack is, and the less you're aware of what code is actually running...

Greetings friends! This week we’re on #6 in my list of Top 10 security issues I’ve found during audits: Outdated & Vulnerable Dependencies! Since I’ve covered this topic a few times, today’s tip will be on a related topic: replace simple dependencies with in-house versions. As per usual, I’ll link to my previous articles on this topic at the end.

Here’s our current Top 10:
#10 → Insufficient Input Validation
#9 → Missing Subresource Integrity (SRI)
#8 → Insufficient Rate Limiting
#7 → Cross-Site Scripting (XSS)
#6 → Outdated & Vulnerable Dependencies

🛡️ Worried about the security of your Laravel app? Book a security audit now to identify and fix any vulnerabilities in your code! 🕵️

Looking to learn more?
⏩ Security Tip #30: Finding Secrets
▶️ In Depth #11: Insecure Direct Object References (IDOR)

---

---

Replace Simple Dependencies

Given the huge dependence on frameworks and shared components, supply-chain attacks are a real risk to modern web applications. Laravel alone pulls in a significant number of packages by default, and then we add in our own packages for different features, they pull in even more… those numbers very quickly add up. Not to mention the sheer multitude of packages required in the JS world… 😱

It becomes harder and harder to keep track of all of the packages in your app, and then something like the recent Packagist.org maintainer account takeover occurs, and you find yourself with a package that has been compromised and injected with some malicious code

¹

.

A common “solution” you’ll hear from infosec folks is to “review all dependencies before using them”, but this is completely useless advice. No one has time to review every dependency they use!

Instead, I recommend you replace simple dependencies with your own in-house versions.

I’m talking about Laravel-specific wrappers around other packages (there are a multitude of these), or middleware helpers, blade components, JS helpers, etc. So many of these packages really only contain one or two actual classes, and then often pull in other dependencies. By replacing them with your own in-house code, you’re eliminating at least one dependency (and often a lot more) that could be compromised and injected with malware.

Even things like vendor SDKs can be easily replaced - if the API is simple and/or you’re only using a subset of the endpoints, you may find that ripping out the vendor SDK and using Laravel’s HTTP Client does everything you need, without the bloated and clunky vendor SDK

²

.

So go take a look at your `composer.json` and `package.js` and see what you can remove. 🧐

More About Vulnerable & Outdated Dependencies

• Security Tip: Keep Dependencies Updated

• OWASP Top 10 → #6 - Vulnerable and Outdated Components

• Security Tip: Composer Audit

1. To be fair, the person responsible for the recent account takeover was just looking for a job, but not everyone has such benign intentions...

2. This is especially true when the vendor isn’t a PHP shop, and their code is complete rubbish. I’ve done this a few times, and the features of Laravel’s HTTP Client won me over completely. It’s surprisingly powerful and makes working with APIs really easy!