Security basics for small sites

Most attacks on small sites are not personal. Bots scan the whole internet for old software, leaked passwords and open admin pages, and they find small sites the same way they find big ones. The good news: a few plain habits stop most of it. This is the list we use, in the order we would do it.

1. Keep everything up to date

Old software with a known hole is the most common way in. That means the CMS and its plugins, the web server, the operating system, and the libraries your code uses.

Turn on automatic security updates for the operating system.
Remove plugins, themes and apps you don’t use. Code that isn’t there can’t be attacked.
For code projects, let a tool tell you about vulnerable dependencies, for example GitHub’s Dependabot alerts.

2. Use HTTPS everywhere

Every page should load over HTTPS, and plain HTTP should redirect to it. Free certificates from Let’s Encrypt renew themselves, and most hosts and proxies set them up for you.

Once HTTPS works everywhere, add Strict-Transport-Security. It tells browsers to never try plain HTTP on your site again. Start with a short max-age and raise it once you are sure.

3. Protect the ways in

Use a password manager and a different, long password for every account: the host, the domain registrar, email, the CMS.
Turn on two-factor authentication wherever you can. The registrar and your email matter most, because whoever controls them can take over everything else.
Don’t leave admin pages, database tools or test copies of the site open to the internet.
Give each person and each tool only the access it needs.

4. Send a few security headers

Headers are cheap and help browsers protect your visitors. A good start for most sites:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;

The strongest one is a Content Security Policy (CSP). It lists where scripts, styles and images may come from, so injected code has nowhere to run. A strict CSP is easiest when you plan for it early. This site has no JavaScript, so its policy simply says script-src 'none'. You can check your headers with Mozilla’s HTTP Observatory.

5. Make backups you have tested

Backups protect you from attacks, from mistakes and from a host that disappears.

Keep at least one copy somewhere other than your server.
Back up the database and uploaded files, not only the code.
Try a restore once. A backup you have never restored is a hope, not a backup.

6. Look after your domain and DNS

Your domain is the root of everything. Lock it at the registrar, keep the renewal paid ahead of time, and turn on DNSSEC if your DNS provider supports it, so answers about your domain can’t be quietly forged. Delete DNS records that point to services you no longer use: a forgotten record can let someone else serve content on your name.

7. Let people tell you about problems

Sooner or later someone will find a bug and want to tell you. Make it easy:

Publish a security.txt file at /.well-known/security.txt with a contact address.
Answer reports politely, even short or clumsy ones. A person who reports a problem to you is doing you a favour.

8. Know what normal looks like

You don’t need a security team to notice trouble. Read your host’s alerts, glance at logs now and then, and set up a free uptime check. If the site suddenly sends spam, shows strange pages or gets much slower, look at it that day.

A short checklist

Updates on, unused code removed.
HTTPS everywhere, then Strict-Transport-Security.
A password manager and two-factor authentication on every important account.
Security headers and a Content Security Policy.
Off-server backups, and one test restore.
Registrar lock, DNSSEC, no stale DNS records.
A security.txt file and a friendly way to report problems.

If you own a site and want a second pair of eyes on it, you can ask us to check it.