WordPress Security

The average WordPress site runs a stack of plugins from many different authors, of wildly varying quality. When a popular plugin ships a vulnerability, it becomes a mass-exploitation campaign within hours, sweeping every site that runs it. The plugin is the entry point far more often than the core or the theme.

A default “admin” username, a reused password, and a login page open to the whole internet with no rate limiting is a combination that automated brute-forcing finds and beats. A large share of WordPress compromises need nothing more sophisticated than that.

Sites drift. A plugin that was safe at launch picks up a vulnerability, a theme stops being maintained, an admin who left still has an account. Security is a state you have to keep, not a box you tick once, and WordPress rewards the sites that stay on top of it.

First we take stock: every plugin and theme with its version and vulnerability status, the user accounts and their roles, the file permissions, the wp-config settings, and the hosting setup. This is a WordPress security scan done with an engineer’s eye, so it flags the risks a tool would rank as informational.

We update or replace vulnerable plugins and themes, remove anything unused, and check the provenance of what remains, because nulled or pirated plugins are a classic way malware arrives baked in. Fewer, well-maintained components is a more secure site than a pile of half-used ones.

We remove default and stale accounts, enforce strong passwords, add rate limiting and, where appropriate, two-factor authentication on wp-admin, and rename or protect the login endpoint to cut brute-force noise. We also review roles so contributors do not quietly hold more power than they need.

Protecting wp-admin

The admin area is the prize, so it gets particular attention: limiting access by IP where practical, disabling file editing from the dashboard, and making sure a compromised low-privilege account cannot walk up to full control.

We set correct file and directory permissions, harden wp-config.php, disable directory listing, block execution of PHP in the uploads folder, and remove the version-leaking and debug output that helps an attacker profile your site. Small changes, but they close the doors that automated tools rattle first.

The most valuable WordPress security best practice by a wide margin is keeping core, plugins and themes current, and removing what you do not use. It is unglamorous, and it prevents most compromises on its own.

Give each user the lowest role that lets them do their job, use unique strong passwords, and put two-factor on administrator accounts. Most breaches escalate through an account that had more access than it needed.

Layer a tuned firewall in front, keep monitoring behind, and take real backups you have actually tested restoring. No single measure is enough; the combination is what makes a site genuinely hard to breach.

For sites that matter, continuous monitoring watches for file changes, new admin users and newly disclosed vulnerabilities in what you run, so a problem is caught in hours rather than discovered by a customer. This pairs naturally with the hardening as an optional monthly add-on.

If your WordPress site has custom plugins, a membership area, WooCommerce with real money moving through it, or an API, a manual penetration test finds the business-logic and access-control flaws that hardening and scanning cannot. That is a separate, deeper engagement we also provide.

A WooCommerce store handling card data falls under PCI DSS, which expects hardening, testing and a firewall. For any site holding personal data, GDPR expects appropriate technical measures, and a documented hardening and monitoring process is part of demonstrating that.

Hardening and vulnerability management map to ISO 27001 Annex A controls, including A.12.6, and our documentation of what was changed supports that evidence trail.

WordPress ships with interfaces that are useful to some sites and pure attack surface to others. XML-RPC is a favourite for brute-force amplification and can usually be disabled outright. The REST API leaks user names by default, which feeds credential attacks, so we restrict what it exposes to anonymous visitors.

A backup you have never restored is a hope, not a plan. We check that backups exist, run off the server rather than only on it, and can actually be restored, because the worst time to discover a broken backup is the day after a compromise.