The OWASP Top 10 is a research and awareness document published by the Open Web Application Security Project, a non-profit community organisation focused on improving software security. The Top 10 represents the most critical security risks to web applications as determined by data analysis from security organisations and a consensus process involving security practitioners worldwide. The current version is the 2021 update, which reflects significant changes in the threat landscape compared to the 2017 edition.

Understanding the OWASP Top 10 is essential knowledge for businesses that operate web applications. It forms the baseline vocabulary of web application security risk that security assessors, auditors, and penetration testers use when evaluating an application's security posture. It is the standard against which applications should be measured before reaching production, and it is the language development teams need to understand to build defensibly from the beginning rather than discovering critical vulnerabilities after deployment.

This article explains each of the ten categories in the 2021 OWASP Top 10, provides concrete examples of how each vulnerability manifests in business web applications, and identifies specific controls and mitigations for each category. The goal is to make each category concrete enough that security-aware development teams can evaluate their own applications without needing to translate abstract descriptions into specific implementation concerns.

A01:2021 Broken Access Control

Access control is the enforcement mechanism that determines what authenticated and unauthenticated users are permitted to do. Broken access control is the most prevalent category of web application vulnerability, appearing in 94% of applications tested by OWASP in their 2021 analysis. It ranks first in the Top 10 because it is both ubiquitous and frequently critical: an access control failure typically allows an attacker to access data or functionality they should not be able to reach.

The most common broken access control pattern is vertical privilege escalation where a regular user can access administrative functionality. This manifests as an administrative URL like /admin/dashboard that is not properly protected by access controls, or as an API endpoint that returns admin data without verifying the caller's role. The vulnerability is not the existence of an administrative URL or API endpoint; the vulnerability is the failure to enforce the access control rule that only administrators should be able to reach it.

Horizontal privilege escalation occurs when a user can access resources belonging to another user at the same privilege level. A business application where one user can view another user's private documents is a horizontal privilege escalation. An application handling sensitive customer data where one customer can access another customer's records is both a horizontal privilege escalation and a serious data breach with regulatory consequences.

Mitigation requires explicit, consistently applied access control on every endpoint and API that requires it. Access control decisions must be made on the server side rather than relying on client-side indicators like hidden URLs or API parameters that the client should not know. Every access to a resource must be verified against the authenticated user's permissions, not just the presence of an authentication session. Access control testing must be included in the development workflow, not deferred to a penetration test that happens just before launch.

A02:2021 Cryptographic Failures

This category was previously called Sensitive Data Exposure and was renamed in 2021 to more precisely identify the root cause. The vulnerability is not that sensitive data exists; it is that cryptographic controls protecting that data fail in ways that expose it. This includes data in transit over unencrypted connections, data at rest in unencrypted storage, and data being processed using weak, broken, or absent cryptographic algorithms.

Business web applications most commonly fail on data in transit. Applications that accept user input over HTTP rather than HTTPS transmit that data in cleartext across the network, making it readable by anyone positioned between the user and the server. Man-in-the-middle attacks are practical in many network environments, particularly public WiFi networks. HTTPS must be enforced for the entire application, not just the login and checkout pages, and modern TLS configurations that avoid known-vulnerable cipher suites must be used.

Data at rest failures include storing passwords in plaintext rather than using appropriate password hashing functions, storing credit card data in application databases rather than delegating to a PCI-compliant payment processor, and storing sensitive customer data without encryption or with encryption keys stored alongside the encrypted data. Password storage failures are particularly damaging because they create the conditions for credential stuffing attacks when the plaintext or weakly-hashed passwords are exfiltrated.

The appropriate mitigation is a data classification scheme that identifies what data requires what level of protection, combined with technical controls that implement that protection correctly. Passwords must be hashed using bcrypt, Argon2, or scrypt with appropriate work factors. Sensitive data that is not actively needed should not be stored at all. Sensitive data that must be stored must be encrypted at rest with keys managed separately from the data. Data in transit must use TLS 1.2 or higher with appropriate cipher configurations.

A03:2021 Injection

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most well-known form, but injection attacks can target operating system commands, LDAP queries, XPath queries, and any other interpreter that processes data from untrusted sources. Injection has consistently ranked in the top three of the OWASP Top 10 because it is easy to introduce and the consequences are severe: a successful SQL injection attack can result in complete database exfiltration.

SQL injection manifests when application code constructs SQL queries by concatenating user input directly into the query string rather than using parameterised queries. Consider a login form that constructs a query like SELECT * FROM users WHERE username = 'input' AND password = 'input'. If an attacker provides a username of admin'--, the query becomes SELECT * FROM users WHERE username = 'admin'--' AND password = '', which returns the admin user without needing the actual password.

