Website Security Basics Most Small Businesses Get Wrong

Nobody is running a sophisticated, targeted attack against most small business websites. What actually happens is automated bots scanning millions of sites a day for a handful of well-known, preventable mistakes, and moving on the instant they find one that isn't. Almost every incident we've been called in to clean up traces back to one of five things on this list.

The five doors that were never locked

1. 1Outdated plugins and dependencies — a CMS plugin with a known, published vulnerability that's been sitting unpatched for months, because nobody owns the job of updating it.
2. 2Default or weak admin credentials — "admin/admin123" is not a joke, it's a real password we've found on real client sites during an audit.
3. 3No HTTPS, or HTTPS misconfigured — beyond the browser warning, this exposes any form submission, login, or cookie to interception on public networks.
4. 4Unrestricted file uploads — a contact form or CMS that accepts any file type, which is exactly how an attacker gets executable code onto your server.
5. 5No backups, or backups nobody's tested restoring — the difference between a bad afternoon and a business-ending event when something does go wrong.

Why this matters even if you're "just a small business"

A compromised site doesn't need to hold anything valuable to be worth compromising. Attackers use hacked small business sites to host phishing pages, distribute malware, or send spam email under your domain's reputation — and Google will quietly blacklist a compromised site from search results long before you notice anything's wrong, which turns a security problem into an SEO problem overnight.

What a reasonable baseline actually looks like

• Dependencies and plugins on a schedule — updated monthly at minimum, immediately for anything marked critical.
• Unique, generated credentials for every admin account, with two-factor authentication turned on wherever it's offered.
• HTTPS enforced everywhere, with HTTP requests redirected, not just allowed to fall back.
• File upload validation — restricting type, size, and where uploaded files can execute from.
• Automated daily backups stored somewhere other than the server itself, with an actual test restore done at least once.

None of this requires a security specialist or a large budget — it requires someone treating it as a recurring task instead of a one-time setup step, which is the same discipline behind not skipping QA before a release.