A website security checklist to use before launch

Most attacks on small business websites are not clever. They use a password that was reused, a plugin that was never updated, an admin page that anyone can reach or a backup that does not exist. A short checklist before launch removes most of that risk. No checklist makes a site immune, so this note also covers what to do when something goes wrong. The aim is a site that is hard to break into and quick to recover.

1. Encrypt every connection

• Serve the whole site over HTTPS, and redirect every HTTP address to HTTPS.
• Turn on HTTP Strict Transport Security (HSTS) once you are sure HTTPS works everywhere, so browsers stop trying plain HTTP. The MDN page explains the header and its risks, such as a mistake locking visitors out.
• Renew certificates automatically and check that they do.

2. Protect the accounts that can change the site

• Give each person their own account. Shared logins make it impossible to tell who did what, or to remove one person safely.
• Require two-step verification for every administrator, preferably with an authenticator app rather than text messages.
• Use long, unique passwords. The UK's National Cyber Security Centre (NCSC) recommends combining three random words, and a password manager makes unique passwords practical. Its guidance for small organisations is written for people who are not technical.
• Give people only the access their job needs, and remove access the day someone leaves.
• Limit login attempts and notify people of unusual sign-ins.

3. Keep everything up to date

• Update the platform, themes, plugins and libraries. Known flaws in old versions are what automated attacks look for first.
• Remove plugins, themes and test sites you do not use. Code that is not installed cannot be exploited.
• Decide who is responsible for updates and how often they are checked. An update plan that nobody owns does not happen.
• Buy software and extensions from sources that still maintain them.

4. Back up, and prove you can restore

• Take regular copies of the files and the database, and keep at least one copy away from the server that hosts the site.
• Protect the backups themselves with a password or encryption and limited access.
• Do a test restore before launch and then at intervals. A backup that has never been restored is only a hope.
• Write down how long a restore takes, so you know what a bad day costs.

5. Close the common web holes

The OWASP Top 10 lists the most widespread web application risks. For a typical business site, the following checks cover a lot of ground:

• Validate and escape everything. Treat every form field, URL parameter and uploaded file as untrusted. Use the framework's built-in protection against SQL injection and cross-site scripting rather than writing your own.
• Protect forms against forgery. Use anti-forgery tokens on every form that changes something.
• Restrict uploads. Allow only the file types you need, check their real type, store them outside the executable path and limit their size.
• Add security headers. A Content Security Policy limits where scripts can load from; X-Content-Type-Options: nosniff, a sensible Referrer-Policy and frame restrictions close other gaps. The MDN guide to CSP is a good place to start.
• Limit what errors reveal. Visitors should see a friendly message, never a stack trace, file path or database error.
• Rate-limit logins, contact forms and anything that sends email, to slow down abuse.
• Hide what is not public. Admin areas, backups, .git folders, configuration files and test pages must not be reachable from the internet.

6. Handle data with care

• Collect only the data you need, and delete it when you no longer need it.
• Keep secrets such as database passwords and API keys out of the code and out of public repositories.
• Use a separate account with minimal rights for the website's database connection.
• If you handle personal data, know your duty to report a serious breach. Under UK GDPR, that is generally to the Information Commissioner's Office within 72 hours of becoming aware of it, where the breach is likely to put people's rights at risk.

7. Watch, log and be ready

• Keep logs of sign-ins, errors and admin changes, and keep them long enough to investigate.
• Set up uptime monitoring so you hear about an outage before your customers do.
• Write a one-page response plan: who to call, how to take the site offline, where the backups are, who talks to customers. Practise it once.

8. Check before you go live

1. Sign in as a normal user and try to reach an admin address. It should be refused.
2. Try submitting each form empty, with very long text and with special characters.
3. Look at the response headers in the browser's developer tools.
4. Restore a backup to a separate location.
5. Check that the test content, test accounts and debugging settings are gone.
6. Ask someone who did not build the site to try to break it.

When to get a professional test

If the site holds sensitive data, takes payments directly or is critical to your business, an independent security review is worth paying for. A proper test is done only with the owner's written permission and an agreed scope, and ends with a plain report of what was checked, what was found and what to fix first. For a wider baseline across your organisation, the NCSC's Cyber Essentials scheme covers five technical controls and offers a certificate that some customers ask for.