In recent days, I’ve talked about the importance of server hardening and security, but there’s another aspect of the integrity of your server that must not be ignored: PHP code.

If you don’t have secure PHP code, you may find yourself the victim of numerous type of attacks, including SQL injection attacks, which as the name suggest, goes directly after your database, which in most cases is the very heart of your website or application.

Sometimes, the most basic adjustments will go along way. One example is this variable:

register_globals

If you look in your php.ini file, and find that this variable is enabled, you may be putting yourself at risk, for all anyone has to do is add “?authorized=1” to a URL on your site, and they will then gain access to sensitive information that you likely don’t want the average user to see.

The best solution here is to simply set register_globals to “off”.

Another mistake that many people make is that they fail to suppress PHP errors. When a PHP error occurs, and error reporting is fully enabled, a user can see a lot of information about your site, including exact paths. Of course, you don’t want this information to be readily available, so it would be a wise decision to suppress the errors so that they do not display in the web browser.

You actually need not change the error_reporting variable itself, because you still want to be able to see errors as the administrator. You just don’t the whole world to see them, too. To accomplish this goal, simply look for the “display_errors” variable, and set it to “Off”.

You will also want to set the “log_errors” variable to “ON”, so that the errors show up in your error log. If you turn both logging and display off, the potential exists for errors to still display, because the errors do need to be reported somewhere. But by confining it to the error_log, you and anyone else you grant administrative powers to will be the only ones who see them.

By doing this, you will prevent error messages from showing up on a user’s web browser, potentially giving them a detailed road map to the compromising of your server.

Also, make sure that there are no settings for error reporting in your .htaccess file, because these settings could override your default php.ini settings for that particular website.

These are just two examples of easy ways that you can secure PHP. There are, of course, many others. Though these solutions are simple, they go a long way, and the time invested in making these adjustments will pay dividends in the form of a secure server.