OWASP Top 10 Explained: What Each Risk Means for Your Web Apps

The OWASP Top 10 is the most widely referenced standard for web application security risks. It shapes how organizations prioritize security testing, how developers write code, and how auditors evaluate compliance. The current official edition, OWASP Top 10:2021, ranks the ten most critical categories of risk facing web applications, from broken access control and cryptographic failures through injection, insecure design, and server-side request forgery. If you build, deploy, or maintain web applications, understanding these risks is not optional. This guide walks through every category in plain language: what each risk actually means, a realistic example of how it appears in production systems, and the defense that prevents it. It also explains which of these risks automated tools can reliably catch and which ones only a skilled human tester will find.

Why Does the OWASP Top 10 Still Matter?

Every few years, the debate resurfaces: is the OWASP Top 10 still relevant? The answer is unequivocally yes. Not because it covers every possible attack vector, but because it represents the most common and impactful vulnerabilities that real applications face in production. These are not theoretical risks. They are the exact weaknesses that lead to the breaches you read about in the news.

The OWASP Top 10 also serves as a common language between security teams, developers, and management. When a penetration test report references A01:2021 Broken Access Control, everyone involved should understand what that means and why it is critical.

The Top 10, Category by Category

The table below summarizes each category and its core defense at a glance. The sections that follow explain each one in detail.

A01: Broken Access Control

Broken access control has held the top position because it is fundamentally a logic problem, not a technical one. No scanner can fully test whether User A should be able to access User B's data. This requires understanding the business logic of your application.

Common examples we continue to see:

• IDOR vulnerabilities where changing an ID parameter exposes other users' records
• Missing function-level access controls on admin endpoints
• JWT tokens that are validated for signature but not for authorization scope
• API endpoints that enforce authentication but not authorization

Defense: deny by default, enforce ownership checks on every object reference, centralize authorization logic instead of scattering checks across controllers, and verify the model with human-led testing. This category is the clearest case for manual penetration testing, because only a person can judge who should be allowed to do what in your application.

A02: Cryptographic Failures

This category covers failures to protect sensitive data in transit and at rest: transmitting data over unencrypted channels, storing passwords with weak or unsalted hashing, relying on outdated algorithms, or building homegrown cryptography. Often the failure is not a broken algorithm but the decision not to encrypt at all. A realistic example is an internal API that carries customer records between services over plain HTTP because it sits behind the firewall; one compromised machine on that network segment can then read everything in transit. Defense: encrypt data in transit with current TLS everywhere, including internal traffic, hash passwords with a modern adaptive algorithm such as bcrypt or Argon2, classify the data you hold, and stop storing sensitive data you do not actually need.

A03: Injection

SQL injection gets the headlines, but the injection category has expanded to include NoSQL injection, LDAP injection, OS command injection, and expression language injection. Modern frameworks have reduced traditional SQL injection through ORMs and parameterized queries, but developers who write raw queries or use string interpolation in database calls still create these vulnerabilities.

Server-side template injection (SSTI) has become increasingly common as frameworks like Jinja2, Twig, and Thymeleaf gain adoption. A single unescaped user input in a template can lead to remote code execution. The 2021 edition also folded cross-site scripting into this category, since XSS is at heart the injection of untrusted input into HTML output. Defense: use parameterized queries or an ORM for every database call, apply context-aware output encoding for anything rendered to a page, and never concatenate user input into templates, shell commands, or query strings.

A04: Insecure Design

Insecure design covers flaws baked into the architecture before a single line of vulnerable code is written. No amount of correct implementation can fix a design that is unsafe by intent. A realistic example is a password recovery flow built on security questions whose answers are easy to research, or a funds-transfer feature designed without velocity limits, so an attacker with one stolen credential can drain an account in a single scripted session. Defense: threat model new features before building them, write abuse cases alongside use cases, and apply secure design patterns such as rate limits, step-up authentication for sensitive actions, and server-side enforcement of every business rule.

A05: Security Misconfiguration

Cloud infrastructure has made deployment easier but security misconfiguration more prevalent. Default credentials, unnecessary open ports, verbose error messages in production, missing security headers, and overly permissive CORS policies are found on the majority of web applications we test.

The shift to containerized deployments and infrastructure-as-code has helped in some ways but introduced new misconfiguration surfaces: exposed Docker sockets, overly permissive IAM roles, and secrets baked into container images. Defense: maintain hardened configuration baselines, enforce them through infrastructure as code, strip defaults and unused features before deployment, and scan continuously, because configurations drift with every release.

A06: Vulnerable and Outdated Components

The software supply chain remains a critical risk. The average web application depends on hundreds of third-party packages, each with their own vulnerability history. A single outdated dependency can expose your entire application to known exploits.

This is not hypothetical. The Log4Shell vulnerability demonstrated how a single library flaw could affect millions of applications worldwide. Keeping dependencies current and monitoring for new CVEs in your technology stack is essential. Defense: maintain an inventory of every component and version you run, watch vulnerability feeds for your stack, patch on a defined cadence, and treat unmaintained dependencies as risks to replace rather than merely monitor.

