We do not install a plugin and declare the site secure. We start from the real threat model of a WordPress site and treat every class of attack separately, with a concrete measure, configured and verified.
You are not being attacked personally. You are being scanned automatically.
WordPress runs on roughly two in five websites in the world, which makes it the most attractive target on the internet. Almost none of the attack traffic is aimed at you specifically. It is automated, indiscriminate and continuous: scanners walking IP ranges, botnets replaying password lists, robots checking every site they find against a database of vulnerabilities published this week.
That changes what good security means. You are not defending against somebody who wants you. You are defending against a machine that tries thousands of sites an hour and keeps the ones that fall over. The objective is not to be the site that falls over.
The threat model
What actually happens, and what we do about each
Security without a threat model is decoration. Below, the real attacks that hit WordPress sites and the measure we take for each.
Brute force and credential stuffing
The most common attack by volume. Automated login attempts, either guessing passwords or replaying username and password pairs leaked from other breaches. It works far more often than people assume, because password reuse is almost universal.
What we do: rate limiting at the network edge, before the request reaches PHP, so attempts do not cost you resources. Blocking after a defined number of failures. Two step authentication for administrators. Moving or hiding the login address. An audit of existing accounts, because the account nobody remembers creating is exactly the one that gets used.
Vulnerable plugins and themes
The single largest cause of compromised sites. A vulnerability is published, exploit code appears within hours, and automated scanners start walking through every site running the affected version.
What we do: continuous monitoring of every plugin and the theme against vulnerability databases, not merely against the question "is there an update". Security updates applied immediately. Identification of abandoned plugins, because any component no longer receiving updates is a problem regardless of whether it has a known vulnerability today.
SQL injection and cross-site scripting
Through anything that accepts visitor input: search fields, forms, comments, URL parameters, queries written by a previous developer. SQL injection reaches the database. Scripting reaches visitors' browsers and is frequently used for spam links or invisible redirects.
What we do: an application firewall with WordPress specific rules, filtering known patterns before they reach the application. Review of custom code for unsanitised input. A Content Security Policy limiting what a successful injection could do. Database privileges reduced to the strict minimum.
File upload abuse
Any form accepting files is a possible route to code execution. The classic variant uploads a PHP script disguised as an image. The subtle variants abuse SVG files, which can contain JavaScript, or exploit the image processing libraries directly.
What we do: validation of the real file type, not the extension. PHP execution completely disabled in the uploads directory, so a file that does slip through cannot run. SVG sanitisation where it is genuinely needed. Size and rate limits. Permissions set so the web server can only write where it must.
Forged requests and supply chain compromise
The first tricks an authenticated administrator into performing an unintended action, without a password and with logs that look legitimate. The second is the attack nobody prepares for: a legitimate plugin changes owner, the new owner ships malicious code in a routine update, and every site installs it automatically.
What we do: token verification on forms and custom endpoints, cookie attributes configured correctly. We do not apply updates blindly in production: they are tested, and file changes are compared for unexpected additions. File integrity monitoring flags anything that changes outside a known update, which is exactly how this class of attack is caught.
Injected spam and search result poisoning
Instead of breaking your site, the attacker leaves it looking exactly as it was and injects hidden links, or serves Google's crawler different content from human visitors. Sites run in this state for months. The first symptom is usually a collapse in search or a Search Console warning, long after the compromise.
What we do: monitoring that compares what a normal visitor receives against what a search crawler receives, because the divergence is this attack's signature. Periodic checks of indexed pages against expected ones, so pages you did not create get noticed. Search Console integration, so the warnings reach us.
Hardening
The layers underneath
Beyond individual countermeasures, a set of structural decisions determines how much damage a successful attack can do.
Hardening measures applied and verified
Measure
What it prevents
How we apply it
File permissions and ownership
A compromised account able to write anywhere
Least privilege. The web server writes only where WordPress needs it. The configuration file is not readable by other users on the system
File editor disabled
Turning an administrator session into code execution
Disabled by constant. There is no legitimate use in production
Endpoint restriction
Amplified brute force and user enumeration
XML-RPC off or strictly limited, API enumeration blocked, directory listing off, version hidden
A Content Security Policy built from the site’s real inventory, plus HSTS, nosniff, referrer and permissions. Not copied from a blog
Correct TLS
Session interception and filter bypass
Valid certificates renewed automatically, modern protocol versions only, origin protection so nobody reaches the server directly around the filter
The database
A breach spreading beyond the site
A user with privileges limited to what WordPress requires, credentials used nowhere else
Why in stages
A wholesale copied set of headers will be either too permissive to help or too strict to work. A Content Security Policy that blocks your own tag manager is removed within a week, and then you have no policy at all. We start in report only mode, read the violations from real traffic, then enforce. It is slower and it is the only way it survives contact with a live site.
Monitoring: finding out before your customers do
Prevention fails at some point. What separates an incident from a disaster is how quickly you find out.
We monitor file integrity against known checksums, so any unexpected change to core, plugins or theme raises an alert. We monitor availability and certificate expiry. We monitor blocklists, so you hear it from us rather than from a customer telling you their browser shows a red warning page. We track administrator account creation and privilege escalation, because a new account you did not create is the clearest signal there is.
Incident response
If a site under our management is compromised, the response is included. There is no emergency rate appearing at the worst possible moment.
The procedure: isolate first, so the spread stops and the search presence is no longer affected. Preserve the evidence before cleaning, because a site cleaned without analysis teaches you nothing and you will be compromised the same way again. Restore from a backup verified as clean, not assumed clean. Identify and close the entry point. Rotate every credential. Request review wherever the site was flagged. Then a written report on what happened, how, and what changed so it does not repeat.
What you get every month
Vulnerability status for every plugin, theme and core version, with everything urgent already applied
The volume and type of attacks: what was blocked, from where, against what
Integrity check results, with every change explained
The audit of accounts and permissions, including what changed
Verification of response headers and TLS configuration
Backup confirmation, including that a restore was actually tested
Concrete recommendations, ordered by real risk rather than by what is easiest to sell
Frequently asked questions
Is a security plugin not enough?
No. A plugin runs inside PHP, so it sees the request only after WordPress has fully loaded and after the request has already consumed server resources. It is a useful layer and we configure it properly, but it does not replace filtering at the network edge, correct file permissions, hardened configuration or monitoring.
Can hardening break something on the site?
It can, if applied from a generic list. Disabling XML-RPC stops some mobile publishing apps. An overly strict Content Security Policy blocks undeclared integrations. That is why every change is tested on staging and validated against your site's real behaviour.
What if the site is already infected?
We clean it, find the entry point and close it. Recovering an already compromised site is quoted separately, because the work depends entirely on what we find there. From that moment on, the subscription covers you.
Do you guarantee the site cannot be broken into?
No, and be careful with anyone who guarantees that. Security means reducing risk, not eliminating it. What we guarantee is a defined countermeasure for every known class of attack, monitoring that detects a compromise quickly, tested backups and response included if it happens.
How quickly do you apply a security update?
As soon as it appears, without waiting for the monthly cycle. The interval between a vulnerability being published and automated exploitation is now measured in hours, not days.
Send us your website address
We run a security assessment and tell you exactly what we find, concretely, not a generic list of warnings designed to frighten you.