Website security: 10 things small teams actually need to do

Most small teams treat security as something you buy. In the real world, sites fall over not to zero-days but to an unpatched plugin, a shared password and a backup nobody ever tried to restore.

None of the following is expensive. All of it requires discipline.

1 · Shrink the attack surface

The most effective security measure is code that does not exist. If no part of your site runs on the server, that part cannot be exploited.

This is why a statically generated site is structurally safer: no database, no admin login, no interpreter running. If you do need server-side logic, compress it into a single endpoint and defend that one well.

Delete every plugin, library and subdomain you do not use. The thing kept “in case we need it” is the thing that breaks first, because nobody updates it.

2 · Do not leave updates to chance

Most breaches exploit known vulnerabilities whose patches shipped months earlier.

Put it on the calendar: one fixed day a month to update dependencies and run the tests. Turn on automated dependency alerts. Separate security patches from routine updates and do not make them wait.

3 · Test the restore, not the backup

“We have backups” is not an assurance. The assurance is when you last tried restoring one.

Backup files can be corrupt, the database schema can mismatch, the media folder may never have been included. Learning this for the first time during an incident is close to having no backup at all.

Every quarter, restore into a separate environment and watch the site come up. Keep backups somewhere other than the production server, so a compromise does not take them too.

4 · Tie access to people

A shared admin account makes it impossible to know who did what, and leaves an open door when someone leaves the team.

• One account per person.
• Two-factor authentication mandatory — especially on domain, hosting and repository accounts.
• Least privilege: not everyone needs to be an administrator.
• Revoke access the same day someone leaves.

Your domain registrar account is the most critical asset you own. Lose it and everything, including your email, can be redirected.

5 · Set your security headers

A handful of HTTP headers close whole classes of attack. On a static site this is usually one configuration file:

• Content-Security-Policy — restricts where scripts may load from. The most effective and the most skipped.
• X-Content-Type-Options: nosniff
• X-Frame-Options or CSP frame-ancestors — stops your site being embedded elsewhere.
• Strict-Transport-Security — tells browsers to use HTTPS only.
• Referrer-Policy: strict-origin-when-cross-origin

Roll CSP out in report-only mode first, see what it breaks under real traffic, then enforce it.

6 · Close your forms to abuse

If your site has a form, that form is an email-sending tool, and bots know it.

Rate-limit server-side, add a honeypot field, cap field lengths, and escape submitted content before it reaches an email body. Validating only in the browser is not validating.

7 · Keep secrets out of the code

API keys, database passwords and tokens belong in environment variables, not in the repository.

A key that has been committed once stays in the history even after you delete the file. If it happens, deleting the file is not enough — revoke the key and issue a new one. Add a secret-scanning step to CI to stop it recurring.

8 · Count your dependencies

A modern project can carry thousands of transitive dependencies. You cannot read them all, but you can:

• Pin versions.
• Run automated security audits.
• Consciously approve packages that run install scripts.
• Delete two of the three libraries doing the same job.

9 · Keep logs, and keep them long enough

After an incident the first question is “when and how did they get in”. With no logs there is no answer.

Record access logs, admin logins and failed login attempts. Retain them for at least a few months — breaches are usually discovered weeks after they happen.

10 · Write the incident plan in advance

Nobody improvises well during a crisis. One page is enough:

• If we suspect a compromise, who takes the site into maintenance mode, and how?
• In what order do we rotate domain, hosting and repository credentials?
• If personal data leaked, who files the regulatory notification, and within how many hours?
• When, and by whom, are customers told?

Writing this takes half an hour and saves hours when it matters.

Priority order

If you cannot do it all in one day, work in this order: access management and 2FA → a restore test → update discipline → security headers → form protection.

The first two cover the majority of what actually happens in the real world.