I almost missed this story about a how mistyped opening PHP tag exposed a bunch of Tumblr data. This wasn’t sensitive data like usernames and passwords but rather the slip revealed database-related information and private API keys related to the running of the site.
I was a little concerned with the misinformed comments in the article and the speculation as to the performance costs and overheads involved in parsing ini files. The fact remains that no matter where in your system you store your configuration files and what format you keep them in, they still need to be readable by your public-facing webpages to be of actual use. However, in this case simple, best practise methods would have mitigated the security lapse.
Keep sensitive details protected
Store your configuration files at a level above your web root so that they are inaccessible to a HTTP request if their location is revealed. If you don’t have access or permissions to write to a secure directory then protect your configuration with
.htaccess — either denying access outright or by using a password, preferably using Digest authentication and not the weaker Basic method.
Never edit directly on the server
Some people persist with this practice despite the inherent issues. You’re using version control for a reason right? Deployment of files goes in one direction only: from development to staging and then to live.
Test your code before you put it live
You don’t have to have a full-featured test harness integrated into your deployment chain — running a quick check using the
-l flag with the PHP command line binary should suffice.
This is obviously not an exhaustive list of best practices but, as the title of the post suggests, sticking to these points should be enough for you to avoid dropping a clanger.