I've been picking up a few things about securely running PHP apps while getting the site up and running. I am by no means a PHP security expert, but I thought I'd write down the things I've found out so far so I can find them again when I forget. The first big thing that bothered me was that I had to make all my files world-readable to get anything to work. This bugged me, so I searched around a while for a better way to do it.

On my webhost, PHP scripts are (by default) run with the Apache module mod_php. I imagine most shared hosting services have the same setup. Although mod_php has many benefits (speed, memory usage, resource sharing), it has some security implications on a shared server. Many PHP+MySQL applications (phpMyAdmin, Wordpress, etc.) will have a file where your MySQL database password is stored (this file is generally called "config.php", or similar). When using mod_php, your PHP application will run under the user id of the Apache server (usually an unprivileged user id). One effect of this is that you are forced to make all of the files that the PHP application needs to access world-readable (readable by any other user on the webhost). Even worse, if the PHP application needs to write any data, then you have to make those files/directories world-writable. Try running "ls ~/.." on your webserver sometime and you will see there are likely dozens of other accounts on the same machine as you. Once you make all of your files world-readable, any one of those users (and anyone they have given FTP access to) can chdir into your directory, read your config.inc.php files, and get all of your MySQL passwords. In the case of a world-writable directory, someone could use your space to set up their own MP3 file-swapping area. Do you trust the random people sharing the server with you? I sure don't.

Fortunately, there is a way around this. Instead of running your PHP scripts with mod_php, decent webhosts will allow you to run via cgiwrap (or equivalent - something like php4-cgiwrap, or suphp - check your webhost for site-specific details). When using cgiwrap, the PHP application will run under your user id, so you can remove all other file permissions from sensitive files. You probably do not want to just do a "chmod -R go-rwx" on your entire site, however, since there are likely non-PHP files that still need to be world-readable (images, style sheets, etc.). I just do "chmod go-rwx" on the specific files that have sensitive information in them (like config.inc.php).

Running scripts under your own user id isn't without its own set of security risks. If someone were to compromise your site (via a bug in a PHP script for example), they would have full access to read/change/delete all of your files, since they would be running as "you". When running under mod_php (as an unprivileged user), they would only be able to use whatever "world" permissions your have granted. It's definitely a tradeoff and you have to decide which is more appropriate for your site. For example, when running a stable/mature application, the CGI method may be better for security since you can lockdown all files and run under your user id. With a new application you might want to run under mod_php until you are fairly sure there are no security bugs in the application itself.

Note that running via CGI will incur a performance penalty compared to mod_php. There are solutions like fastcgi that can greatly improve performance, however I am not aware of any CGI-accelerators that also support running under your own user id. If your site gets enough traffic that CGI becomes a serious problem, you can likely justify moving to a dedicated server or VPS where you can safely make files world-readable (since there will be no other users on the system) and run mod_php.

Either way you go, it makes sense to me to prepare for the worst (i.e. expect to have your site hacked sooner or later), and take steps such as keeping daily backups of your site and databases. I personally wouldn't keep any data on a webhost that I would care too much if anyone saw. For sites that need to process confidential data, credit card numbers, etc., obviously much more is required beyond these simple steps.