Small business websites are rarely attacked by someone who has picked them out. They are hit by automated tools that look for the same handful of gaps on thousands of sites at once. That is good news, because closing those gaps does not need a security team. It needs a checklist and an afternoon.
This is that checklist: what to look at, what to ask your developer, and what each item protects you from.
HTTPS everywhere
Every page should load over HTTPS, and the plain HTTP address should redirect to it. That is the padlock in the address bar. It stops someone on the same Wi-Fi network from reading or changing what your visitors send and see, including the contact form.
Certificates are free from most hosts and renew themselves. If yours expires, browsers show a frightening warning page, and visitors leave. Check that renewal is automatic.
Six response headers worth having
Your server can send small instructions with every page, called response headers, that tell the browser to be careful. OWASP, the foundation that maintains the best-known list of web security risks, recommends these.
Strict-Transport-Security tells browsers to use HTTPS only for your site, with a value such as max-age=63072000. X-Content-Type-Options set to nosniff stops browsers guessing what a file is. Referrer-Policy set to strict-origin-when-cross-origin limits how much of your visitors' browsing is passed on to other sites. Permissions-Policy switches off browser features you do not use, such as the camera or microphone. X-Frame-Options set to DENY stops other sites from showing yours inside a frame, which is how clickjacking works. Content-Security-Policy restricts where scripts and other content may load from, which limits the damage if something malicious gets onto a page. It is the most powerful and the one that needs the most care, because a policy that is too strict breaks the site.
Equally, remove headers that tell attackers what you run. OWASP advises dropping the Server and X-Powered-By headers, or giving them a non-informative value.
You can look at your own headers in the browser's developer tools, under the Network tab, by clicking the first request. A site that was built carefully will already send most of them.
Updates
Most successful attacks on small sites use a known flaw in software that has not been updated: a content management system, a plugin, a theme. The fix usually exists already. Know what your site runs, and who is responsible for updating it, and how often.
Fewer parts means fewer things to update. Every plugin you remove is a door you no longer need to lock. A site built without a large stack of third-party code is simpler to keep safe.
Logins and access
Use a password manager and a different long password for every admin login, and switch on two-step verification wherever it is offered, especially for your hosting account, your domain registrar and your email. Stolen or reused passwords are a far more common way in than clever hacking.
Give each person their own account, and remove people who have left. Share the least access a person needs to do the job.
Backups you have tested
A backup you have never restored is a hope, not a backup. Make sure there are regular copies of the site and its data, stored away from the server itself, and that someone has tried bringing one back at least once. If the worst happens, this is what turns a disaster into a bad afternoon.
This is general guidance, not a security audit. If you take payments, store customers' personal data or run a custom application, ask for a proper review.