Parameterised queries, also called prepared statements, are the primary mitigation. Instead of concatenating user input into a query string, the application sends the query structure with placeholders to the database, then sends the parameter values separately. The database distinguishes between the query structure and the parameter values, preventing user input from being interpreted as SQL code. Every major web application language and database combination supports parameterised queries.

Object-Relational Mapping (ORM) layers provide some injection protection by abstracting SQL construction, but they are not immunity. ORM implementations that accept raw SQL strings rather than using the ORM's query builder, or that use raw query methods for complex queries, can reintroduce SQL injection vulnerabilities. The correct approach is parameterised queries throughout the data access layer, whether using raw SQL or an ORM. For a more detailed guide to PHP-specific injection prevention, see the PHP security checklist for business websites.

A04:2021 Insecure Design

This is a new category in the 2021 OWASP Top 10, reflecting a deliberate shift in the security conversation from implementation defects to design-level failures. Insecure design is a risk category that is broader than any specific vulnerability: it represents the absence of security controls in the application design that would make particular vulnerability classes impossible or significantly harder to exploit.

The most common insecure design pattern is missing or inadequate rate limiting on authentication endpoints. An application that allows unlimited login attempts without progressive delays, account lockouts, or CAPTCHA challenges is designed in a way that makes brute force attacks trivially easy. An application that sends verification emails without rate limiting is designed in a way that facilitates email bombing attacks. These are not implementation bugs; they are design choices that create security risk.

Threat modelling is the primary mitigation for insecure design. Before writing application code, identify what assets the application protects, what threats those assets face, and what controls mitigate those threats. The STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides a structured framework for this analysis. A threat model conducted during design and reviewed during development is substantially more effective than penetration testing that happens after the application is built.

Businesses looking to understand how these design principles apply to broader security frameworks can explore the comparison between ISO 27001 and Cyber Essentials certifications, which provide structured approaches to security controls at the organisational level.

A05:2021 Security Misconfiguration

Security misconfiguration covers a wide range of configuration-level failures: unnecessary features enabled by default, default credentials not changed, error messages that expose stack traces to end users, outdated software components, and missing security headers. It ranks fifth in the 2021 Top 10 because it is both common and reliably exploitable by attackers who use automated scanning tools to identify common configuration weaknesses across large numbers of applications.

The most impactful misconfiguration in business web applications is unnecessary services and ports exposed. Application servers, database servers, and development tools that are accessible when they should not be creates an expanded attack surface. An application server with its management console exposed to the internet, or a development API with debug mode enabled in production, is a configuration failure that provides direct access to sensitive functionality.

The recommended mitigation is a repeatable hardening process that configures each environment identically. Configuration management tools like Ansible, Chef, or Puppet allow you to define your server configuration as code and apply it consistently across development, staging, and production environments. Automated security scanning that checks for known misconfigurations should run in CI/CD pipelines before deployment to production. Error messages must be generic at the user-facing layer while logging detailed diagnostic information server-side.

Organisations with limited internal security expertise may benefit from a practical zero-trust security approach that focuses on verifying every access request regardless of network location.

A06:2021 Vulnerable and Outdated Components

Modern web applications are assembled from large numbers of third-party components: framework libraries, utility packages, middleware, and operating system libraries. Each of these components is a potential source of known vulnerabilities. The 2021 OWASP analysis found that applications tested had a median of 528 dependencies. Most development teams have a poor understanding of the composition of their own application dependencies.

Component vulnerabilities are exploited through package manager repositories, supply chain attacks on development tooling, and direct exploitation of known CVEs in components used by the target application. The Log4Shell vulnerability in Apache Log4j, discovered in December 2021, is a canonical example: a widely-used Java logging library contained a remote code execution vulnerability that affected millions of applications worldwide and required urgent patching by every organisation that used it.

Software Composition Analysis (SCA) tools automatically scan application dependencies for known vulnerabilities by comparing the components in use against public vulnerability databases like the National Vulnerability Database (NVD) and the MITRE CVE list. SCA tools should be integrated into the CI/CD pipeline to fail builds when components with known critical vulnerabilities are detected. Dependency pinning ensures that subsequent builds use the same component versions that were tested, rather than automatically pulling newer versions that may introduce vulnerabilities.

A07:2021 Identification and Authentication Failures

Authentication and session management failures allow attackers to impersonate users without knowing their credentials. This includes weak password policies that allow common passwords, absence of credential stuffing protections, session fixation vulnerabilities, and improper session invalidation on logout or timeout. The category encompasses both authentication failures (can an attacker log in?) and session management failures (can an attacker maintain access after authenticating?).

