Website Security Basics for Small Businesses

Small business owners tend to assume nobody would bother attacking them. That assumption is reasonable and also wrong, because almost nothing that happens to a small website is personal.

The overwhelming majority of compromises are automated. Scripts crawl the internet looking for known-vulnerable software versions, exposed login pages and reused passwords. They do not know what your company does or care. Your site becomes a host for spam pages, a redirect to a scam, a mining script, or a staging post for sending phishing email. You usually find out when a customer mentions it, or when a browser starts showing a warning.

The good news is that the defences against automation are unglamorous and mostly free.

How sites actually get broken into

Four routes account for most incidents on small brochure and ecommerce sites.

Out-of-date software. A content management system, theme or plugin with a publicly disclosed vulnerability. Disclosure is the starting gun: once a fix is published, the flaw is documented, and scanning for unpatched installations begins within days.

Weak or reused credentials. An administrator password that also protects a forum account that was breached three years ago. Credential-stuffing tools try known email and password pairs at scale.

Abandoned extensions. A plugin installed once for a specific feature, deactivated but never deleted, whose author stopped maintaining it in 2021. Deactivated code still sits on the server and can still be reachable.

Compromise of someone’s computer. Malware on a laptop harvests the FTP credentials saved in the editor. The website was never attacked directly at all.

Notice what is missing from that list: sophisticated targeted intrusion. It happens, but it is not what is likely to happen to you.

The measures that do most of the work

Turn on multi-factor authentication for every administrator. This is the single highest-value change available and it neutralises credential stuffing almost entirely. Do it for the CMS, for the hosting control panel, for the domain registrar and for the email account those password resets go to. The registrar and the email account matter more than people expect: whoever controls them can redirect everything else.

Apply updates on a schedule you actually keep. Automatic updates for security releases are worth enabling on most small sites. The theoretical risk of an update breaking something is real, but it is a smaller risk than running vulnerable code for six months. Where automatic updates are not acceptable, book a recurring slot and treat it as non-negotiable.

Reduce the number of administrators. Give people the least access their job needs. An editor account for someone writing blog posts. A separate personal account for each individual, so access can be removed when they leave and so activity is attributable. Delete the shared “admin” login that four contractors know the password to.

Uninstall what you do not use. Every plugin, theme and integration is code you are responsible for. Deactivating is not removing.

Use a password manager. Long unique passwords for every service, generated rather than invented. This is more effective than any complexity rule.

Backups, which are the actual insurance

Prevention fails sometimes. Recovery is what determines whether that is an inconvenience or a disaster.

A usable backup arrangement has four properties. It runs automatically. It stores copies somewhere other than the server being backed up, because a compromised or failed server takes its local backups with it. It keeps enough history to reach back past the point where a problem started, since infections are frequently discovered weeks later. And it has been restored at least once, as a test, so you know it works and roughly how long it takes.

The last of those is the one everyone skips. An untested backup is a hypothesis.

If you take payments or store customer records, also be clear about what personal data those backups contain and how long you keep it, because retention is a data protection question as well as a technical one.

Certificates, headers and the visible layer

HTTPS is now the baseline and free certificates through Let’s Encrypt made it universal. Two things still go wrong: renewal failing silently on manually configured servers, and mixed content, where a secure page loads an image or script over plain HTTP and the browser complains. Redirect all HTTP traffic to HTTPS at the server level and check with an SSL testing tool once a year.

A few response headers cost nothing and remove entire categories of attack. Strict-Transport-Security tells browsers never to attempt an insecure connection to your domain. X-Content-Type-Options: nosniff stops browsers guessing file types. X-Frame-Options or a frame-ancestors policy stops your pages being embedded in someone else’s site for clickjacking. A Content Security Policy is more powerful and more work, because it needs tuning against everything your pages legitimately load.

Also configure SPF, DKIM and DMARC records for your domain. These are email authentication records, and their absence makes it far easier for someone to send convincing mail pretending to be you.

The first hour after a compromise

If you find spam pages, unexpected redirects or a browser warning, the order matters.

1. Take the site offline or into maintenance mode. Continuing to serve malware to visitors makes everything worse.
2. Change every administrator password, and the hosting, database, registrar and email passwords too. Force all sessions to log out.
3. Preserve a copy of the compromised site before cleaning it. You will want it to work out what happened.
4. Restore from a backup taken before the earliest sign of the problem, then patch whatever let them in. Restoring without patching invites an immediate repeat.
5. Check for persistence — added administrator accounts, scheduled tasks, modified core files, injected code in the theme.
6. Request a review in Google Search Console if the site was flagged.
7. If personal data may have been accessed, take advice quickly. UK data protection law sets short timescales for notifying the regulator about certain personal data breaches, and this is a point to get professional guidance rather than a blog post. Nothing here is legal advice.

What proportionate looks like

A five-page brochure site does not need a security operations centre. It needs multi-factor authentication, current software, off-site backups that have been tested, and a named person who notices when something is wrong.

Most small sites we look at have none of those four, and adding them takes an afternoon. That afternoon is the highest-return security work available, and everything more sophisticated should wait until it is done.

Keeping this in place month to month is what website development support should cover, rather than something you remember after an incident.