Most hacked websites I've been called in to clean up weren't targeted by anyone. There was no shadowy figure who chose them, no competitor paying for sabotage, nothing personal at all. A bot scanned ten thousand sites in an afternoon, found the one running an outdated plugin with an admin password from 2019, and walked in through the front door. The owners always ask me the same question, why us, and the honest answer is usually: because you were the easiest one that day.
That reframing matters, because security for a small business site isn't about being impenetrable. Nation-states are not coming for your booking system. It's about not being the easiest door on the street, and the gap between easiest and average is smaller than most owners think. What follows is the checklist I run before any project of mine goes live, in the order of what actually gets sites breached.
Dependencies come first because outdated packages are the number one way in. Modern sites are assembled from hundreds of open-source pieces, and every few weeks one of them announces a vulnerability along with the fix. From that moment, every bot on the internet knows exactly what hole to look for, and the only question is whether you patched before they found you. Turn on automated dependency alerts, and more importantly, actually act on them within days, not quarters. Unpatched is unlocked.
Secrets are next, and this one still surprises me every time I audit a codebase. API keys, database passwords, and payment credentials belong in environment variables on the server, never in the code itself. I still find live database credentials sitting in repositories, sometimes public ones, where they've been quietly indexed and scraped months ago. If a secret has ever touched your codebase, treat it as leaked and rotate it. That's an hour of annoying work against a very bad morning.
The admin panel deserves its own paragraph because it's under attack right now, whoever you are. Look at the access logs of any website that's been online for a week and you'll find bots hammering /admin and /wp-login around the clock, trying credential lists from old breaches. The defenses are unglamorous and effective: rate-limit the login so a bot gets five tries and a long timeout instead of five thousand tries, require strong passwords, and add two-factor authentication if your platform supports it. Watch your own logs once and you'll never skip this step again.
Input validation is the quiet one. Everything a user can type, a form field, a search box, a URL parameter, has to be validated on the server, not just in the browser, because attackers don't use your pretty form, they talk to your server directly. Anything that touches your database or gets rendered back onto a page is a weapon until proven otherwise. This is the family of holes behind most of the famous breaches, and the defense is mostly discipline: never trust, always check, and let your framework's built-in protections do their job instead of working around them.
Backups are the item everyone nods at and nobody tests. Automated, stored somewhere other than the server they're backing up, and, this is the part that separates real backups from theater, actually restored at least once so you know the process works and how long it takes. A backup you've never restored is a rumour, not a backup. When something does go wrong, and across enough years something always does, the difference between a bad hour and a bad month is whether yesterday's copy of everything actually loads.
HTTPS everywhere, sensible security headers, and locked-down file uploads round out the list, and they're worth doing, but the five above stop the attacks that actually happen to small business sites.
None of this takes more than a day to set up on a well-built site. Cleaning up after a breach takes weeks, costs real money, and ends with the email nobody wants to write, the one to your customers explaining what leaked. I know which day I'd rather bill for.
Want this checklist run against your site? Book a security review — it takes a day, not weeks.