When it comes to securing your PHP application against hackers and other types of malicious use, there are a number of different things to consider. We touched on a few of them previously, including what's probably the most important one: filtering all user input. We can't stress enough the importance of correctly validating all user input, including any input that comes in the form of file uploads. However, one of the most useful tools to secure your PHP code against malicious users is built right into the way PHP operates: the php.ini file.The php.ini file is a customisable configuration file that is called when PHP loads which specifies a number of key settings for how PHP operates and executes your code. Because of this, it's also a great place to handle a couple of security vulnerabilities that are almost as crucial as controlling user input.
The first of these is the issue of error reporting. Obviously, when you're working in a test development environment, it's incredibly valuable to have your error reporting visible to help you quickly source any bugs in your code - but once you move out of the testing phase into a production environment, the data offered by error reporting can provide valuable clues to a hacker about potential vulnerabilities in your code. While you can try to ensure that doesn't happen by writing flawless code, there are a number of global parameters you can set in your php.ini file that will ensure your production code is safe from this issue. The first parameter, error_reporting, does exactly what it says on the tin, namely enabling error reporting at all, and should be set to E_ALL. The follow-up to this is the parameter display_errors, which should be 'off' once you move out of the testing phase. However, as you will probably want to ensure that any errors that do occur are logged, enable log_errors and specify the path using error_log. That's all there is to it!
The other important security vulnerability to prepare for is the type of attack known as session fixation. Essentially, this type of exploit tricks your code into accepting a session ID that has been faked by the malicious user. This can occur in a few different ways, but the methods for overcoming it can all sit in the php.ini file. A few different parameters are very useful: both session.use_cookies and session.use_only_cookies should be set to 1, which prevents GET parameters from setting your session ID. Session.use_trans_sid should be set to 0 to prevent session IDs from persisting, and as a final measure you should modify the name of the session parameter - session.name - away from the default "PHPSESSID" to something random.
These tips won't guarantee the perfect security of your code, but they can go a long way towards preventing the casually snooping hacker from easily breaking into your application and causing untold damages. Take the time to write technically exacting code, and you'll be rewarded by an app that flows smoothly and robustly!
