It was the year 2017. The last remnant of the PHP 5 series was demoted into *security fixes only* status. Soon it was to be retired to the dustbin of technological history; its purpose spent. The world was largely [moving towards supporting PHP 7 exclusively](https://paragonie.com/blog/2016/04/go-php-7-our-commitment-maintaining-our-open-source-projects). Discussion towards improving the language and cleaning up the existing software ecosystem was ongoing. And then, in one fell swoop, all of this great progress gets discarded because someone decided to regurgitate ancient PHP 5.1-era advice about LAMP stack hardening. There have been countless examples posted in various places (Reddit, Hacker News, Twitter, Facebook, Slashdot, and even LinkedIn group discussions), and while a handful occasionally contain one or two tips that might be beneficial towards securing your PHP applications, almost all of the advice they contain is either wrong, a huge waste of time, downright silly, or all of above. As part of a team that specializes in application security (in particular: securing PHP applications), I feel it's high time someone cleared the air about this advice. # PHP Security Has (Almost) Nothing To Do With Configuration Here are the things that *do* actually matter for security: 1. You had better be using HTTPS. * And you had better be using it ***everywhere***. * Configuring Apache/nginx/lighttpd/Caddy/etc. to send a [HTTP Strict-Transport-Security](https://scotthelme.co.uk/hardening-your-http-response-headers) header to tell your users' browsers to stay on a secure channel. But you can do this with a single `header()` call, so classifying it a configuration change is really a cop out. 2. If you're still using PHP 5.6 and are using PHP's native session feature, set `session.entropy_length` to `32` and `session.entropy_file` to `/dev/urandom`. (This may be done for you already.) * PHP 7 users can ignore this, as PHP does the right thing automatically. That's it. Any other recommendation you receive about `php.ini`-driven security is non-helpful; including but not limited to: * `expose_php`: Self-service automated scanning tools love to include "PHP version exposed" in their reports, so people assume that exposing this will get them targeted for recently-patched vulnerabilities. This is easily debunked: If an attacker is interested in attacking your system, they're going to attempt to break in whether or not your server advertises its version information. Worst case scenario for an attacker: You burned one proxy to fail2ban (or equivalent), so you switch then continue onto the next possible vulnerability, usually milliseconds later. So instead of worrying about that, [make sure you keep your systems up to date](https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#offline-digital-signatures) so this information doesn't matter to the security of your systems. * Debian users will want `unattended-upgrades`. * CentOS users will want `yum-cron`. * Other operating systems and Linux distros will have their own equivalent. * `register_globals` hasn't been a PHP feature since 5.4.0. It doesn't exist anymore. * `magic_quotes` hasn't been a PHP feature since 5.4.0. It doesn't exist anymore. * `allow_url_fopen` and `allow_url_include` only stop unskilled attackers. * Don't believe me? Read this great article by Keith Makan about [ordering a Remote File Inclusion exploit via email](http://blog.k3170makan.com/2012/01/ordering-remote-file-inclusion-via-e.html). Keith turns a Local File Inclusion vulnerability (which is usually only useful for leaking credentials) into an arbitrary file inclusion vulnerability by sending an email to the server and using that file in the LFI exploit. * The **suhosin** patch and the **Hardened-PHP project** in general: Despite OpenBSD's insistence on including it with PHP (because it claims to be more secure, and OpenBSD likes to bill itself as the "proactively secure" operating system), the [Suhosin project isn't exactly *active*](https://github.com/sektioneins/suhosin/commits/master). Suhosin probably won't hurt anything, but don't go out of your way to install it. Your `php.ini` kung fu cannot save you from insecure code. Which is the point most of these articles seem to miss. ## Secure PHP Software: It Begins and Ends with the Code Read [*A Gentle Introduction to Application Security*](https://paragonie.com/blog/2015/08/gentle-introduction-application-security), which is the best starting point for learning to write secure PHP code that we can offer. If you want your PHP software to be secure, learn to identify vulnerabilities and mitigate them. Relying on brittle configuration settings to protect your servers from some developer's mistake is a losing strategy. It's also wasteful, which harms any company that decides to pursue configuration-based PHP security instead of hardening their code-base. If you need help, get in touch. We consult. ### Frequently Asked Questions > Can *some* configuration changes help improve security? Well, they usually don't hurt. The problem is that time is finite and would almost certainly be better spent preventing the actual vulnerabilities in the code itself, rather than trying to dance around them by obsessively tweaking webserver configuration files. Some features, like `open_basedir`, were exclusively intended to improve security. If you have a lot of attack surface provided by third party software, it's an additional *layer* of security. However, if you're reading an article to *learn about PHP security*, focusing on last-resort configuration settings rather than *secure code* isn't a recipe for success. On that note: If you use `open_basedir` in particular, make sure that `/dev/urandom` is whitelisted too so that your software can generate secure random numbers.