A07: Identification and Authentication Failures

This category covers weaknesses in confirming who a user is: permitting weak or breached passwords, missing multi-factor authentication, no protection against credential stuffing, and sloppy session handling such as session identifiers that survive login or logout. A realistic example is a login endpoint with no rate limiting and no MFA, where an attacker replays credentials leaked from other breaches and every reused password hands over an account. Defense: offer and encourage multi-factor authentication, check new passwords against known-breached lists, rate limit and monitor authentication endpoints, rotate session identifiers after login, and invalidate sessions on password change.

A08: Software and Data Integrity Failures

These are failures to verify that code and data have not been tampered with: build pipelines that pull dependencies without integrity checks, auto-update mechanisms that skip signature verification, and insecure deserialization of untrusted data. A realistic example is a pipeline that installs packages by name from a public registry; an attacker who publishes a malicious package under a confusingly similar name, or hijacks an abandoned one, gets code executed inside your build and shipped to production. Defense: pin and verify dependencies with lock files and checksums, sign and verify artifacts through the pipeline, restrict who and what can modify build configuration, and never deserialize untrusted input into rich object types.

A09: Security Logging and Monitoring Failures

You cannot respond to an attack you cannot see. This category covers missing or inadequate logging of security events, logs that nobody reviews, and alerts that never fire. The realistic example is depressingly common: an attacker brute-forces an admin account over several nights, exports customer data, and the organization only learns of it when the data surfaces elsewhere, because failed logins and bulk exports were never logged or alerted on. Defense: log authentication events, access control failures, and high-value transactions, ship logs to a centralized store the application cannot alter, alert on suspicious patterns, and rehearse incident response so the alerts actually lead somewhere.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a URL supplied by a user without validating it, letting an attacker make the server issue requests to internal resources on their behalf. A realistic example is a webhook or link-preview feature that will happily fetch the cloud metadata endpoint and return credentials for the server's own cloud role, from which an attacker pivots into storage buckets and internal APIs. Defense: validate and allowlist outbound destinations, block requests to private and link-local address ranges, isolate URL-fetching functionality on a segmented network, and never return raw fetch responses to the user.

What Does This Mean for Your Security Program?

Understanding the OWASP Top 10 is the starting point, not the finish line. Here is how to translate this knowledge into action:

• Automate what you can: Automated scanners are effective at detecting security misconfigurations, vulnerable components, and many injection patterns. Run them continuously, not just before audits. Automated scanning that tests your live environment, rather than replaying cached results, keeps the picture current between releases.
• Test business logic manually: Broken access control and authentication flaws require human intelligence to test properly. Automated scanners cannot understand your authorization model.
• Shift left: Integrate security testing into your CI/CD pipeline so vulnerabilities are caught before they reach production.
• Monitor your supply chain: Use tools that map your dependencies to known CVEs and alert you when new vulnerabilities are published.
• Prioritize by impact: Not all vulnerabilities are equal. A broken access control flaw that exposes customer data is more critical than a missing security header.

Combining Automation with Expertise

The OWASP Top 10 makes one thing clear: some risks can be detected by machines, and some require human judgment. Automated scanning catches the technical vulnerabilities like misconfigurations, known CVEs, and injection patterns. Manual penetration testing catches the logical vulnerabilities like broken access control, business logic flaws, and chained exploits.

An effective security program uses both. Automation gives you coverage and speed. Human expertise gives you depth and context. Together, they address the full spectrum of OWASP risks.

To go deeper, our complete guide to web application security testing shows how to build a testing program around these categories, and the manual penetration testing guide explains how human-led testing covers the risks that tools cannot. When you are ready to put both layers in place, explore our security services.

Frequently asked questions

What is the current version of the OWASP Top 10?

The current official edition is OWASP Top 10:2021. It ranks the ten most critical categories of risk facing web applications, from broken access control and cryptographic failures through injection, insecure design, and server-side request forgery. It shapes how organizations prioritize security testing, how developers write code, and how auditors evaluate compliance, and it serves as a common language between security teams, developers, and management.

What happened to cross-site scripting in the OWASP Top 10?

The 2021 edition folded cross-site scripting into the injection category (A03), since XSS is at heart the injection of untrusted input into HTML output. That category also covers SQL injection, NoSQL injection, LDAP injection, OS command injection, expression language injection, and server-side template injection, where a single unescaped user input in a template can lead to remote code execution.

Which OWASP Top 10 risks can automated scanners detect?

Automated scanners are effective at detecting security misconfigurations, vulnerable and outdated components, and many injection patterns, and they should run continuously rather than just before audits. They cannot fully test broken access control or authentication flaws, because those are logic problems that require understanding who should be allowed to do what in your application.

Why is broken access control ranked number one?

Because it is fundamentally a logic problem, not a technical one. No scanner can fully test whether User A should be able to access User B's data, so these flaws survive automated checks. Common examples include IDOR vulnerabilities, missing function-level controls on admin endpoints, JWT tokens validated for signature but not authorization scope, and API endpoints that enforce authentication but not authorization.