Website security for small businesses: the attacks that actually happen

Every conversation we have about website security starts from the same misconception: that an attack would be a targeted, deliberate act by somebody who had decided to come after your business. It almost never is.

What actually happens is a script, running on a rented server, working through a list of millions of domains. It requests a handful of well-known paths on each one, notes the version numbers it finds, and compares them against a database of published vulnerabilities. If it finds a match, it exploits it, installs something, and moves on. Nobody chose you. Nobody has heard of you. The whole exchange took under a second.

Understanding that changes the question. It is not "why would anyone attack us?" — it is "would we notice, and how long would recovery take?"

What a compromise actually looks like

The dramatic defacement is rare, because it is worthless to the attacker. What we are usually called in to clean up is much quieter.

Injected spam pages. Hundreds of pages appear on your domain — usually about pharmaceuticals, gambling or counterfeit goods — invisible from your home page but indexed by Google. They exist to pass authority to somebody else's site. You find out when your search traffic collapses, or when Google adds a warning to your listing.

Conditional redirects. Visitors arriving from a search engine are sent somewhere else; anyone typing your address directly sees the normal site. This is deliberately designed so that the owner never sees the problem. We have seen this running for over a year, quietly diverting every new customer, while the business assumed the market had gone quiet.

Mail abuse. Your hosting is used to send phishing email. The immediate cost is that your domain's reputation is destroyed, so your genuine email starts landing in spam folders — including invoices and quotes. Recovering a domain's reputation takes weeks.

Cryptomining. A script is added that uses your visitors' devices to mine cryptocurrency. It makes the site sluggish and drains phone batteries. Visitors do not report it; they simply leave.

Data theft. Less common on a brochure site, but if you store enquiry data anywhere — a database, an unprotected export, an email archive on the same server — it is a target. This is the scenario with legal consequences attached.

The common thread is that none of these announce themselves. By the time the symptoms are obvious, the attacker has usually had months.

What it costs

For a small business, the direct cost of clean-up is rarely the largest number.

Search visibility. A hacked-site warning or a manual action can remove you from results within days. Getting back takes a clean-up, a reconsideration request and then patience. Rankings that took three years to earn do not return in three weeks.

Trust. A browser interstitial saying "Deceptive site ahead" is seen by every visitor, including existing customers and anyone who was about to enquire.

Time. Clean-up on a compromised site with no reliable backup is days of work, not hours, because you cannot be confident you have found everything. Frequently the only defensible answer is to rebuild.

Regulatory exposure. If personal data was accessible, UK GDPR gives you 72 hours to notify the Information Commissioner's Office from becoming aware of a reportable breach. Whether that clock has started is exactly the sort of judgement you do not want to be making at 9pm on a Friday without a plan.

How they get in

In our experience of cleaning up small business sites, the causes are boringly consistent.

An out-of-date plugin or theme. By far the leading cause. A vulnerability is published, a proof of concept follows within days, and automated scanning begins immediately. Sites that are patched within a week are largely fine. Sites patched within a year are not.

Unsupported platform software. An end-of-life PHP version, or a CMS major version that no longer receives security fixes. Common on sites where hosting has been left untouched for years.

Reused or weak administrator passwords. Your CMS password is the same as one from a service that was breached in 2019, and credential-stuffing tools do the rest. No amount of server hardening helps here.

No two-factor authentication on the CMS, the hosting control panel or the domain registrar. The registrar is the one people forget, and it is the most damaging to lose.

Insecure file uploads. A form that accepts attachments without validating type and content, storing them somewhere they can be executed.

Credentials in the repository. API keys and database passwords committed to a Git repository, sometimes a public one. Automated scanners look for exactly this, continuously.

Notice what is not on the list: sophisticated novel attacks. Almost all of it is known problems left unattended.

The measures that actually work

You do not need an enterprise security programme. You need a small number of things done properly and kept done.

1. Reduce what can be attacked

The most effective security decision is architectural: have fewer things that can be exploited.

A statically generated site has no database, no public login form, no plugin ecosystem and nothing executing code on request. That eliminates whole categories of attack rather than defending against them. It is a large part of why we build the way we do — not because it is fashionable, but because there is less to go wrong.

