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've made it this far, please share this Security Tip and Securing Laravel with your Laravel friends, colleagues, and enemies! The more folks we have learning about security, the more secure code will be written, and the safer the whole community and our users will be. Also, if you tag me I'll give it a retweet, and you can find all my socials on Pinkary.
