WordPress now powers more than 25% of the world’s websites and almost 50% of the world’s e-commerce websites – that’s a big responsibility for an open source project! WordPress’s simplicity and versatility as a blogging platform, CMS, and web app framework is what makes it so popular, but with so much popularity comes significant risks – such as keeping it secure.
How secure is WordPress in reality & how can we keep it even more protected?
Based on my experience with WordPress and statistics, the platform is as safe as any other web platform. It’s not WordPress’s fault if website admins don’t take the simple steps to at least update the core and/or plugins and themes that need to be updated.
Why WordPress is on the Good Side of Fighting off Hackers
– It is updated often (WordPress core itself and plugins/theme associated)
– It takes things seriously: when vulnerability is reported the WordPress contributors and core of developers usually fix the issue in a matter of hours or very few days
– WordPress core is open source and its code can be reviewed for issues by the whole world
– The core also has bug bounty programs
– They have a security team always available and ready 24/7
– They have set standards (coding references) on how a developer who wants to extend WordPress using plugins/themes should do this.
It’s fair to say that WordPress takes the issue of security very seriously. Even some bigger companies don’t have this kind of organization when it comes to dealing with security, proactively and reactively.
Does this mean WordPress is 100% safe?
Unfortunately, not. Indeed WordPress is doing a great job on fighting off security issues, vulnerabilities on the core, etc. but still there is the possibility of bugs/exploitation points that a dedicated hacker might use to gain access to private information or even take over the website completely! However, at the least WordPress is as safe as any other platform in the wild west of CMS-s.
What can we (the WordPress developers end-users) do to improve the Platform‘s Security?
1) Keep everything up to date (WordPress Core, Plugins and Themes)
Based on stats, the most used attack vector for hackers against WordPress based websites, have been outdated plugins, themes and the WordPress core itself. We all remember the TimThumb issue which affects a lot of websites a few years ago since it was a library integrated into hundreds of plugins and themes. To protect against such vulnerability the solution was easy, update the plugin/s, theme/s that were affected.
2) Change all WordPress defaults.
Start by not using admin as the username for the admin of your website. Change the WordPress table’s prefix. Change WordPress salt keys (you can change the WordPress salt keys on wp-config.php).
3) Use a strong password.
WordPress, as all other CMS-s by default, is vulnerable to brute-force attacks (we will come to how to deal with those soon), so first of all, use a hard-to-guess password. Use a password that contains numbers, characters, and special characters. A password of more than 12 characters composed of numbers, characters and special characters (@#!, etc.) is very hard to break for most hackers.
4) Activate dual-factor authentication
WordPress by default (as most of the other big CMS-s) does not offer a default 2FA system. However, integrating it into the platform is not such a big deal anymore.
For more information on this, you can read the official WordPress tutorial here.
5) Never use nulled Themes/Plugins.
We have to admit it though, we all have used a nulled theme and/or plugin at least once. The thing is, we can’t expect WordPress to protect us from ourselves, we can’t expect everything to work correctly when we don’t know what plugin have we installed on our website.
Based on stats, nulled plugins/themes are one of the most used attack vectors from hackers to gain access to a WordPress based website. So if you want your website to be safe, especially in a production environment, never install a nulled theme or plugin.
6) Always install themes/plugins from trusted sources.
This is complementary to the previous security checklist item (never use nulled themes and plugins). When you install a WordPress theme from WordPress theme directory, that theme has been manually reviewed by the WordPress Theme Review Team so it should be good to use.
A theme that you download from another source might not be reviewed at all might even contain some malicious code inside – and the same goes for when you need to choose a plugin. Another thing to keep in mind here, WordPress is evolving daily. So when you are about to choose a plugin for example from WordPress Plugins directory, always see when was the last time that the plugin was updated.
A plugin that has not been updated in a while (more than 1 year for example) should be treated with suspicion. It could be that the developer has abandoned it as a project and in the future, you might be end-up using an outdated plugin, which means a possible vulnerability in the future.
7) Remove all un-used plugins/themes
Remove all unneeded and unused plugins and themes. Even deactivated plugins might have security problems. Even though the plugin might be deactivated a hacker might use it as an attack vector, if he finds a vulnerability in that plugin he will use it against you.
8) Properly configure files and folder permissions
All directories should be 755 or 750 – All files should be 644 or 640 – wp-config.php should be 600
9) Harden protection of wp-config and htaccess file
Use this code:
<files wp-config.php>
Order allow,deny
deny from all
</files>
<files .htaccess>
order allow,deny
deny from all
</files>
10) Security by Obscurity
Now there are some people that say Security by Obscurity is not a real protection layer for your website, but in my opinion, it is.
After all, security is a concept – it just means making things harder for anyone that is trying to gain access to your website for whatever motive. Based on this “definition”, if security by obscurity helps make things harder, then why not use the added layer of protection.
– Hide wp-admin and other login related url-s: The WordPress default login url is wp-admin and or wp-login.php. Hiding it would make it harder for hackers to brute-force their way on the backend of your website. Most of the hackers use automated tools (scanning tools, bots) to try your website for possible security problems, so hiding wp-admin would make their automated tests, automatically fail. No more brute-force problems!
– If not needed disable author archives and/or don’t show author username in posts. By showing the username of the author who posted a post, you have immediately told the hacker your username. So if you are the only author on your website it could be better to just disable author archives completely, remove links to author archives in the theme, modify your theme so it doesn’t show the author archive or at least doesn’t show the author username in the front end.
– Disable Directory Indexing and Browsing: When a folder has no index.html/index.php file and if that folder is accessed via a web browser, a list of files/folders will be shown. This can pose a security problem since it might expose the plugins/themes used on your website. A dedicated hacker might use this info to search for vulnerabilities on these plugin/s theme/s and then achieve his goal of gaining access to your website.
11) Limit Login Attempts
By default, WordPress does not have this feature integrated into its core, but there are a lot of plugins we can use to implement this feature in order to eliminate brute-force attempts on our website:
– Limit Login Attempts
– iThemes Security 1
12) Remove WordPress related info from the front end.
Hackers use automated tools to scan websites for vulnerabilities. Initially, they do a scan to just identify the CMS and/or other libraries used on the website, then when they know the CMS used they try a different kind of vulnerability attack for that kind of CMS and see if 1 of them helps them to gain access to your website (all of this is automated). So that’s why giving the less info possible to the hackers is always a good idea.
Add this code on your functions.php inside your active theme: remove_action(‘wp_head’, ‘wp_generator’);
13) Configure user roles correctly
In the case of your website having a registration form, always configure the user role for the new users correctly. WordPress by default adds the new users in the user role Subscriber, which is good in the security point of view. If you decide that you need to change this though, select the user role of the newly added users correctly.
Always keep in mind the principle of least privilege. Everyone should have the privilege to access only what he should have to, a simple user doesn’t need to have access to plugins/themes for example.
14) Disable editing of plugins/themes from backend
define( ‘DISALLOW_FILE_EDIT’, true ); By adding this code on wp-config.php, you disable the theme and plugin editor in backend. No one (including the admin user) will be able to edit themes or plugins from the backend.
15) Disable errors from showing on production server
Now while we work on development environments we need to have errors shown or at least logged somewhere so we can debug problems showing while developing. In a production environment it is recommended not to show errors or log them, or if we need to log them the log file shouldn’t be accessible via browser or it would give the hackers a way for them to identify possible issues with our website and use that against us.
16) Disable XML-RPC
XML-RPC is one of the least used features in my opinion. XML-RPC can be used for a lot of things but the thing it is used for more and more is used to hack your website. So disabling it (until WordPress decides to remove its support), could be a good idea.
After all, some of the features that XML-RPC covers, now or in the future will be completely covered from the new WordPress REST API which should in one way or another minimize the need to keep using XML-RPC.
17) Use a good hosting company
Now one of the main attack vectors used on WordPress websites is the hosts being configured incorrectly. For example, you are on a shared host, one of the other websites hosted on the same host as you gets hacked and the malware spreads even on the other websites hosted on that same host.
Usually this shouldn’t happen: usually, malwares shouldn’t access files/folder above the root of their current website, but if this happens it means that something is badly configured from the hosting company. Normally good hosting company don’t do this kind of mistakes so before deciding where to host your website, always see reviews.
18) Use security plugins for WordPress
I wouldn’t want my recommendations here to look like an affiliation with these plugins. I’m basing my recommendations firstly on personal experience than from global feedback. I would recommend using these plugins/tools to protect your website:
– iThemes Security (security plugin)
– Sucuri Security (security plugin)
– WordFence Security (security plugin)
– Cloudflare (CDN and Firewall)
For the full list of features that each plugins has i would advise to check out each plugin since there are a lot more features then I can cover here!
19) Be pro-active when it comes to being safe
When it comes to security, we have an axiom: there is no 100% being safe in the information world. No matter how hard we try, how many layers of security we add, we might go to 99% but never 100%. That’s because there are still a lot of factors not in our hands.
If one of those elements is vulnerable the whole system is vulnerable. Having said that, we need to always be proactive, in other words to be ready for whatever it comes, whenever it comes. By being ready I mean at least having a backup in place and having a plan of action on how to deal when bad things happen.
Regarding the backup, there is no 1 rule for all since there are very high traffic sites that might need a backup every day, there are others that might need backup every week, etc. But i will leave that to you to choose the right backup for you based on your experience. I would recommend though to have a backup at least in two copies and well don’t just do the backups, test them also from time to time (at least).
You need to know the backup you have is ready to be restored if anything happens, you can’t afford to do the restore test on live website if the backup you have is not correct.
As for how to deal when you get hacked (plan of action) since it’s a very broad topic it could be better if i write another article for that specific topic.
Until then, I hope you liked this post and hope it helps you making your WordPress website even safer!
