Website security for people who are not security people

The first thing to get out of the way: almost nobody is attacking you personally. Scripts crawl the entire internet looking for one known hole in one popular plugin, and your site is a row in a list. That is good news, because defending against a script is a matter of habits, not expertise.

What actually happens to small sites

Four patterns cover the overwhelming majority of incidents:

• A known vulnerability in a plugin or theme. Someone publishes it, bots start scanning within hours, and unpatched sites get taken.
• Guessed or reused admin passwords, often harvested from an unrelated breach years ago.
• Hosting account compromise — often a neighbouring site on shared hosting, not yours.
• Form abuse: spam, mass emails sent through your contact form, junk entries filling your inbox until you stop reading it.

What the attacker usually wants is not your data. It is your server: a place to host spam pages, send email, or quietly insert links into your content. Which is why the symptom is rarely a defaced homepage — it is a warning in Search Console, or a customer saying your site sent them somewhere strange.

The numbers, since WordPress runs most of the web

From 2025–2026 vulnerability reporting: over 11,000 new vulnerabilities were catalogued across the WordPress ecosystem in 2025, up more than 40% year on year. Ninety-one percent of them were in plugins and nine percent in themes — the core itself accounted for a handful, all low risk. Roughly 13,000 WordPress sites are compromised daily, and the median time from public disclosure to mass exploitation is about five hours.

Two conclusions follow, and they are the whole article in miniature. Your risk is proportional to how many plugins you installed, not to how popular your business is. And "I will update it next month" is not a delay — on that timescale the vulnerability window has opened and closed several times.

Five habits that prevent most of it

1. Update on a schedule. Once a week, ten minutes: core, plugins, themes. Turn on automatic updates for security releases if nobody is going to do it manually.
2. Delete what you do not use. Every deactivated plugin and unused theme is still code on your server. Fewer plugins is the single most effective security decision available to a non-technical owner.
3. Separate, unique admin passwords plus two-factor authentication. Do not share one login among a designer, an agency and yourself — when someone leaves, you cannot tell whose access to revoke.
4. Backups you have actually restored. An untested backup is a belief, not a backup. Restore one into a test copy once, so you know how long it takes and what is missing.
5. HTTPS everywhere, with the certificate renewing automatically. This is free and takes minutes; browsers now flag anything with a form on it as unsafe without it.

Security headers, and the honest part about them

Headers are instructions your server sends with every page telling the browser what is allowed. Two of them are worth knowing by name.

HSTS tells browsers never to open your site over plain HTTP again. Straightforwardly good — with one clause worth understanding. If you enable it with the option covering all subdomains, you are promising that every future subdomain will also have a valid certificate, and browsers remember that promise for months. I turned it on for this domain, and the consequence is real: a quick test subdomain without a certificate can no longer be spun up here. Nothing broke, but it is a commitment, not a checkbox.

A Content Security Policy lists which sources of scripts, styles and frames are allowed, which kills most injected-script attacks outright. It also breaks things, and the breakage is never where you expect. On this site the policy included a rule permitting only our own pages to embed us in a frame — sensible, and it silently disabled a map view inside our own analytics dashboard, because that feature works by loading our page inside the analytics provider’s frame. It looked like the provider was broken. It was our header.

Which is the practical advice: add a policy, then check every embedded thing you own — maps, videos, payment widgets, chat, analytics. Whatever silently stops working is what the policy just blocked.

Forms deserve their own paragraph

A public form is the one door you deliberately left open. Three cheap measures handle nearly all abuse: a hidden field humans never fill in and bots always do, a limit on submissions from one address per hour, and server-side validation of everything — never trusting what the browser sent. Also make sure the form cannot be used to send arbitrary email to arbitrary recipients; that mistake turns a contact page into someone else’s spam relay.

A form also creates an obligation of a different kind: from the moment it collects a name and an email, your site is processing personal data and has to say so somewhere.

The legal pages a website needs, and the ones it does not

How you would even find out

Assume you will not notice on your own. Cheaper hosting plans often provide no access to raw server logs at all — that is the case on the plan this site runs on, and it was discovered when the logs were needed rather than before. Which leaves a small kit that works without them:

• Search Console: it emails you when a site is flagged for malware or unwanted software, and shows sudden appearances of pages you never created.
• Your own request log inside the site. If the host will not give you logs, record what matters yourself — the entries you keep are the ones you will need.
• Uptime monitoring, so you learn about downtime from a notification instead of a customer.
• A monthly look at the list of users with access. Accounts you do not recognise are a finding all by themselves.

If it already happened

1. Take the site offline or into maintenance mode. Every hour it stays up spreads whatever it is doing.
2. Change all passwords, including the hosting account and any FTP or database users, from a clean device.
3. Restore the most recent backup from before the incident. Cleaning an infected site by hand is a specialist job and rarely complete.
4. Update everything before putting it back online, otherwise the same hole gets used again within the day.
5. Ask for a review in Search Console if you were flagged, and check that no unfamiliar admin users remain.

For a small business, the reported average cost of recovering from an incident runs into five figures — mostly other people’s time and lost sales, not ransom. Compared to that, the whole prevention list above costs a few hours a year.

Website maintenance: what it is and what it should cost

What is enough for a small site

• HTTPS on, renewing automatically.
• Updates weekly, unused plugins and themes deleted.
• Unique admin passwords, two-factor authentication, no shared accounts.
• Automatic backups kept somewhere other than the same server, restored once to prove they work.
• A form with a honeypot, rate limiting and server-side validation.
• Uptime and Search Console notifications going to an address someone reads.

That list is not exhaustive security. It is the part that removes you from the population scripts are looking for, which for a small site is most of the job.