Website security in levels: what each one stops and what it costs

You have a site that works. One day you get an email from your hosting provider about “suspicious activity”, or a customer tells you the site sent them to a betting page. Only then does the question come up: what should I have done before, and how much would it have cost?

The problem with security is that it is invisible. When it works, nothing happens. The offers are confusing: some sell you a plugin, others a cloud firewall, others a maintenance package. None of them says clearly what remains uncovered.

Below is a map in three levels. For each one you see what measures it contains, what it stops, what it does not stop and what it costs you, as an order of magnitude, in money and time. At the end there is a checklist in the order someone would actually go through it.

Level 1: what is free and mandatory for any site

The first level costs no money. It costs discipline. And it stops most of what hits an ordinary site, because most attacks are automated: bots looking for old software versions and weak passwords. They are not looking for you. They are looking for any door left open.

• Updates on time for the core, themes and plugins. When a vulnerability becomes public, bots start looking for it within hours.
• Unique, long passwords, generated by a password manager. A password also used on another site ends up in a leaked list sooner or later.
• Two-factor authentication for all administrator accounts, with no exception for the “test account” or the “agency account”.
• Automatic backup, stored somewhere other than the site’s server and tested by restoring it.
• Deleting unused plugins and themes. A deactivated plugin still has code on the server and can still be exploited.
• Minimal roles. Whoever writes articles gets the author or editor role, not administrator.
• HTTPS everywhere, with a redirect from http and a certificate that renews automatically.

What it stops and what it does not

It stops: exploitation of known vulnerabilities, password guessing, reuse of leaked passwords, access through old forgotten accounts. In practice, most hacked sites failed here, not on something sophisticated.

It does not stop: a zero-day vulnerability in a popular plugin (one that not even the author knows about yet), an account compromised through phishing, or an attack that comes through the hosting server rather than through the site.

What it costs

Zero in money. In time, a few hours at the start to put things in order, then usually one or two hours per month for updates and checking the backup. If you do not have someone to do this consistently, a maintenance and updates subscription is the form in which level 1 is actually bought.

Level 2: what a firewall and access rules add

The second level assumes someone will try more than a scan: more persistent bots, or an attacker who found a hole before you managed to update. Here you reduce the window of risk and gain visibility.

• Web application firewall (WAF), at plugin or server level. It filters requests that look like known attack patterns before they reach the site’s code.
• Login attempt limiting: after a few wrong passwords, that address is temporarily blocked.
• Blocking access to sensitive files: wp-config.php, readme.html, xmlrpc.php, the .git directory and backup or migration archives forgotten in the webroot.
• File change monitoring. When a core file changes without you having run an update, you get an alert.
• Login logs: who signed in, from where, when. Without them, you cannot reconstruct anything after an incident.
• Security headers: Content-Security-Policy, X-Frame-Options, Permissions-Policy, HSTS. They tell the browser what the page is allowed to load and from where.
• Hiding software versions from the page source and from the server headers.

What it stops and what it does not

It stops: brute force against the login, some of the new exploits (if the firewall has the rule before you have the update), leaks of configuration and backup files. Just as important, it shows you what is going on: without logs, a site can be compromised for months without anyone noticing.

It does not stop: an administrator whose password was stolen through phishing and who signs in perfectly legitimately, a vulnerability for which the firewall has no rule yet, or problems at the level of a server shared with other sites.

What it costs

A good plugin-level firewall has a free version, but rules for new vulnerabilities arrive faster in the paid version, an annual subscription in the range of a few tens of euros. Headers, file blocking and logs require technical knowledge: a few hours of configuration, then time for someone to read the alerts. If you have no one for that, it is part of a WordPress security service with a monthly subscription.

Level 3: infrastructure, isolation and a plan for when things go wrong

The third level makes sense when the site makes money directly or holds customer data: online stores, platforms with accounts, high-traffic sites. Here you also protect the context in which the application runs.