Credential stuffing, where attackers use lists of usernames and passwords from previous data breaches to attempt authentication on other applications, is one of the most prevalent attack vectors against business web applications. Most credential stuffing attacks are volumetric: automated tools try thousands of credential combinations against many accounts simultaneously. Defending against credential stuffing requires detection at the application level through rate limiting, CAPTCHA challenges, device fingerprinting, and integration with credential breach notification services.

Multi-factor authentication (MFA) is the single most effective control against authentication failures. Applications that implement TOTP or hardware token-based MFA are effectively immune to credential stuffing attacks because the stolen password alone is insufficient for authentication. Business applications handling sensitive data, financial transactions, or administrative access should make MFA available if not mandatory.

Businesses should also consider implementing IT security awareness training to help employees understand authentication best practices and recognise phishing attempts that could compromise credentials.

A08:2021 Software and Data Integrity Failures

This is another new category in the 2021 Top 10, reflecting the increasing prevalence of supply chain attacks targeting software development and deployment pipelines. Software and data integrity failures occur when an application relies on untrusted software, data, or configuration from unverified sources without adequate integrity verification.

The most common manifestation is using unverified software from package repositories without checking integrity or provenance. An application that pulls a JavaScript package from npm without verifying its checksum, or a deployment pipeline that pulls a Docker image without verifying its signature, is relying on the integrity of the package repository without verification. Several high-profile attacks have targeted package repositories specifically because the attack surface is large and the trust model is poorly understood by most developers.

Mitigation includes verifying checksums and signatures on all third-party software and components, using dependency pinning with locked hashes rather than version ranges, and reviewing the provenance of critical dependencies including the maintainers' security history. CI/CD pipelines should be treated as production infrastructure with appropriate access controls, audit logging, and integrity verification of all components that flow through them.

A09:2021 Security Logging and Monitoring Failures

Most security breaches are not detected by security controls at the time of intrusion. They are detected weeks or months later during security review, audit, or when a third party notifies the organisation that their data has appeared in a public breach repository. The difference between a breach that is detected in hours versus one that is detected in months is typically the quality of the security logging and monitoring infrastructure.

Security logging must capture authentication events (successes, failures, lockouts), access control decisions (particularly denials), application errors, and business-relevant events like high-value transactions or administrative actions. The logs must capture sufficient context to reconstruct the timeline of an attack: at minimum, the user identity, source IP address, the specific resource accessed, the action taken, and the timestamp.

Centralised logging that aggregates security events from multiple sources into a SIEM (Security Information and Event Management) system enables correlation of events across the application, detection of attack patterns that would be invisible in individual logs, and alerting on anomalous activity that warrants investigation. Without centralised logging, a distributed attack across multiple application instances is invisible to the defenders.

A10:2021 Server-Side Request Forgery

SSRF vulnerabilities occur when a web application fetches remote resources without validating the URL supplied by the user. An attacker who can control the URL that the application fetches can cause the application to execute requests against internal systems that are not directly accessible from the internet, potentially exfiltrating data from those systems, performing port scanning of internal infrastructure, or accessing cloud instance metadata endpoints that expose credentials.

Cloud metadata service exploitation is the most critical SSRF scenario. AWS, Google Cloud, and Azure all provide metadata services at a predictable internal IP address that expose instance credentials, user data, and configuration to any process running on the instance. An SSRF vulnerability that allows a request to the cloud provider's metadata endpoint can expose the credentials assigned to the instance, which can then be used to escalate privileges or access other cloud resources.

Mitigation requires validating all user-supplied URLs against an allowlist of permitted hosts and protocols. URLs must not be fetched without validation, and the validation must be applied server-side rather than trusting client-supplied validation. Network segmentation that prevents application servers from accessing internal systems directly limits the impact of any SSRF vulnerability that does exist.

Building Secure Business Web Applications

The OWASP Top 10 represents the most common categories of security failure in business web applications, but it is not an exhaustive list. Organisations that build or operate web applications should treat the Top 10 as a starting point rather than a complete security checklist. A mature security posture requires threat modelling during design, secure development practices throughout the development lifecycle, automated security testing in CI/CD pipelines, regular penetration testing, and ongoing monitoring of the deployed application.

The security of a web application is not a state that is achieved and then maintained without effort. New vulnerabilities are discovered regularly, and attackers continuously develop new techniques. Application security requires ongoing attention, regular updates to dependencies, periodic review of security controls, and monitoring for emerging threats relevant to the application's technology stack and business domain.

For businesses in the UK, understanding these security fundamentals is particularly important given the increasing regulatory focus on cyber security and data protection. Whether you operate a small business website or a complex web application handling customer data, the principles in the OWASP Top 10 provide a practical foundation for evaluating and improving your security posture.