PHP Tips, Resources and Best Practices for 2015

PHP has had many reputations over the years, but being insecure as a language never really was one of them.

The core team, all its faults notwithstanding, is rather quick in pouncing on all security matters, and updating PHP to the latest version will often allay all worries. But the end users, such as we are, tend to mess things up. We don’t update, we use outdated packages or packages with holes in them we’re not aware of, we use ancient extensions… we expose ourselves to risk in some truly creative ways.

Tips, Resources and Best Practices

Let’s start 2015 off right, shall we? This post will list important resources you should have in your brain/toolbelt before building anything with PHP in 2015. I’ll do my best to keep this post up to date, so it stays relevant indefinitely, but, like I said, I’ll need your help.

Keep your PHP up to date

When I wrote about the cancer that is legacy code, I focused on application code. I still firmly believe that you should never develop for the lowest common denominator, else you risk becoming the very thing that’s holding your language’s progress back. That’s not the focus of this section, though. Recently, a new version related discussion ensued.

CodeIgniter and WordPress are sticking with PHP 5.2 support (a version that’s been dead for four years now and shouldn’t exist on anyone’s server), and Anthony Ferrara responded in his blog post. Before you read this section any further, I implore you to read that post first. It’s important.

What that post accomplished was getting some people too lazy to upgrade riled up.

They argued for legacy support without considering the damage they’re doing to the PHP ecosystem. Anthony wrote another post in which he further explains his stances, and finished up with yet another post taking apart installation percentages of old PHP versions across the web, comparing them to the stability list to find out how many servers running PHP out there are insecure by default and hackable – today. The results are frightening to say the least.

If you’re developing something and are running anything but the latest major version of PHP, I urge you to give these posts a thorough read. If your client insists on host X or version Y for whatever reason, refer them to these posts, educate them, and help them see the error of their ways – teach them about the vulnerabilities they’re introducing to their project, and tell them about the horrors that can happen if they don’t act before it’s too late. Upgrading your PHP’s version is not something you should file under “we can do that later”. Do it now, and do it often.

Avoid outdated hosts

Inspired by the aforementioned discussions, Phil Sturgeon compiled a table of current PHP versions supported by various hosts. You can find it at or if you’d like to contribute and add some missing values, on Github.

I recommend you steer clear of all shared hosting in general – there are extremely cheap VPS providers out there now, like DigitalOcean (feel free to check them out via my ref link for a leg up).

Don’t be these guys. It starts out innocent and simple, but when you end up having to lend out your partner while doing someone else’s laundry, it stops being fun.

When opting for a VPS, other than saving you from sharing an environment with everyone else or being susceptible to the instability of a system as introduced by someone else, setting up your own server from scratch is a fun and rewarding experience you should be familiar with anyway. Besides, you can see on the list that barely anyone has the latest PHP version as the default one – why settle for anything but the latest software when starting a new project?


Encryption is crazy important today. Not just as a means of defending yourself from government snooping, but also as a way to make sure your clients and website visitors are protected as well and aren’t leaking any personal data. With advocates such as Ilya Grigorik and his pitches for TLS to Google announcing it would favor websites with HTTPS in search results, there’s no question about the ever increasing importance of HTTPS, even for simple websites.

While there are workarounds to getting HTTPS everywhere, one shouldn’t rely on those – it’s our responsibility as web developers to improve the web at large. HTTPS is not directly related to PHP, but whenever you’re starting a new PHP project it’s generally easier to set up your server to use HTTPS before you start coding, rather than in the middle of a project. To help you get through this often cryptic, daunting and discouraging task, (at least until Let’s Encrypt is out) Chris Palmer put together this Google Doc.

Secure your PHP

Don’t be these guys.

Follow best practices in password protection, generation, encryption and authentication. Read books and use packages like those suggested on the SecuringPHP site.

Stay on the Right Way

PHP The Right Way is responsible for improving the life of many a PHP project out there. In book form or digital, PTRW is an indispensable resource for making sure you’re fit to handle the challenges of modern app development. If you feel like it’s missing something or just want to contribute with typo corrections or alternative resources and guides, feel free to do so via Github.

Avoid Bad Packages

Almost two years ago, Fabien Potencier of Symfony fame announced the creation of a list of vulnerable packages for PHP. A year and a half later, this became standard part of Symfony and was turned into open source public domain property. You could now post your composer.lock file to their API or the web interface, or even the CLI tool, and it would check your project for vulnerabilities. However, this still required one step from the end users, and we’re lazy, lazy people.

Enter Roave team, the laziest of us. They made a security-advisories package which uses this database of known vulnerabilities. As Marco Pivetta explains in his blog post, you require it in your project like any other package, but instead of downloading anything, the package serves as a meta-package, not downloading anything and instead checking for whether the bad versions are required in your project. It will warn you and prevent even the attempt to download those packages, saving you not only a checking step, but a step that includes deleting them as well.

I urge everyone doing PHP development to include this in their projects. By jointly attacking the common vectors of insecurity, we’ll be one step closer to eradicating security holes on a large scale.

Dodge common mistakes

We’ve compiled lists of common mistakes before. Read the following posts to learn what to avoid:

By keeping these in mind, you’ll save yourself a world of trouble and major headaches down the road.


Use Vagrant! Even PTRW says so.

Vagrant helps you run cloned environments in small, headless virtual machines that forward requests to ports inside the machine, letting you use your host’s browser and your host’s IDE without interference. Want to nest a virtual machine inside a virtual machine? You can do that too, and it’s all completely safe! We’ve got a bunch of Vagrant tutorials and explanations under the Vagrant tag, so if you’re confused about the technology, read up.

