Website security: the practical minimum for a small business

Start by asking what you are protecting

A landing page with a contact form and a service storing accounts, documents and orders need different levels of protection. The shared baseline is simple: minimise access, keep secrets private, update dependencies and plan for failure.

1. HTTPS only for public sites

Login forms, cookies and personal data should not travel in plain text. Configure TLS and redirect HTTP to HTTPS. Most modern platforms can renew certificates automatically.

2. Long unique passwords and MFA for admins

Password reuse turns one external breach into access to multiple systems. Administrative accounts should use MFA, and teams should use a password manager instead of a shared spreadsheet.

3. Secrets do not belong in frontend or Git

Database credentials, SMTP passwords, session secrets and private tokens belong in environment variables or secret storage. Anything shipped to browser JavaScript must be treated as public.

4. Check permissions on the server

Hiding an “Delete order” button from normal users is good UX, not security. The backend must verify the user role for every privileged request, because an attacker can call the API manually.

5. File uploads need their own threat model

• Limit file size.
• Validate content, not only the extension.
• Do not trust the original filename.
• Store user files separately from executable application code.
• Use malware scanning/quarantine for risky formats.
• Authorise every private download.

6. Validate forms on the backend and rate-limit abuse

Frontend validation improves usability but can be bypassed. Re-check email, length, required fields and allowed values on the server. Login, password reset and public forms should also have sensible request limits and spam protection.

7. Keep the system updated

An outdated CMS, plugin or dependency with a known vulnerability is an obvious entry point. Regularly review updates, critical security notices and unused dependencies.

8. Backups must exist before the incident

Backups protect against more than hacking: failed migrations and accidental deletion are common. Copy both database and user files, and test restoration at least once.

9. Logs explain what happened

Keep server errors and important administrative events, but do not log passwords, raw tokens or unnecessary personal data. Logs should help investigate an incident, not create a second leak.

A minimum pre-launch checklist

• HTTPS and secure cookies.
• Secrets only in environment/secret storage.
• Admin endpoints check roles server-side.
• MFA for administrators.
• Forms and uploads validated in backend.
• Backups and a tested restore path.

10. Treat a session like the key to an account

Browser sessions should use secure cookie settings, a reasonable lifetime and invalidation after password changes. Administrator sessions can justify stricter rules than ordinary customer sessions.

11. Do not collect data “just in case”

The less sensitive data you store, the smaller the impact of a breach. If a birthday is not required to fulfil an order, do not ask for it. Define retention periods for uploaded files instead of keeping everything forever.

12. Decide what to do during an incident

Even a short plan helps: who is notified, how to disable a risky function, where secrets are rotated, how sessions are revoked, where backups are restored from and which logs must be preserved.