OWASP Top 10 Explained for Business Owners

The OWASP Top 10 is a widely used list of the most critical security risks for web applications, published by the Open Worldwide Application Security Project. For a business owner it works as a checklist of questions to put to developers and suppliers: do you control who can see what, protect data properly, validate input, design for security from the start, configure systems safely, keep components updated, handle logins well, protect against tampering, log and monitor, and avoid being tricked into making requests on the attacker's behalf? This article explains each category in plain language, based on the 2021 edition. OWASP revises the list from time to time, so check owasp.org for the current version.

Why a business owner should care

You may never read code, but you own the consequences if your web application leaks customer data or lets someone change an order. The Top 10 gives you shared vocabulary with your technical team. It is an awareness document, not a guarantee: addressing all ten does not make an application secure, and a vulnerability outside the list can still hurt you.

The categories in plain English

A01: Broken access control

Users can do or see things they should not. A customer changes a number in a web address and views someone else's invoice, or an ordinary user reaches an admin page. This sits at the top of the 2021 list. Ask: is every action checked on the server against the logged-in user's permissions, and has this been tested?

A02: Cryptographic failures

Sensitive data is not protected properly: sent without encryption, stored in readable form, protected by weak or home-made cryptography, or passwords stored without proper hashing. Ask: is everything over HTTPS, is sensitive data encrypted at rest, and how are passwords stored? See encryption at rest vs in transit.

A03: Injection

An attacker supplies input that the application treats as commands, for example to the database (SQL injection) or the operating system. This can expose or destroy data. Ask: does the code use parameterised queries and validate input rather than building commands from raw user text?

A04: Insecure design

Security was not considered when the feature was designed, so no amount of careful coding fixes it. Examples include a password reset flow that can be abused, or no limit on how many times an action may be attempted. Ask: did anyone think about how this feature could be misused before building it? A practice known as threat modelling helps here.

A05: Security misconfiguration

Default passwords, unnecessary features enabled, overly detailed error messages, open cloud storage, and missing security settings. Ask: is there a hardened, repeatable configuration, and who reviews it?

A06: Vulnerable and outdated components

Modern applications are built from many libraries and frameworks. If any have known flaws and are not updated, the application inherits them. Ask: do you track dependencies and apply updates, and how quickly?

A07: Identification and authentication failures

Weak login handling: allowing weak or reused passwords, no protection against automated guessing, no MFA, poor session handling. Ask: is MFA available, are login attempts rate-limited, and are sessions ended properly? See our MFA guide.

A08: Software and data integrity failures

Trusting code or data without checking it has not been tampered with: unsigned updates, untrusted plugins, insecure build and deployment pipelines. Ask: how do you know the code that reaches production is the code you reviewed?

A09: Security logging and monitoring failures

Without logs and alerts, attacks go unnoticed for long periods. Ask: are important events such as failed logins and access changes recorded, protected from tampering, and actually reviewed?

A10: Server-side request forgery (SSRF)

The application can be tricked into making requests to internal or unintended systems on the attacker's behalf, sometimes reaching resources that are not meant to be public. Ask: does the application restrict where it will fetch data from when given a user-supplied address?

Summary table

Category	One-line meaning	Question for your developer
Broken access control	Users act beyond their rights	Is permission checked on the server for every action?
Cryptographic failures	Data not protected properly	What is encrypted and how are passwords stored?
Injection	Input treated as commands	Are queries parameterised?
Insecure design	Risk built in at design stage	Was misuse considered?
Security misconfiguration	Unsafe settings and defaults	Is configuration hardened and reviewed?
Vulnerable components	Outdated libraries	How do you track and update dependencies?
Authentication failures	Weak login handling	MFA, rate limits, session control?
Integrity failures	Unverified code or data	How is the deployment pipeline protected?
Logging and monitoring	Attacks go unseen	Who reviews the alerts?
SSRF	App makes attacker-chosen requests	Are outbound requests restricted?

How to use the list in practice

1. Brief suppliers. Ask agencies and software vendors how they address these categories, and ask for specifics rather than reassurance.
2. Add it to contracts and acceptance criteria for new builds: security testing before launch is part of delivery.
3. Request testing. Automated scans catch some issues; a manual review or penetration test finds more. Agree scope and written permission first.
4. Keep updating. Plan ongoing maintenance, because new vulnerabilities in dependencies appear continuously.
5. Build it into process. See our guide to secure software development lifecycle basics.

Which categories matter most for your application?

All ten deserve attention, but the order of priority depends on what your application does. A customer portal holding personal data should put access control, authentication and data protection at the top. A public marketing site built on a content management system will care most about outdated components, configuration and the admin login. An internal tool that talks to other systems may be most exposed to integrity and request-forgery issues. Ask your technical team to map the categories to your actual application, rank them by likely impact, and record the decisions. That one-page ranking is more useful to you than a generic report, because it shows where effort is going and why, and it gives you something concrete to review each time the application changes.

Common mistakes

• Treating the Top 10 as a pass-fail certificate. It is a set of risk categories, not a certification.
• Testing only at the end. Fixing a design flaw after launch is far more costly than catching it early.
• Relying on the firewall. A web application firewall can help but does not fix flawed code.
• Ignoring third-party plugins. Many compromises come through outdated plugins and libraries.
• Assuming the platform handles it. Even with a mainstream CMS or framework, configuration and custom code are your responsibility.
• Forgetting the admin area. Back-office interfaces often receive less scrutiny than public pages.

A note on terminology

You may see references to OWASP lists beyond the web Top 10, including lists for APIs and for applications using large language models. They follow the same idea: shared categories that help teams discuss risk. Whichever list applies, the first step is the same. Understand what your application does, who can reach it, and what the worst misuse would be.

Next steps

Take the ten questions to your developers or suppliers and note how confidently they are answered. Gaps are not a cause for alarm, but they tell you where to focus. Our cybersecurity solutions include security audits and authentication and encryption work, and we are happy to talk through how an application review could be scoped.