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...
#1 → Exposed API Keys & Passwords
#2 → Missing Authorisation
#3 → Missing Content Security Policy (CSP)
#4 → Missing Security Headers
#5 → Insecure Function Use
#6 → Outdated & Vulnerable Dependencies
#7 → Cross-Site Scripting (XSS)
#8 → Insufficient Rate Limiting
#9 → Missing Subresource Integrity (SRI)
#10 → Insufficient Input Validation & Mass-Assignment Vulnerabilities
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
If you found this security tip useful, subscribe to get weekly Security Tips straight to your inbox. Upgrade to a premium subscription for exclusive monthly In Depth articles, or drop a coin in the tip jar to show your support.
When was the last time you had a penetration test? Book a Laravel Security Audit and Penetration Test, or a budget-friendly Security Review!
You can also connect with me on Bluesky, or other socials, and check out Practical Laravel Security, my interactive course designed to boost your Laravel security skills.
