WordPress svetainės saugumas: 10 patikrų šį mėnesį

WordPress sites are rarely broken into by someone who picked you specifically. Almost always it is an automated crawler working through thousands of addresses looking for one of a few dozen known weaknesses. That is two pieces of good news: the list of attacks is short and predictable, and most of the checks can be done from the outside, without server access.

Here are ten checks an agency can run in an hour on one site — or automate across every client site at once. The order follows how often each one turns out to be the culprit.

1. Core version

Start with the obvious: which WordPress version is running and how old it is. Security releases come out regularly, and a site two minor versions behind is almost always behind on something else too. If automatic updates are off, find out why — the reason is usually one plugin that broke once.

2. Plugins and themes

Most real incidents start in a plugin rather than in core. Three questions for each one: is it on the current version, is it still maintained, and is it needed at all. The third matters most. A deactivated plugin left on the server is still a set of files that can be called directly. If the feature is no longer used, the plugin should be deleted, not switched off.

3. Version disclosure

WordPress publishes its version in the generator meta tag by default, and /readme.html says it again. Neither is a vulnerability, but both are a signpost: a crawler that sees a specific old version knows what to try next. Both take a few minutes to remove.

4. User enumeration

Open /wp-json/wp/v2/users and try /?author=1. If either returns usernames, or redirects to an author page with the username in the URL, half the password-guessing work is already done — only the password is left. This is closed either by a plugin or by a few lines of server configuration.

5. xmlrpc.php

The old XML-RPC endpoint is still enabled on a great many sites. It is both a password-guessing channel that bypasses ordinary login throttling and a pingback abuse vector. Unless you use the WordPress mobile app or Jetpack, it can safely be closed. The check is simple: if the address answers with 200 or 405, it is live.

6. Files that should not be public

This is the category where findings are the most unpleasant, because they are immediately usable. Check at least:

• /wp-content/debug.log — a debug log containing paths and sometimes queries.
• wp-config.php.bak, .old, .save and wp-config.php~ — editor leftovers the server happily serves as plain text. They contain the database password.
• .zip, .sql and backup files left in the web root.
• An open directory listing under /wp-content/uploads/.

If you find a wp-config copy, treat the database password as leaked and rotate it rather than just deleting the file.

7. The admin panel

There is no need to hide /wp-admin itself — hiding it buys little. Three things are worth more: login attempt throttling, two-factor authentication at least for administrators, and a user audit. The last one is skipped most often: sites tend to keep a former employee’s account with administrator rights and a password unchanged since 2019. Go through the list and remove anything that no longer has a reason to exist.

8. Security headers and HTTPS

Check that the whole site runs on HTTPS with no mixed content, that the certificate is not close to expiry, and that the basic headers are present: HSTS, X-Frame-Options or the equivalent Content-Security-Policy directive against framing, X-Content-Type-Options and Referrer-Policy. None of them stops a break-in, but they do stop several cheap attack techniques, and they can be added without touching code.

9. File permissions and writability

With server access, check the permissions on wp-config.php — 644 or tighter. Also check whether theme files are writable from WordPress itself: being able to edit PHP directly in the admin panel means one compromised administrator account turns straight into code execution. The DISALLOW_FILE_EDIT constant switches that off in one line.

10. Backups — and restores

The last item is what still helps once the other nine have been missed. Three questions: are backups being made, are they stored somewhere other than the same server, and when did anyone last restore something from one. A backup that has never been tested is a hope, not a fallback.

Doing this for thirty sites

For one site this list is an hour. For thirty it is a week, which is why it does not get done. That is exactly why we wrote the WordPress scan: from the outside it detects WordPress, reads core and plugin versions and checks these same familiar points — version disclosure, xmlrpc, user enumeration, debug.log and config backups. The output is a score and a list you can put in front of a client.

An honest note on what such a check cannot see. It looks from the outside, so it does not know your password policy, whether the backups actually work, or whether a foreign file is already sitting on the server. It is the first layer, not the whole of it.