Website security is sold badly. Small businesses get pitched enterprise threat monitoring for a five page marketing site, or nothing at all until the day the site starts serving pharmacy spam to Google. The real list of what a normal business website needs is short, mostly free, and mostly ignored.
HTTPS, correctly, everywhere
A certificate is table stakes and every serious host issues one free. What gets missed is enforcement: HTTP requests should redirect to HTTPS at the server, in one hop, and the site should send a strict transport security header so browsers refuse to try the insecure version at all.
Then check for mixed content, which is the usual reason a padlock disappears after a redesign. One image or script loaded over HTTP on one page is enough to break the whole impression, and it is trivially fixable.
While you are in the server config, look at whether both the www and bare domain resolve to one canonical version. That is an SEO fix and a security hygiene fix at once, and it belongs on any pre launch pass.
Security headers cost nothing and stop a lot
A handful of response headers close off the most common browser side attacks, and most sites send none of them.
A content security policy is the significant one: it declares which sources of scripts, styles, frames, and images are allowed, so an injected script from somewhere else simply does not run. It takes an afternoon to get right on a real site, mostly because you discover how many third party tags marketing added. X content type options stops browsers guessing file types, referrer policy stops leaking full URLs to other sites, and a frame policy stops your pages being embedded inside someone else’s.
Nothing about this requires a subscription. It requires someone to write the config once and test it, which is the part that gets skipped.
The attack surface is usually a plugin
The overwhelming majority of compromised small business sites are running a well known CMS with out of date plugins. Not targeted, not sophisticated: automated scans looking for a known vulnerability in a version number, at scale.
So the highest value habit is unglamorous. Update core and plugins on a schedule rather than when something breaks, remove every plugin and theme you are not actively using (deactivated is not removed), and prefer fewer dependencies from maintainers who are still shipping. Each plugin is a supplier you did not vet, and most maintenance plans are worth judging on whether they actually do this.
This is also the strongest practical argument for a static build. A site rendered to HTML at build time has no database to inject, no admin login exposed to the internet, and no plugin executing code on request. The dynamic parts shrink to the few endpoints you deliberately wrote, which is a large part of why we build the way we do.
Logins are where most breaches actually start
Not exotic exploits, credentials. A reused password on a hosting account, or a CMS admin with the username “admin”, does more damage than any zero day.
The minimum: unique passwords in a password manager, two factor authentication on the hosting account, the domain registrar, and the CMS, and a real audit of who still has access. Agencies, ex employees, and that developer from three years ago frequently still have admin logins. Remove them. Give people the least access their job needs rather than administrator by default.
The registrar deserves special attention, because losing the domain is the one failure you cannot rebuild your way out of. Lock it, and keep the recovery email on an account you control.
Secrets never live in the repository
Any part of your site that sends email, calls an API, or talks to a payment provider has a credential. That credential does not belong in your code, in your repository, or anywhere under the public web root.
Environment variables, or a config file stored outside the served directory with restrictive permissions, are the standard answer. The test is simple: try to load the file by URL. If it returns anything but a 404, fix it today. And if a secret has ever been committed to a repository, rotate it rather than deleting the line, because the history keeps it.
Forms, spam, and the data you keep
Every public form is an invitation to bots. A honeypot field, basic rate limiting, and strict server side validation handle most of it without punishing real humans with puzzles.
Validate on the server always, not just in the browser, since client side checks are a convenience rather than a control. Escape anything you display back. And be deliberate about what you store: a contact form that emails you and keeps no database is a form that cannot leak one, which is the same minimalism that makes forms convert.
If you handle personal data, say so plainly in a privacy policy and delete what you no longer need.
Backups you have actually restored
An untested backup is a belief, not a plan. Know where backups live (somewhere other than the server they back up), how far back they go, and how long a restore takes. Then restore one to a staging environment and time it. The first time you attempt a restore should never be during an incident.
Pair that with basic monitoring: uptime, certificate expiry, and an alert if the site starts returning errors. It is the difference between discovering a problem yourself and hearing about it from a customer.
None of this is a project. It is an afternoon of setup and a habit, and it removes almost every realistic way a business website gets hurt.
Want yours checked over? hello@beconfidency.agency, and everything we build ships with this configured by default.
If you would rather have the build and its hardening owned by one team, that is exactly what our web development service is for.