WordPress security tips

Having worked with WordPress for a while now I worked-out certain simple ways to drastically improve the security and integrity of a WP based website.

From my experience most of the successful attacks come from existing admin accounts. Hackers always try to brute-force they way in pretty much every website there is on the web for weak login credentials. It can be spotted in the server logs.

Even non-admin accounts with post publishing capability pose a threat. They can be e. g. accessed by a bot which will create thousands of posts or add a malicious code to existing ones. Those hacks, depending on the scale of your website, can be difficult to remove as most likely would affect all your website’s articles.

Recommended precautions:

• Limit the access to admin panel. Also keep an eye on non-admin accounts if there are any and disable or delete the accounts that are not currently in use. Kinda universal tip, applies everywhere not only in WordPress.
• Limit accounts to a bare minimum. Keep the number of admins as low as possible and avoid sharing same credentials between the accounts.
• Always use strong passwords. A good idea to apply this to user names as well as email addresses. Keep those information safe and avoid accessing admin panels from unknown computers or on random wifi networks.
• Check the site health on a regular basis. Websites left alone without attention often get hacked. It’s a good practice to at least regularly monitor the size of your MySQL database.

Bare in mind that a hacked website might not show any bad symptoms for many years.

Below there are my recommendations for a managed WordPress websites, where the web admin have the access to the server’s files and some knowledge of PHP.

1. Set the recommended access rights to the files on server. Generally a good practice is to set 644 for the files and 755 for the directories. All files should be owned by the web server user and group*. Tighter access rights should be applied to .htaccess and wp-config.php files depending on environment.
2. Turn-off the admin’s panel file-editing capability. This serious security issue can be easily avoided by adding a single line to wp-config.php: define('DISALLOW_FILE_EDIT', true); Without that clause anyone with the admin account access (and I mean mostly bots) is able to amend any of the files of your WordPress installation. You won’t even notice when the website starts sending thousands of spam emails or creating a random, hidden posts.
3. Turn-off the file modifications. A line in wp-config.php: define('DISALLOW_FILE_MODS',true) will effectively block anyone, even with admin privileges, from tinkering with your WordPress installation. File modifications should to be only allowed on a temporary basis, when performing the WordPress and plugins update.
4. Turn-off the plugins screen in the admin. The plugins panel only needs to be available for updating or managing of the plugins. It is a good practice to have it disabled by default: remove_menu_page(plugins.php)  – this hook allows for hiding tabs from the admin menu, it won’t block the access though. To make it effective you need to also redirect the http request (containing e. g. a string plugin) to let’s say localhost. I usually do so also with the requests containing theme and customize strings to disable the relevant admin screens.
5. define('FORCE_SSL_ADMIN', true) – this setting is most likely only important on servers that don’t automatically redirect to secure channel. It can be added in wp-config.php.
6. On almost all WordPress websites you can see many break-in attempts in the server’s logs spamming the wp-login.php and xmlrpc.php. There are many ways of securing those files, depending on your build and requirements. The quickest possible way would be probably by renaming them and adding some e. g. random string to the filename itself. It will make the login and logout process a bit tricky and might disable certain functionality in case of  xmlrpc.php. Similar to this approach would be adding an additional user and password requirement in the http header such as request.Headers.Add(‘UserID’ … .
   This approach is not recommended as the long-term solution in the production environment, but effective as a quick ‘n’ dirty fix.

Conclusion

If your passwords are strong and safe, you’ve got correct access rights to website’s files set-up, don’t have questionable plugins installed and keep your WordPress up to date then you should be completely fine.