Application security research hub
OWASP Security Risk Guides
Technical guides to OWASP risk lists for web applications, APIs, AI, MCP, Kubernetes, mobile, CI/CD, open source, and non-human identities.
Direct answer
How Should Teams Use OWASP Top 10 Lists?
OWASP Top 10 lists are awareness and prioritization resources for defined technology areas. Teams should record the exact project and edition, map relevant categories to their architecture, and use deeper standards and testing methods for implementation.
OWASP now maintains risk lists for several distinct scopes. A web application assessment, API review, Kubernetes review, and agent security assessment may all use different lists. Combining their category numbers without the project name and year creates ambiguous findings.
Which OWASP List Fits the System?
Start with the system boundary under review, then add adjacent lists when the architecture crosses another domain.
| System or component | Relevant OWASP project | Use it to examine |
|---|---|---|
| Web application | OWASP Top 10 2025 | Application design, implementation, dependencies, and failure handling |
| API | API Security Top 10 2023 | Object and function authorization, inventory, resource use, upstream APIs |
| LLM or agent system | LLM, Agentic, MCP, and Agentic Skills lists | Prompts, models, memory, tools, identity, protocols, reusable skills |
| Cloud-native platform | Kubernetes Top 10 2025 | Workloads, RBAC, secrets, networking, components, cloud access |
| Software delivery chain | CI/CD and Open Source Software lists | Pipelines, runners, dependencies, artifacts, provenance, maintenance |
Name the project, edition, and status
A finding labeled only with an OWASP category number is incomplete. The same number means different things across projects, and draft lists may change before a stable release. Reports should state the project title, year or version, category identifier, and source URL.
This is especially important for current AI security projects. Some are stable editions, while others are beta or incubator work. A status label prevents a draft category from being mistaken for a settled standard.
Turn categories into testable security work
A category name is a starting point, not a test procedure. Map it to assets, trust boundaries, threat events, control owners, test cases, evidence, and remediation criteria for the system being reviewed.
Where possible, connect the category to a more specific standard or testing guide. Examples include the OWASP ASVS and Testing Guide for web applications, API test cases for authorization, and platform configuration checks for Kubernetes.
Do not treat rank as local risk
Top 10 ordering does not establish the likelihood or impact for a particular organization. Exposure, architecture, data sensitivity, tenant boundaries, existing controls, and threat activity can change the local priority.
The guides below explain every category, note the source edition, and translate the lists into control and testing questions. Use them to orient a review, then apply a system-specific threat model and risk assessment.