Loading...
Small business websites get compromised through a small, repeatable set of mistakes. Here are the ten vulnerabilities we find most often, and how to fix each one.
Small business websites rarely get breached through some sophisticated, novel attack. Industry breach reports consistently point to the same small set of preventable mistakes: outdated software, weak credentials, and missing basic hardening. Automated scanners crawl the entire internet looking for exactly these gaps, so a small business site does not need to be a specific target to get compromised.
Here are the ten vulnerabilities that show up most often in our security audits, ranked roughly by how frequently we find them, along with the concrete fix for each.
WordPress alone powers a large share of the web, and the majority of WordPress compromises trace back to an outdated plugin or theme with a known, publicly disclosed vulnerability. Once a CVE is public, automated bots start scanning for unpatched sites within days.
Fix: enable automatic updates for minor CMS versions and security patches, review plugin updates weekly, and remove any plugin that hasn't been updated in over a year, since abandoned plugins are the highest-risk category.
Credential stuffing, trying leaked username/password pairs from other breaches, is one of the most common ways admin panels get compromised, because so many people reuse passwords across sites.
Fix: enforce a password manager for all admin accounts, require multi-factor authentication on every admin login, and rename or restrict access to default login URLs (like `/wp-admin`) where the platform allows it.
A web application firewall (WAF) filters malicious requests, SQL injection attempts, brute-force login attempts, known exploit patterns, before they reach the application at all. Sites without one rely entirely on the application code itself being flawless, which it never is.
Fix: put the site behind Cloudflare, Sucuri, or a hosting provider's built-in WAF. This is one of the highest-value, lowest-effort fixes on this list.
Sites still serving any pages over plain HTTP, or with expired/misconfigured certificates, expose visitor data in transit and get flagged by browsers as "not secure," which damages trust and conversions on top of the security risk.
Fix: force HTTPS site-wide with automatic redirects, use a provider with auto-renewing certificates (Let's Encrypt via Cloudflare or your host), and enable HSTS so browsers refuse to fall back to HTTP.
Custom-built forms, search bars, and comment sections that pass user input directly into database queries or render it directly into the page are vulnerable to SQL injection and cross-site scripting. This is less common on CMS platforms with built-in protections but very common on custom-coded sites.
Fix: use parameterized queries or an ORM for all database access, never string-concatenate user input into SQL, and sanitize or escape any user input before rendering it back to the page.
A backup that has never been restored is not a backup, it's a hope. We regularly find sites where backups exist but haven't been tested, and the first real test happens during an actual incident, when it's too late to discover they're broken.
Fix: automate daily backups stored off-server (a different provider or region than the live site), and actually run a test restore on a staging environment at least quarterly.
Contact forms, job application pages, and user profile uploads that accept any file type and store it in a web-accessible directory are a direct path to remote code execution if an attacker uploads an executable script disguised as an image or document.
Fix: restrict uploads to a strict allowlist of file types, validate file content (not just the extension), store uploads outside the web root or in object storage (S3, Cloudflare R2) rather than a directly executable path, and scan uploads for malware where the volume justifies it.
Without rate limiting, login pages and public forms are wide open to brute-force attacks and automated spam. This is a simple gap that costs almost nothing to close and gets exploited constantly because it's so often left open.
Fix: add rate limiting at the application or edge layer (Cloudflare rate limiting rules, or middleware-level limits like the ones we use on our own contact and booking forms), and add CAPTCHA or a honeypot field on public-facing forms.
Default error pages, exposed `.env` files, and server headers that announce exact software versions hand attackers a head start by telling them precisely which known exploits to try.
Fix: disable directory listing, set custom error pages that don't leak stack traces, strip version headers from server responses, and make sure `.env` and other config files are never served publicly (this should be verified directly, not assumed).
Many small business sites have no way of knowing they've been compromised until a customer reports something wrong, or Google flags the site as unsafe. By that point the damage, and the cleanup cost, is much larger than if it had been caught in hours instead of weeks.
Fix: enable uptime and malware monitoring (Sucuri, Cloudflare, or your host's built-in scanning), set up alerts for unexpected admin logins or file changes, and review access logs periodically rather than only after something looks wrong.
Not every business can fix all ten at once, and trying to do everything simultaneously often means nothing gets done properly. A sensible order: start with the WAF and HTTPS enforcement (numbers 3 and 4), since both take under an hour to configure and close off entire categories of automated attacks immediately. Credential hardening and rate limiting (numbers 2 and 8) come next, because they are nearly as fast and close the most common manual attack paths.
CMS and plugin updates (number 1) deserve a recurring calendar slot rather than a one-time fix, since new vulnerabilities get disclosed continuously. Backups (number 6) should be treated as urgent regardless of where else you start, because it's the only item on this list that determines how bad a worst-case outcome actually is. The remaining items, input sanitization, file upload restrictions, exposed version information, and monitoring, are best handled as part of a proper security audit rather than piecemeal, since they often require looking at the application's actual code rather than just a configuration change.
Whatever order you choose, write it down and assign an owner. Security gaps that everyone agrees are important but nobody is explicitly responsible for are exactly the ones that stay open for years, and re-checking the list every quarter costs far less than recovering from a single compromised site.
None of these ten fixes require an enterprise security budget. Most are configuration changes, a plugin, or a habit, not a rebuild. The businesses that get compromised are almost always the ones that never got around to closing these gaps, not the ones that faced some unstoppable attack.
StrattonX Technologies includes a security review as part of every website engagement, and offers standalone audits for existing sites. If you want an honest assessment of where your site actually stands, our web development services team can walk through it with you.
Book a free consultation and lets build something extraordinary together.