PHP at Scale #12
Welcome to the twelfth edition of PHP at Scale. I am diving deep into the principles, best practices and practical lessons learned from scaling PHP projects — not only performance-wise but also code quality and maintainability.
This month, I would like to focus on security. In recent weeks, I have seen major negligence in this area in a couple of projects.
Before I jump into the security-related articles, there are two news that I believe should be shared here.
Compile-time generics: yay or nay?
Quite often, when I discuss modern PHP with other developers, the question of whether we already have generics comes up. Even PHP devs bring it up to show what is missing in our beloved language ;). Thankfully, due to the existence of the PHP Foundation, we have developers working full-time (and earning a living) on improving PHP. A stable team allows some members to focus on important but complicated topics (like generics) for a longer time. If you would like to contribute to this topic, a discussion is available on Reddit.
Fascinating small improvement in PHP, that might make some code flows easier to read. Not something that we can’t live without, but definitely a nice improvement.
There are actually a lot more new things coming that I did not share in the last release; you can check them out here.
—
Back to the security part. The topic is quite broad and problematic to describe. I will touch on different areas, but feel free to add your thoughts to the comments.
For the sake of this article, let’s assume there are two kinds of security issues:
Simple code-related problems: SQL Injection, XSS, IDOR (Insecure direct object references), etc.
More process-related issues, where the attacker needs to figure out a specific flow missed during the refinement and implementation, which leads to unwanted results.
I will focus on the first category, but I will look at both basic information and some tools, my thoughts on the tools, and what I think is a good approach.
Usually, when we think about the most common security leaks, we think about OWASP Top 10, and when asked for specific cases, we would mention SQL Injections or XSS.
And indeed, in most of the projects I worked for, this was the main focus, but if you have a look at the actual list, injections are in third place. Some vulnerabilities might not be stuff you actually consider on a daily basis.
Anyway, if you are not sure what the whole SQL Injection, remote code execution and XSS is:
OWASP Top 10 Security Risks (2025): A Comprehensive Guide
I struggled a bit to find a good article on the OWASP Top 10, but this one is good. What I would like to suggest is to dig down, and not only read 5-10 sentences per vulnerability, but rather try to really understand how to perform an attack for each of them and how to prevent it.
OK, so understanding the OWASP Top 10 is a very basic step that each developer needs to master. Another very basic thing is to have AUTOMATED CI/CD steps to verify at least the basic things.
I struggle to understand why teams do not have this (or similar tools) set up in their pipelines. Fast, efficient, simple, and powerful. Of course, it does not detect issues in your codebase, but I have seen projects running an outdated, vulnerable Symfony version for years.
Invest the 10 minutes to set it up, and make use of it.
While you are already at it, you should also consider adding Psalm and/or PHPStan - maybe not directly related to security, but Psalm can actually find simple SQL Injections and XSS, and PHPStan will help prevent some bugs from happening.
A bit similar to composer audit, but more on the infrastructure side (although Trivy can also scan and report outdated libraries). Both are easy to install and set up, and while Hadolint will mainly improve your Dockerfiles, Trivy can do a lot more. It will scan your Docker images too, but it can also scan your codebase for secrets and security issues (including things like unsafe configs in Terraform), or even scan your Kubernetes cluster. I was actually surprised that during a Kubernetes scan, it reported critical vendor vulnerabilities in a package.json file! As developers, we often tend to forget that some infrastructure vulnerabilities also need to be covered, and for sure, in many cases, this will be handled by the DevOps team, but we should be aware of that attack vendor. Similar to composer audit, you should set those tools in your pipeline.
Commercial tools
While we are on the pipeline topic, some of you might be aware of commercially available tools: RIPS (now part of Sonar), Snyk, Aikido, just to name a few. To be honest, I haven’t used any such tools recently, as they always annoyed me a bit. False positives were quite common, and they still left real issues unseen. I’ve recently seen a project where one of the tools detected SQL Injections in safe queries, but missed them in places where SQL Injections actually occur. This is not only a waste of money, but gives the development team a false feeling of being secure.
The newsletter already gets a bit long, so let me focus on the last topic that I think is important.
I know people usually say they know OWASP Top 10, and they understand SQL injections, etc, yet they still make mistakes and write unsafe code. Another issue I often see is that people assume “modern frameworks are secure”. They are, but they won’t prevent mistakes in the code you write. For this reason, I think it’s beneficial to spend a bit of time and learn how to “hack” web apps ;) There are lots of ways you can do that. One is to use (free) services like PortSwigger Web Security Academy, OWASP Juice Shop (not written in PHP, but still the attacks are pretty much the same ;)) or DVWA (PHP). There are even gamified platforms like TryHackMe, with some content being available for free.
While playing with the above, consider testing the tools mentioned before; will they catch the issues? You can also give dynamic application scanning testing a go, eg. ZA Proxy.
I know this did not cover 100% of security best practices and tips, but as mentioned in the beginning, the topic is very broad. I hope you found something new in this edition, and do not hesitate to share your suggestions/questions in the comments.
Why is this newsletter for me?
If you are passionate about well-crafted software products and despise poor software design, this newsletter is for you! With a focus on mature PHP usage, best practices, and effective tools, you'll gain valuable insights and techniques to enhance your PHP projects and keep your skills up to date.
I hope this edition of PHP at Scale is informative and inspiring. I aim to provide the tools and knowledge you need to excel in your PHP development journey. As always, I welcome your feedback and suggestions for future topics. Stay tuned for more insights, tips, and best practices in our upcoming issues.
May thy software be mature!