How to audit a WordPress site for security weaknesses

A security audit of a WordPress site is an inventory with a record. You go through six areas of a site that is working: what is installed, who can log in, how it is configured, what it shows from outside, whether it could be restored, and who holds the hosting and domain accounts. For each area you write down what you found. Plan an afternoon for it.

Nothing in the audit changes the site. The fixes come afterwards, in an order you choose, and WordPress security: what to do, in order of what matters most has the steps for most of them. If your question is whether someone has already got in, that is a different job: see how to check whether your WordPress site has been hacked.

Keep a record as you go

Open a spreadsheet before you start. Give each finding one row.

Record what was in order too, with the date. Never put a password in the record.

The dashboard is enough for most of the audit. The commands on this page need SSH access and WP-CLI, which you can ask your host about. Run them from the site's main folder. None of them installs, updates or deletes anything.

Software: what is installed

WordPress's hardening guide says older versions of WordPress are not maintained with security updates. It also says to keep plugins updated and to delete the ones you do not use. So the first area is a list of everything installed, with its version.

In the dashboard, go to Tools, then Site Health. The Status tab raises "You have plugins waiting to be updated" and "Your site is running an outdated version of PHP, which requires an update" as critical issues. On the Info tab, the WordPress section gives the version, the Server section covers PHP, and "Active Plugins", "Inactive Plugins", "Active Theme" and "Inactive Themes" give each item's version and whether auto-updates are enabled. The tab can copy all of it to the clipboard for your record.

With WP-CLI, it takes five steps.

A finding is any of these:

• WordPress or PHP on a version that no longer gets security fixes, or any update left waiting.
• A plugin or theme that is inactive. Its files are still on the server.
• A plugin on a version lower than the "Fixed in" of a record against it.
• A closed plugin. Its WordPress.org page says "This plugin has been closed and is no longer available for download." A security issue is one of the reasons a plugin is closed.
• A plugin whose last update is years old. It may be abandoned, or small and finished. How to choose a WordPress plugin shows how to read its listing.
• A row marked must-use or dropin, or a plugin from outside WordPress.org, that nobody can explain.

Write down every version, every update waiting, and for each plugin from outside WordPress.org, who installed it and where its updates come from.

Accounts: who can log in

Go to Users. The links above the table filter the list by role. Start with the administrators. From the command line:

wp user list --role=administrator --fields=user_login,user_email,user_registered

WordPress's documentation defines an Administrator as somebody with access to all the administration features of a site, and an Editor as somebody who can publish and manage posts, including other people's. A person who writes and edits rarely needs more than Editor.

Then go to Settings, then General, and read three things. "Anyone can register" decides whether a stranger can create an account. "New User Default Role" is the role a new account is given. "Administration Email Address" is where WordPress sends recovery mode and critical error notices, so it has to be a mailbox your organization can open.

A finding is any of these:

• An account for someone who no longer works on the site.
• One login shared by several people. You cannot remove one of them, and you cannot tell who did what.
• An administrator who only writes or edits.
• An administrator without two-factor login. How to set up two-factor authentication in WordPress shows where to check what each one has enabled.
• Registration open on a site that does not need it, or a default role above Subscriber.
• An administration email address that belongs to a past developer.

Write down each administrator's login, the person behind it, why they need the role, and whether two-factor login is on.

An administrator nobody can account for is a sign of a break-in, not a finding to file. The page on checking for a hack says what to do.

Configuration: how the site is set

• HTTPS. Type the http:// form of your address into the redirect checker. The last address it shows should begin with https://.
• File editing. WordPress's hardening guide says the dashboard by default lets administrators edit plugin and theme files, and gives a constant that takes that ability from every user. If the line is missing from wp-config.php, the command answers that the constant "is not defined in the 'wp-config.php' file." Look in the dashboard as well: if you can open a theme or plugin file editor there, editing is on. The security guide linked at the top has the line to add.
• Debug output. WordPress's documentation says its debug tools are not recommended on live sites. wp config get WP_DEBUG should print false, or answer that the constant is not defined.
• File permissions. WordPress's guidance is 755 for folders, 644 for files, and a wp-config.php that only you and the web server can read. WordPress file permissions shows how to read the modes and correct them.
• XML-RPC. WordPress's guidance calls xmlrpc.php a frequent target for password guessing, and names Jetpack and mobile apps as things that use it. How to protect WordPress from brute force attacks shows how to tell whether it answers and how to close it.

Write down each setting as you found it.

What the site shows from outside

Two checks read the site as a stranger does.

• The WordPress site health check reads one page and shows what it shows a visitor: whether it answers, how it is secured, what search engines are told, and which WordPress, theme and plugins it shows.
• The hacked-site check looks for the signs of a break-in that show from outside: visitors from search sent somewhere else, links hidden in the page, and code written to hide what it does.

A finding is an out-of-date version on show. The fix is the update, not hiding the number. Any sign from the second check ends the audit and starts the hack check. Write down the date and what each check returned.

Backups and recovery

WordPress's documentation says a backup has two parts, the database and the files, and that you need both to restore a site. It advises keeping at least three to five recent backups, with copies in different places. Answer these in the record:

• Does each backup hold both parts?
• Where are the copies, and is at least one away from the site's server?
• How many are kept, and how far back do they reach?
• When was one last restored, by whom, and how long did it take?
• Who can start a restore if you cannot be reached?

A finding is a backup with one part missing, copies kept only beside the site, or no date for a restore. How to schedule automatic WordPress backups has the steps for restoring one to a private copy of the site.

The hosting account and the domain

Whoever controls these controls the site, whatever WordPress is set to. List every account the site depends on: the hosting panel, SFTP or SSH, the domain registrar, DNS if it is somewhere else, and wherever backups are stored. For each one, record:

• whose name and email address it is in;
• who knows the password, and whether it is shared;
• whether its login has a second step;
• whether renewal is automatic, and whether the card on file is still valid.

A finding is an account in the name of a past developer or employee, a password passed around by email, a domain that renews only by hand, or file access over plain FTP. The hardening guide says to connect with SFTP, so the password is encrypted on the way.

The same guide notes that on a shared server, a break-in on another site on that server can reach yours. That is a line for the record, and often one to accept. The WordPress maintenance checklist covers reading the domain and certificate dates each quarter.

Turn the findings into a short list

Sort the record into three groups.

Keep the record. The next audit starts by comparing with it.

What this audit does not tell you

• It is not a penetration test. In one, a specialist tries to break in, with your permission, and reports how far they got. This audit attempts nothing.
• It does not find a flaw nobody has reported yet. A database and an update notice know only what has been found and published.
• It does not prove nobody is inside. The checksum step covers WordPress's own files and nothing else.

When to get help

• A client or a payment provider asks you for a penetration test. That is work for a specialist firm.
• A finding has no fix you can apply, such as a closed plugin the site depends on.

A care plan from our WordPress security service keeps the site updated, scanned and backed up offsite.