I think point #1 is very important. I do this also: * All code is owned by a 'code' user, and all files by default are user and group read/write. * The www-da

I think point #1 is very important. I do this also: * All code is owned by a 'code' user, and all files by default are user and group read/write. * The www-data user (who runs the web server) can only write to wp-content/uploads and where ever else the plugins are required to write to * The places www-data can write to have .htaccess files that turn off execution of PHP scripts (so the app itself cannot upload code and run it, if there is a zero day exploit like the timthumb.php). What this causes though is a bunch of plugins to complain they cannot work due to not enough access, and WP upgrades can't be done through the wp-admin, this tends to upset end users a bit, so I agree #5 is important. I have a deploy user who is in the code group so I can manage our automated deploys. Also, by default wp-admin doesn't have any login restrictions so people can brute force it (I think). It's really important to install something like the wp-recapcha plugin so people can't brute force your logins. This is especially important as end users who are creating accounts often choose poor passwords. I like #2, I don't do this, though I think I'm going to have to! Generally it comes down to typical system admin best practices. You're running a codebase you didn't write yourself, you have no idea what it's going to do. EDIT: These permission things are not typically doable if you're running your blog on shared hosting. So shared hosting is generally not particulary safe. I'd recommend anyone without a dedicated sysadmin to use something like http://page.ly/ http://page.ly/, which is managed by smart guys.