• Proxy or CDN with protection, for example Cloudflare. Traffic first passes through their network, which absorbs volume attacks and hides the server’s real address.
• Isolating each site in its own container. On classic shared hosting, a hacked site can reach the files of the other sites in the same account.
• Server-level rules for bots and rate limiting. Aggressive bots are blocked before they load the server.
• Uptime monitoring and alerts. You find out the site is down within minutes, not from a customer.
• Periodic testing: someone actively checks, at a regular interval, whether the measures really work.
• Incident response plan, written in advance: who gets called, what gets isolated, which backup is restored from, who informs the customers.

What it stops and what it does not

It stops: denial of service attacks, an incident spreading from one site to another, bots that eat up resources, the time lost until you find out something is wrong. And it reduces the damage of an incident that happens anyway, because you have a plan.

It does not stop: anything that walks in through the front door with a valid password. An administrator who installs a pirated plugin with malicious code gets through all three levels.

What it costs

Dedicated infrastructure, not shared hosting, plus system administration time. The monthly cost is an order of magnitude above level 2. For a store that takes payments daily, one day of downtime often costs more than a year of level 3.

Why WordPress is most often hacked through plugins

The WordPress core is maintained by a large team and receives security updates automatically. Plugins are written by anyone, from companies with security teams to a person who abandoned the project three years ago. Your site runs all the code from all installed plugins with full privileges. A single weak plugin is enough.

How to evaluate a plugin before installing it

• Date of the last update. More than a year without any update is a sign of abandonment. More than two, do not install it.
• Number of active installations. A plugin with many installations is checked more often by researchers and fixed faster. It is also targeted more often.
• Vulnerability history. Search for the plugin’s name in a public vulnerability database. Almost all of them have had problems. What matters is how fast they were fixed.
• What it actually does. If you need a contact form, do not install a suite with twenty modules of which you use one.

The signs that you have already been compromised

A hacked site does not necessarily look hacked. The attacker usually wants to stay unseen, so they can use the site for spam or phishing. Look for:

• Users with the administrator role that you do not recognise.
• Pages or posts you did not write, often in another language or about gambling.
• Strange redirects that appear only on mobile or only when you come from Google.
• Warnings in Google Search Console, in the security section.
• Recently modified core files or new files with random names.
• Emails sent from your domain without your knowledge.
• A sudden slowdown, without you having changed anything.

What to do first, in this order

1. Do not erase the traces. First make a copy of the site as it is, infection included, so you can find out where the attacker got in.
2. Change the passwords: all administrator accounts, the database, the hosting account, FTP or SSH. The attacker may have several ways in.
3. Isolate. Put the site in maintenance mode or block public access until you have fixed it.
4. Restore from a clean backup, from before the incident. Manual cleaning almost always leaves something behind.
5. Find the cause. Which plugin was outdated, which account had a weak password. If you restore without closing the door, the incident repeats within days.

Backup: the only proof it exists is the restore

All three levels rely on backup. It prevents nothing, but it turns a disaster into a lost hour.

The classic rule is 3-2-1: three copies, on two different media, one of them in another location. For a website: one copy on the server, one in the hosting account or in a backup plugin, and one at a different provider. If the server is compromised, the copies on it disappear with it.

The frequency depends on how often the site changes. A brochure site modified a few times a month can have a weekly backup. A store with daily orders needs a daily backup of the database, otherwise you lose orders.

Checklist

• Turn on two-factor authentication on all administrator accounts.
• Change short or reused passwords; put them in a password manager.
• Delete old accounts and lower the role of those who do not need administrator.
• Update the core, theme and plugins. Delete what is deactivated and unused.
• Check the date of the last backup and where it is stored. If it is only on the server, add a copy somewhere else.
• Do a test restore and note how long it took.
• Check whether readme.html, xmlrpc.php and any backup archives are publicly accessible. The free site check quickly shows you the security headers and exposed files.
• Install or configure a firewall and login attempt limiting.
• Turn on login logs and file monitoring, then decide who reads them.
• If the site takes payments or holds customer data, consider isolated infrastructure, monitoring and a response plan.
• Put a quarterly review of the whole list in your calendar.