WordPress security best practices – how to secure your self-hosted WordPress website from malicious hackers. The best plugins (mostly free), tips, and resources.
- Top 14 WordPress security best practices
- Key vulnerabilities in WordPress and how to mitigate them
- Injection attacks
- XML-RPC attacks
You may also be interested in Basic SEO practices.
Top 14 WordPress security best practices
1) Change default “admin” accounts. When you sign up with a hosting company such as SiteGround, Bluehost, or WP Engine, you may find a default user and login account called admin. Hackers know that many people do not change this default account and thus hackers have half the information they need to hack a website (what’s left is figuring out the password).
2) Use only strong passwords–at least 10 characters including 1 uppercase letter, 1 number, and 1 symbol–and enable 2FA. You can test the strength of your password using an online tool such as How Secure Is My Password? by security.org.
3) Your password retrieval email account should be secret/private, and its retrieval email account should also be private (your work/school account is not private).
4) Use a reputable security plugin like Wordfence or iThemes Security and set it to immediately lock out unauthorized users attempting to log in.
5) Eliminate brute force attacks by locking out users after 3 or less failed login attempts (e.g. within a 24 hour period).
6) Limit forgot password feature usability to 3 trials or less (e.g., in a 24 hour period).
7) Ghost your default WordPress common paths, such as wp-login and wp-admin, and mask your default files, such as wp-content/plugins and wp-config, using a plugin like Hide My WP Ghost to prevent hackers and bots from targeting known entry points and vulnerabilities because they can’t find them. If your wp-login authentication path is visible hackers can perform brute force login attempts.
8) Vet your subscribers before approving their subscription or giving them access to your website. Are they real people? Don’t send automated responses as it can give bad guys clues they can use to hack your website.
9) Limit your plugins to what is necessary and sufficient–and remember, the more plugins you install the slower your website will load and the more prone it will be to “things breaking” in functionality due to conflicts/overlapping settings.
10) Use/install only regularly updated plugins (before installing them, Google their names with the words security and vulnerabilities) and keep your plugins up to date. Attribution: opt not to make known/identify your plugins. It’s not a perfect world.
11) Monitor security announcements about newly discovered vulnerabilities in your WordPress core, themes, and plugins. You can refer to Wordfence’s Updates on WordPress security.
12) You really need only one theme installed (WordPress may request that you install a backup theme). Any unnecessary software presents additional entry points to your CMS.
13) Enable auto updates for your themes and your plugins.
Saving the best for last…
14) Keep periodic backups of your website and enable 1-click website restore with a service provider/plugin like Jetpack or BackupBuddy. Also keep screen shots of your website.
Key vulnerabilities in WordPress and how to mitigate them
Your biggest WordPress security risk is probably brute force attacks targeting visible authentication paths or targeting an active XML-RPC php file. Your most significant attack vectors for cross-site scripting (XSS) and SQL injection attacks are probably fill out forms on your WordPress website. Your biggest WordPress security vulnerability is probably faulty plugins or vulnerable apps.
Injection attacks
A security survey conducted by Wordfence circa 2015 of 1599 WordPress plugin vulnerabilities reported over a 14 month period found the following distribution.
Plugin vulnerabilities represented 55.9% of the known entry points reported by respondents. XSS vulnerabilities are the most common vulnerability found in WordPress plugins by a significant margin (at about 47%). “What this means is that if we can successfully teach WordPress developers to avoid writing XSS vulnerabilities, we can prevent almost 50% of the vulnerabilities that appear in WordPress plugins.”
Fast forward to 2021: OWAP ranks injection attacks (which include XSS and SQL injection) in third place in their Top 10 web application risks. Topping the list is Broken Access Control. “Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.” In second place is Cryptographic Failures. Interestingly, at #7 is Identification and Authentication Failures.
In injection attacks, a malicious script is injected into a vulnerable web application. But unlike SQL injections, XSS attacks target the users of the web application rather than directly targeting the application itself.
XSS attacks can be broken down into two types: stored and reflected. Unlike a reflected attack, where the script is activated after a link is clicked (the malicious scripts are executed on the client-side in the browser), a stored attack only requires that the victim visit the compromised webpage (the malicious scripts are stored and executed on the server, and then served by the browser).
In a successful stored XSS attack, a perpetrator injects malicious script into the server (e.g., via a comment field) and then steals each visitor’s session cookies where a user’s credentials are stored, enabling a perpetrator to impersonate valid users and abuse their private accounts.
The easiest way to prevent XSS is to disable JavaScript in the browser (e.g., using browser Add-ons) so no malicious function will be executed. A web application firewall is the most commonly used method to protect from XSS and web application attacks (including SQL injections). WAFs can employ signature based filtering to identify and block malicious code.
Databases using SQL include Oracle, MySQL (used by WordPress), SQL Server, and PostgreSQL. SQL Injection is the result of loopholes in the backend coding. SQL injection is a common way to inject malicious script into data entry fields that could execute SQL commands that can create, retrieve, update, and even delete the data in the database. By using some altered SQL queries, one can request the admin username and password.
XML-RPC attacks
XML-RPC can be a gateway for DDoS and brute force attacks. XML-RPC on WordPress is an API (application program interface) that gives developers who make mobile and desktop apps the ability to communicate with a WordPress site.
Hackers can leverage the Remote Procedure Calls (RPC) capability of XML-RPC to invoke functions to fetch the data they want. “In the majority of the WordPress sites, the xmlrpc.php file is easily traceable, and just by sending arbitrary XML data, hackers control the site to run the code they have prepared to execute a certain type of attack” (servebolt.com).
To ensure your site remains secure it’s a good idea to disable xmlrpc. php entirely, unless you require some of the functions needed for remote publishing or the Jetpack plugin. You can disable XML-RPC either by using a plugin like Disable XML-RPC, or by adding some code in a filter or to your .htaccess file.
Related content
How to set up website analytics to see audience insights
Back to DTI Courses
Related content (off-site)
Understanding PHP Vulnerabilities & How They Originate – From Wordfence
Introduction to WordPress Security for WordPress Administrators – From Wordfence
Detect if Your WordPress Website has Security Flaws – A WordPress vulnerability detector from Hide My WP Ghost
Ways to Prevent SQL Injection in WordPress – Tips from Cloudways.com
