The OWASP Top 10, for people who do not write code

OWASP stands for the Open Worldwide Application Security Project. Every few years they publish a list of the ten ways websites most commonly get broken into. If you have ever paid a developer and read “follows OWASP guidance” in the proposal, this list is what they meant.

It was written for developers, which explains how it reads. Below is the same list from the other side of the desk.

1. Broken access control

The site lets people see or do things it should not let them.

In practice: a members’ area where changing the number in the address bar shows you somebody else’s records. Or an admin page hidden from the menu that still loads for anyone who knows the address. Hiding a page does not protect it.

Your part: review who holds an administrator account on your site, and do it more than once a year. People leave. Freelancers finish the job. Their accounts tend to stay.

2. Cryptographic failures

Sensitive information travelling or sitting around unprotected.

In practice: a contact form on a page still served over http:// rather than https://, so whatever a customer types crosses the internet in the clear. Or customer details sitting in a database as plain text.

Your part: check the site loads over https and that the old http address redirects to it. If you collect any personal information, ask whoever built the site where that information ends up and whether anyone encrypted it.

3. Injection

The site takes something a visitor typed and follows it as an instruction instead of storing it as text.

In practice: someone types database commands into your search box and the site runs them. The mass WordPress plugin hacks come from here, out of a plugin that forgot to check what people typed into it.

Your part: almost nothing directly, which is the point. This one lives in the code, and that is why the plugins you install matter so much. Each plugin is somebody else’s code running on your site with full reach into your database.

4. Insecure design

Someone built the thing without asking what could go wrong.

In practice: a booking form with no limit on submissions, which somebody uses to fire thousands of confirmation emails out of your domain. Your domain picks up a reputation for spam and your ordinary emails stop arriving.

Your part: when a developer builds you something that handles money, bookings or personal details, ask what happens if a visitor uses it badly on purpose. A good answer exists. “Nobody would do that” is not one.

5. Security misconfiguration

Everything was capable of being secure and nobody switched it on.

In practice: this is the big one for small business sites. Default passwords still in place. Directory listing left enabled, so anyone can browse your files. Detailed error messages handing your file paths and database names to the public. An admin login page with no rate limiting, taking thousands of guesses a night.

Your part: quite a lot. Ask whoever hosts your site whether it runs a web application firewall, whether it limits login attempts, and whether it hides error messages from visitors. These are switches, not projects.

6. Vulnerable and outdated components

You are running a version of something with a published hole in it.

In practice: this is the one that gets British small businesses hacked. A plugin you installed in 2021, whose author stopped updating it in 2023, with a vulnerability published in 2024 that now sits in every scanning tool.

The publication is the dangerous part. When someone discloses a vulnerability, the disclosure carries details of what was wrong and which versions it affects. Within hours, scanners sweep the whole internet looking for sites running the affected version. No human chose you. A script read a version number.

Your part: the single highest-value thing you can do. Keep WordPress, plugins and themes updated. Delete plugins you no longer use, because a deactivated plugin still sits on the server and can still be exploited. And check whether anyone still maintains the plugins you depend on.

7. Identification and authentication failures

Proving you are you is easier to fake than it should be.

In practice: an admin password made of the business name and a number, no two-factor authentication, and no limit on guesses.

Your part: turn on two-factor authentication for each administrator. Use a password manager. If you do one thing off this whole list, make it this one. It costs nothing and takes ten minutes.

8. Software and data integrity failures

The site trusts something it should not, such as code loaded from another company’s server.

In practice: your site pulls a script from a third party for a chat widget or a tracking pixel. If that third party gets compromised, whatever they serve tomorrow runs on your pages, including your checkout page.

Your part: know which third-party scripts run on your site and why. Sites accumulate them: an analytics tool from three years ago, a chat widget nobody answers, a heatmap trial that outlived the trial. Each one is somebody else’s code running on your pages.

9. Security logging and monitoring failures

Something happened and no one noticed.

In practice: across the industry, organisations measure the gap between breach and discovery in weeks. For a small business site with no monitoring, “how we found out” is a customer ringing to say the site is behaving strangely.

Your part: ask what watches your site, and how you would learn that it changed. Uptime monitoring does not cover this. A hacked site is usually still up.

10. Server-side request forgery

Someone tricks the site into fetching things on their behalf, from inside your network where they cannot reach.

In practice: a feature that accepts a URL, importing an image from a web address, say, which an attacker points at an internal address instead.

Your part: nothing directly. This one is build quality.

What to take from this

Ten items, but the weighting is lopsided. For a typical WordPress business site, the bulk of real incidents come from three of them: outdated components (6), security misconfiguration (5) and weak authentication (7).

All three are maintenance rather than engineering. None of them ask you to read code.

That is the honest summary of website security for a small business. It has less to do with clever defence than with not leaving known doors open for months at a time, which is unglamorous, and explains why so many sites sit wide open.

To find out which of these apply to your site, our free website review runs the checks and tells you plainly what we found.