In my experience, small business website security is rarely about a hacker who picked you. It is about automated scripts that try every login page, every contact form and every outdated plugin they can find, all day, on every site. The good news is that the basics that stop most of that traffic are cheap, unglamorous and mostly about who holds the keys, not about buying a product with “shield” in its name.
This is the checklist I run when I take over a site or launch a new one. It pairs with my guide to what website maintenance includes, which covers updates and backups. This one covers accounts, forms, secrets, headers and email.
What actually goes wrong on small sites
The OWASP Top 10:2025, OWASP’s ranking of the most critical web application security risks, puts Broken Access Control first, Security Misconfiguration second and Software Supply Chain Failures third. For a small business, that means:
- Access control: someone logs in who should not be able to, because a former contractor still has an admin account, a password was reused, or a page that should need a login does not.
- Misconfiguration: a staging site left public, debug mode left on, an admin login with no rate limit.
- Supply chain: the plugin, theme, package or embedded script you did not write has a hole, and you inherit it.
None of these need a clever attacker, just an unlocked door. The checklist below is ordered by how often I find each door open.
1. Lock down the accounts that control your site
Your website is really a chain of accounts: the domain registrar, DNS, hosting, the CMS or code repository, the form tool, analytics, and the email inbox that can reset all of them. The weakest one decides your security.
- List every account that can change the site, its domain or its email, with who has access to each.
- Make sure the business owns them. Registrar and hosting should sit under a company email, not a former agency’s or freelancer’s login.
- Remove people who left. Old staff and past contractors pile up in CMS admin lists and hosting teams. Anyone who only edits content should be an editor, not an administrator.
- Use long, unique passwords from a password manager. The FTC’s Cybersecurity for Small Business guidance says a strong password is at least 12 characters. CISA now sets the bar higher, recommending passwords at least 16 characters long, unique to each account, and a company-wide password manager so nobody has to remember them.
- Turn on multi-factor authentication everywhere it exists. CISA’s advice is simply to turn on MFA for every account or app that offers it. Start with the registrar, hosting and email, because those three can take everything else with them.
On the type of MFA: an authenticator app or a hardware security key beats a text message code, because people can be tricked into handing codes over. CISA’s write-up on USDA’s FIDO rollout explains why: attackers can trick people into handing over one-time and SMS codes, while FIDO uses cryptographic keys on the device, and CISA notes that FIDO and PKI are the only non-proprietary MFA methods that stop attackers tricking users into revealing authentication secrets. For a small team, hardware keys on the registrar and email accounts, and an authenticator app everywhere else, is a sensible split.
Also check that your domain is locked. ICANN explains that a domain can be locked to protect against unauthorized changes, a status often labelled Registrar Lock or Client Transfer Prohibited. If yours is not, ask your registrar to turn it on, and keep it on except during a transfer you started.
2. Shrink what can be attacked
Every plugin, theme, package, admin page and third-party script is a door someone has to keep locked. The cheapest security work is removing doors you do not use.
On WordPress
WordPress’s own hardening guide says to keep plugins updated and, if you are not using a plugin, to delete it from the system, and to stick to the WordPress.org repository or well known companies. Deactivated is not the same as deleted: the files are still on the server. The same guide shows how to disable the built-in theme and plugin file editor with define( 'DISALLOW_FILE_EDIT', true );, so a stolen admin login cannot be used to paste code straight into your theme. I set it on the WordPress sites I look after.
My rule: if you cannot say in one sentence what a plugin does for a customer, it goes.
On coded sites and site builders
A Next.js or other coded site has no plugin dashboard, but it has dependencies, and that is exactly the supply chain risk OWASP ranks third. Keep packages few, review them before adding, and apply security releases quickly. A hosted builder like Squarespace or Wix patches the platform for you, which is a real advantage, but you still own the accounts, the embedded scripts and the forms.
Embedded scripts (chat widgets, heatmaps, old ad pixels, review badges) run with the same power as your own code. Remove the ones nobody has looked at in a year.
3. Treat every public form as hostile
For most small businesses, the contact or quote form is the only place a stranger can write data into your systems. It is also where bots spend their time. On the PrintVision rebuild, both public forms feed straight into the client’s own ERP, so I treated every public write path as hostile from day one:
- Bot detection and per-IP rate limiting on both endpoints, so a script cannot submit a thousand fake quotes a minute.
- The privileged database call runs server-side only. I moved it behind a server route so the ERP team can revoke the public grant without taking the website down.
- The service key client is created per request and never keeps a login session, which matters in serverless functions where instances get reused between visitors.
Most sites do not need all of that, but every site needs the principle. A short version for any form:
- Validate every field on the server, not only in the browser. Browser checks are for the visitor’s convenience; anyone can bypass them.
- Add a bot check and a rate limit. Most form tools and hosts offer both.
- Avoid file uploads unless you need them. If you do, OWASP’s File Upload Cheat Sheet says to allow only the extensions the business actually needs (a CV form might accept only docx and pdf) and to set a file size limit.
- Do not email full submissions to shared inboxes if they contain anything sensitive. Store them in one place with access control, and send a notification instead.
4. Keep secrets out of the browser
API keys are passwords. If they end up in JavaScript sent to the browser, anyone can read them in the browser’s developer tools.
The most common way I see this happen on coded sites is a naming mistake. In Next.js, the environment variables documentation explains that variables are only available on the server by default, and that prefixing one with NEXT_PUBLIC_ inlines its value into the JavaScript bundle delivered to the client at build time. That prefix is fine for a public analytics ID. It is a leak for a secret key. Ask your developer which variables are public and confirm none are secrets.
Two more rules: secrets never go into the code repository, and when someone with access leaves, you rotate the keys they could see, not just remove their login.
5. HTTPS, HSTS and a few headers that matter
HTTPS is non-negotiable. The FTC’s advice on hiring a web host says the service you choose should include TLS, which protects your customers’ privacy and helps them reach your real site. Make sure every page, including old ones, redirects to the HTTPS version. My technical SEO checklist covers the redirect side, since it affects rankings too.
Once HTTPS works everywhere, two response headers are worth adding:
- Strict-Transport-Security (HSTS) tells browsers to only use HTTPS for your site from then on and to stop visitors clicking past certificate errors, as MDN’s HSTS reference explains. Start with a short max-age, then raise it. Hold off on the
preloaddirective: MDN notes it requires a max-age of at least one year plusincludeSubDomains, so every subdomain you own must work over HTTPS first. - Content-Security-Policy (CSP) controls which scripts a page may load. MDN’s CSP guide describes it mainly as a defence against cross-site scripting, and documents a
Content-Security-Policy-Report-Onlymode that reports violations without blocking anything. Use report-only first. A strict policy switched on in one go breaks analytics and widgets, and then someone deletes it.
If your site builder does not let you set headers, do not switch platforms over it. Accounts and forms matter more.
6. Protect the email that uses your domain
Scammers will happily send invoices “from” your domain. The same FTC web host guidance names three email authentication tools your host or email provider should support: SPF, DKIM and DMARC. In plain terms, SPF lists which servers may send mail for your domain, DKIM signs your messages, and DMARC tells receiving servers what to do when a message fails those checks.
This is also a deliverability issue, not only a security one. Google’s email sender guidelines require all senders to Gmail to set up SPF or DKIM, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC. If your website’s contact form sends notifications from your domain through a third-party service, that service needs to be included in these records, or your own lead notifications start landing in spam.
7. Write a one-page plan for a bad day
Write one page: who to call, where the backups are, who can log in to the host and registrar, and who talks to customers. The FTC’s Data Breach Response guide adds two points owners often miss. First, change credentials: if a hacker stole them, your system remains vulnerable until you change them, even after their tools are removed. Second, do not destroy forensic evidence while you clean up. The guide also says that if personal information was improperly posted on your website, you should remove it immediately and contact search engines so they do not archive it. The same guide notes that every state, plus DC, Puerto Rico and the Virgin Islands, has a breach notification law. The details differ by state, so if customer data was involved, bring in a lawyer early.
A small business website security checklist
| Task | How often | Done when |
|---|---|---|
| Account inventory and ownership check | Twice a year | Every account is in the business’s name, with current owners listed |
| Remove former staff and contractors | On every departure | Logins removed and any keys they saw rotated |
| MFA on registrar, host, email, CMS, repo | Once, then on new accounts | No admin account signs in with a password alone |
| Delete unused plugins, themes and scripts | Quarterly | Each remaining one has a stated purpose |
| Form bot check, rate limit, server validation | At launch, then on form changes | A test with junk input is rejected server-side |
| Secrets review | At launch and on each new integration | No secret key in public variables, code or the repo |
| HTTPS redirects and HSTS | At launch, then yearly | Every URL and subdomain loads over HTTPS |
| CSP in report-only, then enforced | Once, then on new scripts | Reports show only expected sources |
| SPF, DKIM and DMARC | Once, then on new email tools | Every sending service passes |
| Bad-day plan | Yearly | One page, stored outside the website and its host |
What I would not spend money on
- Trust badges and “secured by” seals. They secure nothing.
- Stacking security plugins. One well maintained security or firewall layer is reasonable on WordPress. Three overlapping ones just add code to patch.
- Enterprise tooling before the basics. A monitoring dashboard is the wrong first purchase when the registrar has no MFA.
Where I would not cut corners: any site that takes logins or payments, or collects health, financial or identity data. Those need someone accountable for security, in writing.
Frequently asked questions
Do small business websites really get hacked?
Yes. In my experience the traffic hitting small sites is bots trying leaked passwords, probing for known plugin flaws and flooding forms, which is why MFA, fewer plugins and form rate limits stop most of it.
Is HTTPS enough to make my website secure?
No. HTTPS protects data in transit between the visitor and your site. It does nothing about a weak admin password, an outdated plugin or a form that accepts anything.
What should I do first if my site is hacked?
Change passwords on the host, registrar, CMS and email from a clean device, turn on MFA if it was off, and call whoever maintains the site. Keep logs and copies of what changed instead of wiping everything, as the FTC advises, then restore from a backup taken before the problem started.
Want someone to check the locks?
I build sites with these basics in place from the first commit, and I review inherited sites against this same list. If you want an honest read on where yours stands and what to fix first, see my services or get in touch.
