Back to Blog
web security small business vulnerabilities OWASP security hardening

5 Common Web Security Mistakes Small Businesses Make (And How to Avoid Them)

Vincent E Martinez, MA 7 min read Category: Security

A security breach can happen to anyone. This usually is not a story about espionage, lasers, or a hoodie-wearing supervillain typing very fast in the dark. When clients call us after a breach, the root cause is rarely a zero-day exploit or some movie-grade nation-state drama. It is usually one of a few familiar mistakes that piled up quietly over time.

The Verizon 2024 Data Breach Investigations Report reaches the same conclusion from a much larger dataset. Most incidents involve known vulnerabilities, weak credentials, or misconfigured systems. For a small business, that is both good news and bad news:

  • Good news: most breaches are preventable
  • Bad news: speed, deadlines, and optimism make it very easy to accept avoidable risk

Here are the five mistakes we see most often in small-business environments, why they happen, and how to fix them.

1. Treating the Hosting Provider as the Security Team

The most common misconception we see is this: “We host on a major cloud platform, so security is basically handled.”

It is not.

Cloud providers follow a shared responsibility model. They secure the underlying infrastructure. You secure what you build on top of it. They protect the building. You still need to lock your office door and avoid leaving the customer database in the lobby.

AWS, Google Cloud, and Microsoft Azure all publish shared responsibility guidance. The provider handles the physical data centre, the hypervisor, and the underlying network. You own everything above that line, including:

  • Application code
  • Access controls
  • Data classification
  • Patch management
  • Incident response

The fix is to treat your cloud account like a real office. It has doors, locks, keys, and expensive things inside.

  • Turn on multi-factor authentication for every account that has administrative privileges.
  • Enable cloud-native logging on day one, not after an incident. (That includes CloudTrail, Cloud Audit Logs, and Azure Activity Log.)
  • Review the provider’s security checklist for the services you’re using and work through it systematically.
  • If you do not have expertise in-house, hire a security consultant to validate your configuration. That will cost far less than recovering from a breach caused by a misconfigured storage bucket.

2. Running Outdated Dependencies

Modern web apps rely on more third-party packages than anyone enjoys counting, and every one of them is a potential attack vector. The 2021 Log4Shell vulnerability made that painfully clear. One flaw in one logging library, buried inside dependencies of dependencies, triggered a massive remediation effort across high-profile systems. Plenty of developers did not even realise they were using it. Nothing says “fun week” like discovering your stack contains a surprise from three levels down.

The Open Source Security Foundation (OpenSSF) and Cybersecurity & Infrastructure Security Agency (CISA) both say roughly the same thing:

  • Know what you depend on
  • Track security updates
  • Have a process to apply them quickly

The fix is less about buying tools and more about having the discipline to use them consistently.

  • Configure automated dependency scanning through GitHub Dependabot, Snyk, or a similar service.
  • Review the alerts every week, not “when we get around to it.”
  • Set a policy that gives high- and critical-severity advisories a clear deadline. Seven (7) days is a reasonable target for a small team.
  • Keep your runtime, language, and framework within supported versions. If you run Node.js or Python three major versions behind, the question is no longer “are there vulnerabilities in this system?” It is “how many, and do we want to find out the exciting way?“

3. Weak Authentication

Authentication failures remain one of the top causes of breaches in the Verizon DBIR year after year. The pattern barely changes:

  • Reused passwords
  • No multi-factor authentication
  • Shared accounts
  • Credentials embedded in source code or configuration files

NIST Special Publication 800-63B remains the authoritative guide on digital identity. It moved away from the old “rotate passwords every 90 days” rule years ago, because that practice often just creates weaker passwords with a number taped to the end. What actually works is longer passwords, screening against known-compromised password lists, and multi-factor authentication.

The fix starts with three non-negotiables:

  • Enforce multi-factor authentication for every administrative account and every account with access to customer data
  • Eliminate shared accounts. Every person gets an individual identity, and every service gets its own service account
  • Screen new passwords against the “Have I Been Pwned” breach database

And yes, that first rule applies to founders too. Especially founders. “But I know what I’m doing” is not a recognised MFA factor.

Those three steps alone would prevent most of the credential-driven breaches we investigate.

4. Missing or Misconfigured Security Headers

Security headers are HTTP response headers that tell the browser how to behave safely on your site. They cost nothing, which is a lovely price point. A well-configured Content Security Policy (CSP) can stop a cross-site scripting attack even when your code has an easily exploitable flaw. HTTP Strict Transport Security prevents downgrade attacks. X-Content-Type-Options blocks a class of MIME-confusion attacks. You do not need to buy anything. You just need to configure your server or framework correctly.

OWASP maintains a Secure Headers Project with recommended configurations for each header. Tools such as Snyk’s securityheaders.com can score your site’s current posture in seconds.

The fix is to audit your current headers against OWASP recommendations and close the gaps. For most small-business sites, start with:

  • Strict-Transport-Security with a long max-age and preload,
  • Content-Security-Policy (CSP),
  • X-Frame-Options or CSP’s frame-ancestors directive, and
  • Referrer-Policy.

Start CSP in report-only mode, then tighten it over time. Use X-Frame-Options or frame-ancestors to prevent clickjacking. Use Referrer-Policy to limit information leakage to third-party sites. Most frameworks support this out of the box, or through simple middleware. The documentation is less thrilling than a breach report, but also much cheaper.

5. Storing Secrets in the Wrong Places

No surprise here: secrets should stay secret. Hardcoded API keys, database passwords inside committed environment files, and credentials pasted into Slack can get ugly very quickly. Once a secret lands in a public repository, treat it as permanently exposed. Deleting the commit does not fix the problem. Automated scanners can find exposed credentials within minutes, and GitHub Secret Scanning catches a truly heroic number of exposed tokens.

The fix has two parts:

  • For prevention, use a secrets manager. AWS Secrets Manager, GCP Secret Manager, and HashiCorp Vault are all solid options. A well-managed .env file can also work if you keep it out of version control. Add a pre-commit hook such as gitleaks or trufflehog to scan for secrets before they are committed.
  • For containment, assume a secret will leak eventually. Use short-lived credentials where possible, rotate long-lived credentials on a schedule, and assign each secret to a single service so you can revoke it without setting the whole platform on fire.

The Pattern Behind the Patterns

These five mistakes follow the same pattern. None of them require expensive tooling. None of them require elite threat-research mysticism. They do require disciplined, ongoing attention, and that is exactly the sort of thing teams tend to postpone when the customer demo is on Friday and everyone is feeling courageous.

CISA’s Secure by Design initiative makes the point plainly. The issue is not whether your team can build secure systems. The issue is whether your organisation makes security a priority before it becomes an incident. For small businesses, that usually means defining a small set of non-negotiable practices and enforcing them through automation, not heroic bursts of willpower.

The most practical next step is to draft a short security roadmap for the next quarter.

  • Pick the two biggest gaps
  • Close them with measurable changes
  • Move on to the next two

Within a year, a disciplined small team can go from “we hope we are secure” to a posture that holds up under an enterprise customer review. That is not just a technical improvement. It is a management decision, followed by the deeply glamorous work of consistent follow-through.

Further Reading

Ready to apply this to your project?

Let's talk about your specific challenges.

Start the conversation →