OWASP Top 10 Explained for Non-Technical Founders

OWASP Top 10 Explained for Non-Technical Founders

The OWASP Top 10 is a list published by the Open Web Application Security Project that documents the ten most critical web application security vulnerabilities. It is updated every few years based on data from real-world breaches and security assessments across thousands of applications.

For non-technical founders, the value of the OWASP Top 10 is not in memorising the list. It is in understanding what category of failure these vulnerabilities represent — and therefore what kinds of questions to ask your development team, what to look for in security audits, and why specific security requirements matter.

This guide explains each item on the 2021 list (the current edition) in plain language, with the business implications of each.

A01: Broken Access Control

What it is: Users can access data, functionality, or actions they should not be permitted to reach. An authenticated customer can view another customer's account. A regular user can access admin functionality. A read-only user can modify records.

Why it matters: This is the most commonly exploited vulnerability category. The 2023 data breach affecting a major financial services provider was a broken access control issue. An attacker could modify a parameter in the URL and retrieve any other customer's account data.

What to ask your team: What prevents a user from accessing another user's data by changing an ID in the URL or API request? Is access control enforced at the data layer, not just the UI layer?

A02: Cryptographic Failures

What it is: Sensitive data is not adequately protected in transit or at rest. Passwords stored in plain text. Credit card numbers stored without encryption. Data transmitted over HTTP instead of HTTPS. Weak encryption algorithms that can be broken.

Why it matters: When a database is breached, cryptographic failures determine whether the attacker gets usable data or encrypted gibberish. They also determine whether data is interceptable in transit.

What to ask your team: How are passwords stored? (The answer should be hashed with bcrypt, scrypt, or Argon2 — not encrypted, not plain text.) Is all data in transit over HTTPS? What data is encrypted at rest and with what algorithm?

A03: Injection

What it is: Attackers send malicious data as part of a query or command, causing the application to execute unintended commands. SQL injection, the classic example, allows an attacker to manipulate database queries by injecting SQL commands into input fields. Command injection allows attackers to execute operating system commands.

Why it matters: SQL injection has been responsible for some of the most damaging data breaches in history. It allows attackers to extract entire databases, modify records, or delete data entirely.

What to ask your team: Is all database access using parameterised queries or an ORM? Are all external inputs validated and sanitised before use in any query or command? Has the application been tested with injection payloads?

A04: Insecure Design

What it is: Security vulnerabilities that stem from the architecture and design of an application rather than from implementation errors. The application was designed in a way that makes certain attacks possible by construction, not by accident.

Why it matters: Insecure design cannot be fixed by patching code. It requires redesigning the system. A password reset flow that allows users to reset any account by guessing answers to security questions is an insecure design problem.

What to ask your team: Has the application undergone threat modelling — a systematic review of how an attacker would approach the system and what abuse cases exist? Were security requirements defined before development began?

A05: Security Misconfiguration

What it is: Systems left in insecure default states. Default credentials unchanged. Unnecessary features enabled. Verbose error messages that reveal system details to attackers. Cloud storage buckets set to public when they should be private. Missing security headers.

Why it matters: Security misconfiguration accounts for a significant proportion of cloud data exposures. S3 buckets left publicly accessible have exposed the data of millions of customers at major organisations. These are not sophisticated attacks. They exploit configuration errors that should never exist.

What to ask your team: Have all default credentials been changed? Have unnecessary features and services been disabled? Are all cloud resources reviewed for unintended public accessibility? What is the process for reviewing configuration when new services are deployed?

A06: Vulnerable and Outdated Components

What it is: Applications use libraries, frameworks, and software components with known vulnerabilities. These dependencies are not updated when security patches are released. The vulnerability in the component can be exploited in any application that uses it.

Why it matters: The Log4Shell vulnerability in 2021 affected millions of applications because they all used the same logging library. Attackers can target known component vulnerabilities systematically — if they know you are running a vulnerable version of a library, they have a documented exploit.

What to ask your team: Is there a dependency management process that tracks what libraries are in use and their versions? Are dependencies updated regularly? Is there automated scanning for known vulnerable dependencies?

A07: Identification and Authentication Failures

What it is: Weaknesses in how the application verifies user identity and manages authentication. Allowing brute force attacks on login. Permitting weak passwords. Session tokens that do not expire or that can be predicted. Credentials transmitted over unencrypted channels.

Why it matters: Authentication failures are the entry point for most account takeover attacks. Once an attacker has valid credentials or a valid session, they are authenticated.

What to ask your team: Is there rate limiting on login attempts to prevent brute force? Does the application require strong passwords? Are sessions invalidated correctly when users log out? Is MFA available?

A08: Software and Data Integrity Failures

What it is: The application does not verify that software updates, critical data, or CI/CD pipeline steps have not been tampered with. Deserialisation of untrusted data without validation. Pulling software updates or dependencies from sources that have not been verified.

Why it matters: Supply chain attacks exploit this category. The SolarWinds attack compromised a software update mechanism to distribute malware to thousands of organisations. If your application blindly trusts all software it receives, a compromised dependency or update pipeline becomes a direct path to compromise.

What to ask your team: How is the integrity of software updates and dependencies verified? Is there signed integrity checking for any files the application processes or executes?

A09: Security Logging and Monitoring Failures

What it is: The application does not log security-relevant events, or logs are not monitored. Attacks are not detected. When an incident occurs, there is no forensic record of what happened.

Why it matters: The average time to detect a data breach is still measured in weeks or months. The difference between an attacker who has been in your system for four hours and one who has been there for four months is detection and monitoring.

What to ask your team: What security events are logged? Are logs stored somewhere that is separate from the systems being logged (so they cannot be deleted by an attacker who has compromised those systems)? Are there alerts for suspicious patterns?

A10: Server-Side Request Forgery (SSRF)

What it is: An attacker can cause the server to make HTTP requests to an attacker-controlled destination, or to internal services that should not be publicly reachable. This can expose cloud provider metadata services, internal APIs, and other internal infrastructure.

Why it matters: SSRF has become increasingly significant as applications use cloud infrastructure with metadata APIs that can expose credentials. An SSRF vulnerability in a public-facing application can provide access to AWS credentials with significant access rights.

What to ask your team: Does the application make any outbound HTTP requests based on user-supplied URLs? If so, how is the target URL validated and restricted?

Using This List Practically

The OWASP Top 10 is most useful as a checklist for conversations with your development team and for scoping security assessments. When commissioning a penetration test, confirming that the testers will specifically test for OWASP Top 10 vulnerabilities gives you confidence that the most common and impactful categories are covered.

For existing applications, the list also serves as an audit guide: reviewing your application against each category identifies the highest-priority security investments.

The API security best practices guide covers several of these categories in the context of API-specific vulnerabilities, which is increasingly relevant as more business functionality is delivered through APIs.

For businesses that want a systematic review of their web application security against the OWASP Top 10 and other standards, our cybersecurity team conducts security assessments, code reviews, and penetration tests. Contact us to discuss your current application and what level of review is appropriate.