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. 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 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 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. 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. 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, 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.