Privacy and security basics for small web products

A baseline, not a fortress

Small teams rarely have a dedicated security function, and they do not need one to avoid the most common problems. Most incidents affecting small websites come from a short list of causes: leaked passwords or keys, outdated software, overly broad access, and data that was never needed in the first place.

The practices below are the baseline we apply to our own sites and applications. None of them require specialist tools.

Collect less data

Data you never collect cannot leak. For every form field, ask whether the product genuinely needs it, and for how long. A contact form needs a way to reply; it rarely needs a date of birth or a full address.

• Delete or anonymise data you no longer need, on a schedule rather than 'one day'.
• Let a payment gateway hold card details instead of storing them yourself.
• Avoid writing personal data or secrets into application logs.

Encrypt traffic everywhere

Serve every page over HTTPS, not only login and payment pages, and redirect plain HTTP requests to HTTPS. Free, automatically renewed certificates make this straightforward. Once HTTPS works reliably, enable HTTP Strict Transport Security (HSTS) so browsers refuse to connect insecurely.

Mark session and authentication cookies as Secure and HttpOnly so they are never sent over plain HTTP or exposed to page scripts.

Keep secrets out of code

API keys, database passwords and payment gateway secrets should live in environment variables or a secrets manager, never in the source repository. Commit an example configuration file with placeholder values so new developers know what to set, and add the real file to .gitignore.

If a secret is ever committed, assume it is compromised: rotate it with the provider immediately. Deleting it from the latest commit does not remove it from the repository's history.

Use your framework's protections

Mature web frameworks include defences against the most common attacks, as long as you do not switch them off. Django, which this website is built with, provides CSRF protection for forms, automatic escaping of template output against cross-site scripting, and a query layer that prevents SQL injection when used normally. Its deployment checklist command (manage.py check --deploy) flags insecure settings before you go live.

Limit access and keep software current

• Give each person and service only the access they need, and remove access promptly when someone leaves a project.
• Turn on two-factor authentication for hosting, domain, email and code-hosting accounts. These are the keys to everything else.
• Keep the admin interface on a non-obvious path or behind additional access controls where possible.
• Update dependencies regularly and watch for security advisories for the libraries you use.
• Separate development and production environments, with different credentials.

Back up, and test the restore

Backups protect against mistakes as well as attacks: a wrong migration or an accidental deletion. Store backups separately from the main server, encrypt them, and periodically restore one into a test environment. A backup that has never been restored is a hope, not a plan.

For details of how this website handles visitor information, see our Privacy Policy.