Here at SitePoint, we have an officially endorsed fork of the Homestead Vagrant box (prepared by Laravel’s Taylor Otwell, but compatible with any framework and PHP application) called Homestead Improved. It’s runnable in under five minutes and you’ll have a completely encapsulated PHP environment to play in – with no fear of messing up your host OS or other projects. Made a mistake? Just destroy, rebuild, and you’re back where you started (with zero code lost) in a minute!

Note that we’re using this box in all our tutorials, so getting familiar with it now will both save you some time in the long run, and help you follow along with everything we do with great ease, not to mention the effect it’ll have on your local development environment. is a service from SensioLabs, the guys in charge of the Symfony framework and all its related technologies. It’s a transparent and low-overhead profiler able to analyze your code and alert you to issues with everything from application logic flow to interactions with the DB engines and even the cache layer. Blackfire is already installed in the Homestead Improved box mentioned above, so if you use our box or the original Homestead, you’re all set!

Catch problems before they throw a wrench into production! More detailed tutorials regarding Blackfire are coming soon!


We looked at some important links and resources for starting off your 2015 PHP projects properly, with performance and safety in mind. If you’re already using all these approaches, good for you – you can help us spread the word. Tell your friends and developer circles about it, direct them here, point the newbies who ask you how to get started our way and refer to the specific links in the post whenever someone tells you that legacy code should be supported and old PHP versions are fine. Send them here, and we’ll rough’em up!

Disagree with any of these? Would you add some critical resources that the resources we’ve linked to don’t already mention? Let us know – I’ll make sure the list gets updated!


  1. Only day 2 of the new year and the mis-statement of the year may have been made. PHP is infamous for being insecure. The core has improved, I’ll grant that, but the community surrounding it still doesn’t take the issue seriously. That’s not unique to PHP, but it seems worse among PHP progammers. The language itself does little to nothing to help users avoid these problems - loose datatyping is a hacker’s dream for causing all sorts of havoc. It wouldn’t be so bad if you could turn it off.

    I can’t be too critical of PHP - it does pay my bills - but don’t call it something it never has been - secure. It’s not - you have to watch it and the programs ran using it like a hawk.

  2. There’s to many PHP legacy tutorials out there on the internet, every day you see people who are new to PHP ask for help on script for they are learning PHP for the first time and found this tutorial on the net or it’s obvious they had for I spot is msyql instead of mysqli or PDO. Then you explain to them that mysql is obsolete and that you should choose one of the two alternatives. You get one of two responses.
    First response - “Oh I didn’t know that, Thanks for pointing that out”
    Second response (This one irks me to no end) - “Oh I know that, but I just want to get my script to run. I’ll go back later on and change it when I have the time”.

    I see that second reponse a lot and sometimes you get even a worse response than that, something like “I don’t care, I just want to get my script to work”. The later group of people is a lost cause and the ones who say they will go back when they have the time, I doubt that they ever will. It is not just that the make for PHP insecurities, for it’s other aspects of programming in PHP that make it insecure. A lot of people have this way of thinking - “If it is on the internet, it must be true” mentality.

    I still remember what it was like when I was new to PHP and spent long hours on a script only to ask help on it to get the reply - “You best to throw that code in the trash and start over for that has more security holes in it than Swiss cheese does”. The first inclination is to get defensive about it, but after a cooling of period you realize that the person was only trying to steer you in the right direction. It’s better to get a better grasp of PHP by doing it the right way the first time and I have learn before tackling something new in PHP to ask if I starting off the right way. Thus, hopefully avoiding spending needless hours on PHP code that is a pile of junk. That is my opinion why PHP can have a bad reputation, for there still a lot of legacy code still out there on the internet masquerading as helpful tutorials.

  3. No it isn’t - as the article states, many people write insecure programs using PHP but PHP itself is as secure as most other programming languages.

    There is a huge difference between insecurity being built into the language and people simply writing insecure code using a secure language.

    One of the biggest problems is that almost all books and sites teaching PHP do not include the code to make their example scripts secure in order to save space and to make the code being discussed easier to see. The people learning mostly assume that the code they have been taught is sufficient and so they leave out the other 80% of the code they should be writing that handles the security aspects.

    There are books available on PHP security that specifically teach you how to write the code in a secure manner and if that approach is followed then PHP is as secure as any programming language can be.

  4. That still has nothing to do with how secure PHP itself is. Sure many programs written in PHP are insecure because they omitted all of the validation and other security features but the article is referring to PHP itself as being secure - the code used to write PHP does include all the security features - you can write insecure programs in any language.

    There are far more amateur coders writing in PHP than in most other programming languages - that’s why so many programs written in PHP are insecure. The insecurity is in the way they write their code - it isn’t built into PHP and those who know how to program properly can write programs in PHP that are just as secure as programs written in other languages.

  5. swader says:

    Every kitchen has a knife.
    You can use it to poke out someone’s eye, to cut your veins, to damage your household.
    Why you’re allowed to have it at home is because a basic knowledge of its use is assumed.

    If given basic security training in PHP via the resources linked in the original article, one becomes basically proficient in PHP security measures.

    Much like you don’t let a child stab itself to find out knives are dangerous, so shouldn’t you let a rookie developer sabotage themselves with bad, outdated resources. As a PHP developer, it is on you not only to develop, but to educate those around you and to help spread good practices by means of, at the very least, referring them to proper sources.

    Like the others said - every language is as insecure as those using it make it.

41 more replies