WordPress security: what to do, in order of what matters most
Keep WordPress, plugins and themes updated, give every account a strong unique password and two-factor login, and keep a backup you have restored at least once. Those three do most of the work. Roles, HTTPS, file hardening and a firewall come after them.
- By
- WP Ministry
- Published
In short
- Updates come first. Once a fix is published, so is the hole it closes.
- Every account that can log in needs a long password used nowhere else, and two-factor login.
- Give each person the lowest role that lets them do their work, and remove accounts nobody uses.
- A backup counts once you have restored it somewhere and seen the site load.
- Folders at 755, files at 644, nothing at 777, and the dashboard's file editor switched off.
- Hiding the login page or changing the table prefix cuts noise. It does not replace any of the above.
No WordPress site can be made impossible to break into. WordPress's own hardening guide describes security as reducing risk, not removing it. The useful question is which work lowers the risk most for the time it takes.
This page is in that order. The first four sections apply to every site and need no technical skill. Do the rest once those are in place.
Keep WordPress, plugins and themes updated
When a security hole is fixed, the fix is public, and so is what it fixed. From that day the sites still running the old version are the ones that can be attacked through it. Old versions of WordPress get no security fixes at all.
- Apply updates every week, and security releases sooner.
- WordPress can update itself automatically. Leave that switched on.
- Delete plugins you do not use. A plugin that is switched off still has its files on the server.
- Install plugins and themes only from WordPress.org or from a company you know.
How to safely update WordPress, plugins and themes covers the backup to take first, the order to work in, and how to go back when an update breaks something.
Use strong, unique passwords and two-factor login
Automated attacks on WordPress sites are of two main kinds: requests aimed at holes in outdated software, and password guessing. Updates answer the first. This section answers the second.
- A long password used nowhere else, for every account that can log in. Let a password manager make it and keep it. A password shared with another service is only as safe as that service. WordPress shows a strength meter when you change a password.
- No account named
admin. It is the first name a guessing program tries. - Two-factor login for every administrator. After the password, you confirm with a second thing you hold, such as a code from an app on your phone. A stolen or guessed password is then not enough. WordPress does not include two-factor login; a plugin adds it.
- The same care for the other ways in. The hosting account, SFTP, the database, and the email address that password resets are sent to. Connect with SFTP, not plain FTP, so the password is encrypted on the way.
How to protect WordPress from brute force attacks goes into password guessing and how to limit it. How to set up two-factor authentication in WordPress walks through the setup.
Give each person only the access they need
An Administrator can use every administration feature of the site, which includes installing plugins and creating users. Anyone who gets into that account can do the same. Most people who work on a site need less.
| Role | Can do |
|---|---|
| Administrator | Everything on the site |
| Editor | Publish and manage posts, other people's included |
| Author | Publish and manage their own posts |
| Contributor | Write their own posts, but not publish them |
| Subscriber | Manage their own profile |
Open the Users screen and look at every account. Lower each one to the role its owner needs, delete the accounts of people who no longer work on the site, and keep the number of administrators small.
Keep backups you have restored
A backup does not stop an attack. It decides what an attack costs you: with a clean copy from before the break-in, recovery is a restore, and without one it is a rebuild.
- Back up both parts. A WordPress site is a database and a set of files, and a restore needs both.
- Keep several, in more than one place. WordPress's guidance is at least three to five recent backups, stored in different places. A break-in can go unnoticed for days, and the newest backup may already hold it.
- Keep one away from the server. A copy that lives only beside the site can be lost with it.
- Restore one. Put a backup onto a staging copy of the site and check that it loads. Until then you do not know that it works.
WordPress backup plugins compared describes what each of the common ones does and where it stores its copies.
Serve every page over HTTPS
HTTPS encrypts what travels between a browser and your server, passwords included. Without it, a password typed on a network you do not control can be read on the way.
HTTPS needs a certificate on the server, and many hosts provide one at no extra cost. Check that your site's address begins with https:// and that the browser shows no warning beside it. If visitors see a certificate warning, see how to fix "Your connection is not private". If the page loads but the browser says parts of it are not secure, see how to fix mixed content.
Harden the files
These are measures that WordPress's hardening guide documents. They limit what someone can do after getting in. Take a backup first, and keep a copy of any file before you edit it.
Step 1: Set folders to 755 and files to 644
That is WordPress's guidance: you can change your files, and everyone else can only read them. Most file managers and SFTP programs can apply a permission to folders only or to files only. Over SSH, the two commands below do the same; replace the path with your site's folder.
Never set anything to 777. It lets every account and process on the server change your files.
bashfind /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;Step 2: Tighten wp-config.php
This file holds the database password. WordPress's guidance is that only you and the web server should be able to read it, which generally means a permission of 400 or 440. If the site stops loading after the change, put the permission back to what it was and ask your host which setting their servers support.
Step 3: Switch off the file editor in the dashboard
By default an administrator can edit the PHP files of plugins and themes from the dashboard. Someone who gets into an administrator account can use that editor to run their own code. Add this line to
wp-config.php, above the line that says "That's all, stop editing". The editors are then gone for every user.This does not stop an attacker from uploading a file some other way. It removes one of the first tools they reach for.
wp-config.phpdefine( 'DISALLOW_FILE_EDIT', true );
You can also tell the web server to refuse anyone who asks for wp-config.php by its address.
.htaccess
<Files "wp-config.php">
Require all denied
</Files>Reload the site afterwards. If it shows an error, remove the lines you added.
Add a firewall
A firewall looks at each request and turns away the ones that look like an attack. It can sit in three places:
- In WordPress, as a plugin. It filters requests as WordPress loads.
- On the web server. ModSecurity is a common one. The host usually installs and runs it.
- In front of the server, as a service. Traffic goes to the service first, and it passes on what it lets through.
Ask your host what they already run before you add anything. A firewall does not fix the hole a request was aimed at, so it comes after updates and never in place of them.
WordPress firewall plugins compared covers the plugins and services, and WordPress security plugins compared covers the plugins that bundle a firewall with scanning and login protection.
What hiding things does and does not do
Some advice comes down to hiding where things are. WordPress's hardening guide says that hiding is not sound as a main defense, though it might help in places.
| Measure | What it does | What it does not do |
|---|---|---|
| Moving the login page to another address | Cuts down the automated guessing aimed at /wp-login.php | Make any password harder to guess. xmlrpc.php takes logins too, and stays where it is. |
Not using admin as a username | Takes away the first name a guessing program tries | Protect an account whose password is weak |
Changing the database table prefix from wp_ | Blocks some automated SQL injection written for the default prefix | Fix the hole that let the injection in |
On a new site, choosing another table prefix during installation costs nothing. On a running site it means renaming every table in the database, so take a backup first or leave it alone.
Know the signs of a hack
WordPress's documentation lists these as clear signs:
- A search engine has flagged the site, or a browser shows a warning in place of it.
- Your host has disabled the site.
- Visitors say their antivirus flags the site.
- You are told that your site is being used to attack others.
- Something has changed that nobody on your side did, such as a new user.
- The site looks wrong when you open it.
Register the site with Google Search Console. Its Security issues report shows what Google has found when it judges a site to be hacked.
If you see any of these, write down what you see and when, and tell your host. Then follow how to remove malware from a hacked WordPress site. If you would rather hand it over, our malware removal is a one-time clean-up that ends with a written report and carries a 30-day re-clean guarantee.
The routine part of this page is what a care plan from our WordPress security service covers: weekly updates, security scanning and daily offsite backups.
Common questions
Does a security plugin replace the steps on this page?
No. A security plugin can add two-factor login, limit login attempts, scan files and filter requests. It cannot make an outdated plugin safe, choose your passwords, or restore the site after a break-in.
My host says its servers are secure. Is that enough?
It covers the host's part: the server's own software, the network, and whatever firewall and backups they provide. Ask what they back up and how you get a copy. What runs inside your site is yours: WordPress, plugins and themes, passwords, and who has an account.
Does the computer I log in from matter?
Yes. If the computer has malware that records what you type, no setting on the site helps. Keep its operating system and browser updated, and do not log in over a network you do not trust unless the site is on HTTPS.