Whether you’re running a web service or a blog, you should always keep your software fully patched to prevent attacks and minimize your attack surface. Another smart step is to prevent full path disclosures. For example, if your blog or service throws an error like
“Warning: require(ABSPATHwp-includes/load.php) [function.require]: failed to open stream: No such file or directory in /home/horace/public_html/wp-settings.php on line 21”
then by noting the full pathname from that error, an attacker could reasonably infer that your username is “horace” and use that try to guess your password. It’s not the end of the world if your attacker has that information, but why not make an attack as hard as possible?
For WordPress, here’s a couple ways to prevent full path disclosure vulnerabilities:
– In a php.ini file, you can add a line like “display_errors = off” (without the quotes).
– In an .htaccess file, you can add a line that says “php_flag display_errors off” (without the quotes).
It sounds like the php.ini approach might be slightly better, because some web hosts run PHP in CGI mode which might not allow php_flag or php_value directives in .htaccess files.
After you’ve made this change, php errors shouldn’t be shown to web clients. If you’re developing live code on a PHP installation, that can make debugging slightly less easy. But if you’re running (say) a blog, it’s probably better to turn off display errors for a little extra protection against attacking hackers.