The OWASP Top 10 for small businesses

OWASP CHECKLIST Updated 17 September 2026 · 11 min read

The OWASP Top 10 is the closest thing web security has to a shared vocabulary. It is also written by and for people who do this professionally, which means a small business owner reading it gets ten abstract category names and very little sense of what to actually do on Monday morning.

This is the translation. For each category: what it means in plain terms, whether it realistically applies to a small business site, and whether you can fix it yourself.

A01 — Broken Access Control

In plain terms: someone can reach something they shouldn't. Changing /invoice?id=1042 to 1043 and seeing another customer's invoice is the classic example.

Does it apply to you? Only if your site has logins or accounts. A brochure site doesn't have this problem. Any site with a customer portal almost certainly does until someone has checked.

Can you fix it yourself? No — this is application logic. But you can test it yourself in five minutes: log in as one user, note an ID in a URL, change it, and see whether you get someone else's data. Also check that dangerous HTTP methods like PUT, DELETE and TRACE are disabled at the server; that part is configuration.

A02 — Cryptographic Failures

In plain terms: data that should be encrypted isn't, or is encrypted badly. Expired certificates, sites still reachable over plain HTTP, old TLS versions, cookies without the Secure flag.

Does it apply to you? Yes. Always. This is the most universally applicable category on the list.

Can you fix it yourself? Mostly yes, and cheaply:

• Get a free certificate from Let's Encrypt if you don't have one.
• Redirect all HTTP to HTTPS with a 301.
• Add HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Disable TLS 1.0 and 1.1. Support 1.2 and 1.3 only.
• Set a calendar reminder 30 days before your certificate expires — or better, automate renewal.

A03 — Injection

In plain terms: user input gets treated as code. SQL injection and cross-site scripting (XSS) both live here.

Does it apply to you? If you have any form — contact, search, login, comments — yes.

Can you fix it yourself? The root fix is code: parameterised queries and proper output escaping. But you can add a strong second layer yourself by deploying a Content-Security-Policy header, which stops injected scripts from executing even when escaping fails.

A04 — Insecure Design

In plain terms: the flaw is in how the feature was designed, not in how it was coded. A password reset that emails the password in plain text is perfectly implemented and fundamentally wrong.

Does it apply to you? Yes, but it cannot be found by scanning. No automated tool detects this — including ours. It requires someone thinking about your specific workflows.

Can you fix it yourself? Partly. Ask uncomfortable questions about your own flows: what happens if someone requests a hundred password resets? Can an order be placed with a negative quantity? Does a refund require a second person's approval?

A05 — Security Misconfiguration

In plain terms: the software is fine; the settings are not. Default passwords, directory listing enabled, verbose error pages showing stack traces, .env files readable over the web, missing security headers.

Does it apply to you? Overwhelmingly yes. In our experience this is the category small business sites fail most often, and by the widest margin.

Can you fix it yourself? Yes — this is the highest-value hour you will spend:

• Turn off directory listing (Options -Indexes in Apache).
• Turn off debug mode and detailed errors in production. A stack trace tells an attacker your framework, version and file paths.
• Block access to .env, .git, backup files and *.sql dumps. An exposed .git directory lets anyone reconstruct your entire source code.
• Add the standard header set: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.
• Remove version numbers from Server and X-Powered-By headers.
• Check whether staging, dev or test subdomains are publicly reachable. They usually have weaker settings and a copy of production data.

A06 — Vulnerable and Outdated Components

In plain terms: you're running software with publicly known vulnerabilities. Someone published the exploit; you didn't apply the patch.

Does it apply to you? If you use WordPress, Joomla, Drupal, Magento or any plugin ecosystem — this is your single biggest practical risk. Most small business site compromises trace back here, usually via an abandoned plugin.

Can you fix it yourself? Yes:

• Update core, themes and plugins on a schedule you actually keep.
• Delete plugins you don't use. Deactivated is not removed — the code is still on disk and still reachable.
• Check whether each plugin has been updated in the last year. Abandoned plugins never get patched.
• Stop publishing your version numbers so scanners can't trivially match you to a CVE.

A07 — Identification and Authentication Failures

In plain terms: weak login handling. No rate limiting on password attempts, no MFA, sessions that never expire. For a small business, email spoofing belongs here too — if anyone can send mail as your domain, your identity isn't authenticated.

Does it apply to you? Yes. Especially the email side, which almost every small business gets wrong.

Can you fix it yourself? Largely:

• Turn on MFA everywhere it's offered, starting with your hosting and domain registrar accounts.
• Publish SPF, DKIM and DMARC records so nobody can spoof your domain.
• Enforce rate limiting or lockout on login attempts — most platforms have a plugin or setting for this.

A08 — Software and Data Integrity Failures

In plain terms: you trust code or data you shouldn't. Loading a script from a CDN without verifying it hasn't been tampered with is the everyday version.

Does it apply to you? If your pages load scripts from third-party CDNs, yes.

Can you fix it yourself? Yes — add Subresource Integrity hashes to external script tags:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

If the file changes, the browser refuses to run it. Enabling DNSSEC on your domain covers the DNS-integrity side of this category.

A09 — Security Logging and Monitoring Failures

In plain terms: something bad happened and nobody noticed. The average time to detect a breach is measured in months, mostly because nothing was watching.

Does it apply to you? Yes, and it's the category small businesses ignore most completely.

Can you fix it yourself? Partly:

• Turn on and actually retain access logs.
• Set up uptime monitoring so you learn about outages before customers do.
• Publish a /.well-known/security.txt file so a researcher who finds a flaw has somewhere to report it. Without one, they email a generic inbox and get ignored.
• Re-scan your site on a schedule so you notice when a score drops.

A10 — Server-Side Request Forgery

In plain terms: you can trick the server into fetching a URL of your choosing — often an internal address it shouldn't expose.

Does it apply to you? Only if your application fetches URLs supplied by users: webhooks, "import from URL", link previews, PDF generation from a URL.

Can you fix it yourself? No, this is code. But you can tell whether it applies: if nothing on your site takes a URL as input, you can reasonably deprioritise it.

Where to start

If you do nothing else, do these five, in this order:

1. Block access to .env, .git and backup files. Highest severity, smallest effort.
2. Update every plugin and delete the ones you don't use.
3. Fix HTTPS properly — valid certificate, HTTP→HTTPS redirect, HSTS.
4. Publish SPF, DKIM and DMARC.
5. Add the standard security headers, including a CSP in report-only mode to begin with.

That covers the majority of what a passive scan will flag on a typical small business site, and none of it requires a developer.