If you are on a database-driven CMS, the equivalent discipline is ruthless minimalism: every plugin you do not install is a vulnerability you cannot have. Audit what is installed and remove anything not actively earning its place.

2. Patch on a schedule, not on a whim

Somebody has to be responsible for applying updates and checking that nothing broke. Monthly is a reasonable cadence for routine updates, with same-week action on anything with a published exploit.

The checking matters as much as the updating, which is why it should happen on a preview copy first. "We update automatically" without verification is how sites break silently. Our maintenance service exists precisely because this is the job that never gets done in-house.

3. Turn on the browser's own protections

Modern browsers will enforce a great deal on your behalf, if the site asks them to. Most small business sites never do. The ones that matter:

• HTTP Strict Transport Security, so browsers refuse plain HTTP even from an old bookmark
• A Content Security Policy listing exactly which origins may serve scripts, styles and frames — the single most effective mitigation against cross-site scripting
• X-Frame-Options, so your pages cannot be embedded in somebody else's site for clickjacking
• X-Content-Type-Options: nosniff, so a file cannot be reinterpreted as something executable
• A restrictive Permissions Policy, switching off camera, microphone, geolocation and payment access the site has no use for

These are a few lines of configuration on any competent host. You can check yours in a minute at securityheaders.com.

4. Protect the forms

Your contact form accepts input from strangers and puts it somewhere that matters. Treat it accordingly: validate and sanitise on the server as well as in the browser, cap lengths, strip control characters, and never trust anything the client sends.

For spam, layer cheap defences rather than relying on one: a honeypot field invisible to real users, a per-client rate limit, and a scored challenge such as reCAPTCHA v3. We deliberately avoid checkbox and puzzle challenges, which are a genuine barrier for people with visual or cognitive impairments — accessibility and security should not be in tension.

5. Two-factor authentication, everywhere

CMS, hosting, domain registrar, DNS provider, email. Especially the registrar: losing control of your domain is considerably worse than losing control of your website, and much harder to unwind.

6. Backups you have actually restored

Three questions: where are the backups, how old is the newest one, and when did somebody last restore one successfully? If any answer is uncertain, you do not have backups — you have an intention.

Backups must live somewhere separate from the site. A backup on the same server as the site it protects is not a backup; ransomware and a hosting failure both take out the pair together.

Test a restore periodically. It takes an hour and it is the difference between a bad afternoon and a bad fortnight.

7. Write the plan down before you need it

One page is enough: who to ring, where the backups are, how to take the site offline safely, what to tell customers, and how to judge whether the ICO needs notifying. Nobody makes good decisions about this while adrenaline is involved.

What to check this week

If you do nothing else, spend an hour on the following.

1. Are you on supported software? Check your CMS version, and your PHP version if applicable. Anything past end of life is the most urgent thing on this list.
2. When were plugins last updated? If the answer is over three months, assume you are exposed.
3. Test a backup restore. Not "check backups exist" — restore one.
4. Enable two-factor authentication on hosting, domain and CMS.
5. Run your domain through a security header checker and fix what it flags.
6. Search Google for site:yourdomain.co.uk and look for pages you do not recognise. This finds injected spam pages fast.
7. Submit your own contact form and confirm the enquiry arrives where it should.

That last one is not strictly security, but silent form failure costs our clients more money than every other fault we find, and it takes two minutes to rule out.

If you think you have already been compromised

Do not delete things immediately — you will destroy the evidence needed to work out how they got in, which means it will happen again. Take the site offline or into maintenance mode, preserve a copy, then work out the entry route, clean or rebuild from a known-good backup, rotate every credential, and request review in Google Search Console if a warning has been applied.

Then close the original hole. A clean-up that does not identify the entry point is a temporary reprieve.

Getting help

We provide website security assessments, hardening, and clean-up after an incident, as well as managed hosting where all of the above is included and invisible. An assessment gives you a written summary ranked by real-world risk, with the things that genuinely matter separated from the noise that automated scanners like to flag.

If you are not sure how exposed you are — or you think something has already happened — get in touch or call 01420 446331. Say if it is urgent and we will treat it that way.