As a member of the PHP community for the last 10+ years, I’ve seen the topic of security come and go. PHP’s always had a bad reputation for being an insecure language and, honestly, that’s a valid point to make. It’s PHP’s own low barrier for entry and lack of a cohesive plan that’s made it such an “interesting” language to use over the years. I’ve also had a foot in the security community for the past few years and I’ve seen an interesting disconnect between it and the world of PHP.
I constantly see articles talking about how insecure PHP is compared to other languages and how no one should be using PHP if they’re concerned about protecting their users and data. As such, PHP seems to have been mostly dismissed by the security community as a sort of “toy language” that’s not suitable for the enterprise like Java or .NET are. I can’t tell you how many companies I’ve seen looking for people to fill application security analyst roles that only want Java or .NET experience. PHP makes up such a small part of their market that they don’t even bother looking. This is very surprising considering how much of the web is running on PHP (based on statistics, take that how you’d like).
This focus on the .NET and Java worlds has bled through to other parts of the security community too. Take the Open Web Application Security Project (OWASP) group as an example. If you’re a member (I am) or even just a casual reader of the information they have to offer, there’s a very clear bias towards these two languages. There’s been a few initiatives they’ve started over the years to try to enhance the PHP-related information they provide, but sadly a good bit of it is falling out of date and isn’t as useful as it once was. Things like the PHP Security Cheat Sheet have had a few additions and wording changes, but even then there’s quite a bit of information that’s just missing from its content.
There’s something that concerns me more than just incomplete content on a wiki page, though. I was looking through some of the PHP security libraries that are being worked on by OWASP members (such as phpsec) and noticed something interesting. There is a lot of “Not Invented Here” going on there. Sure, PHP developers are guilty of this too, but it seems this hints at a larger point: is the OWASP group doing more harm than good by not embracing some of the well-known security tools that exist outside of their own organization? In fact, the only PHP library the OWASP group has on Packagist is their RBAC (role-based access control) tool that seems to ignore standards like PSR-4 (or even PSR-0) for autoloading, separation of concerns and good design practices that have become well-used in the PHP community in recent years.
So, what’s my point in all of this? I think the OWASP project can do better, honestly. They’re users of the PHP language but, with a few exceptions, don’t seem to be a part of the PHP community. They almost have their head in the sand when it comes to some of the practices that have come to define the language and community around it. It feels like PHP is an after-through on most of their initiatives and that there’s not much reaching out to the PHP community as a whole to find reusable packages that fit their needs, are more robust, well tested and proven.
The security community inside PHP is growing up and I think having large projects like OWASP understand it and be a part of it can help the news of this renaissance spread even further. PHP developers, more than ever, need as much up-to-date information and tools to help protect their applications. Consider this a call out to both fellow OWASP members and PHP developers as a whole to get involved in the wider security community, share these new advancements and openly share ideas across these borders.
Shatter those old conceptions of what PHP was and replace them with new techniques, practices and knowledge across communities. Only then can we help the wider web understand that PHP isn’t what it once was.
blog.phpdev 
Chris,
Good article. I agree, more involvement from developers and security experts within the PHP space would be a great addition to OWASP’s PHP materials. We should definitely work to break down the Not Invented Here concerns too. OWASP should provide the best available information regardless of origin.
Are there any changes OWASP could make to encourage, or make it easier, for more content and ideas from PHP experts?
– Michael
LikeLike
Michael, drop me a line at ccornutt at phpdeveloper dot org and we can discuss more. I think there’s a good opportunity here.
LikeLike
I tend to view OWASP as a bunch of pentesters sharing knowledge. They tend not to have the best dev skills.
That’s why it’s important that more PHP developers get involved with OWASP.
LikeLike
I’d be keen to help out in anyway I can. I too am disappointed with OWASP when it comes to PHP. I recently patched the PHP CSRF tool (I forget the name) as the existing code didn’t do anything to prevent CSRF attacks.
LikeLike
OWASP provides some useful research documentation, theoretical guidelines and a few summaries, albeit badly categorized and presented. I don’t believe it’s accidential, but just like the inherent CORS unmanagability a vehicle for consulting services.
NIH syndrome certainly plays a part in all that. But a bigger concern to me is a fundamental mistake in approaching security. Take ESAPI for instance. It’s clearly well-intentioned, but tries to carry over Javas enterprisyness and lackluster documentation too literally. It therefore fails big time at applicability in the PHP environment.
Ridiculous API hoops, foreign implementation details and method signatures can only lead to logic errors in library consumers. And logic errors are already the primary limp when it comes to webapp security and reliability. → **Complexity does not abet security.**
LikeLike
This *may* be a reflection that not many PHP developers are involved with OWASP compared to the other languages you mentioned.
OWASP is a community and a portal to share information. Anyone with an account can edit the wikis to improve them. I myself have written a couple and improved wiki pages when I see the need and have the time.
You say that there’s “quite a bit of information that’s just missing from its content”. But you never mentioned (but maybe you did) that you updated the resources with new information.
Maybe this is the problem. Too many people are happy to point out the incomplete/inaccurate/missing information but not enough are willing to edit/update the information themselves.
LikeLike
I definitely think this is the case too. It needs to work both ways. I actually ended up having a Twitter conversation about exactly that the other day. Both sides are guilty of being more siloed than they need to be. I think if work was done to encourage more integration between the groups, it would be a win-win for everyone. I’m not sure how to accomplish that, to be honest, but at least something like this gets the conversation started.
I’ve requested an account on the wiki so I can start contributing myself, hopefully encouraging others to do the same.
LikeLike
“RBAC (role-based access control) tool that seems to ignore standards like PSR-4 (or even PSR-0) for autoloading”
If you have installed PHP-RBAC using Composer simply include the Composer generated ‘vendor/autoload.php’
Using a PSR-0 Autoloader
Point your Autoloader to ‘PhpRbac/src’ using the ‘PhpRbac’ namespace.
LikeLike
Just because it uses an autoloader doesn’t mean it’s PSR-0. The namespacing doesn’t follow the directory structure and a custom autoloader is defined to handle class location.
LikeLike