---
{
  "title": "OWASP Top 10",
  "summary": "Use the OWASP Top 10:2025 as a versioned awareness guide, then turn relevant categories into application-specific requirements and evidence.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP Top 10: 2025",
      "url": "https://top10.owasp.org/2025/0x00_2025-Introduction/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

The OWASP Top 10 is an awareness document about important web application risk categories. The 2025 edition includes broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions. It is not an exhaustive testing plan. Use it alongside architecture review, threat modeling, and detailed testing guidance.

## In practice

A team reviews both missing authorization and its logging behavior rather than checking only whether a scanner found injection.

## A common misunderstanding

Passing ten category checks does not certify an application as secure. Version labels matter when discussing the list.

## Check your understanding

What complements the Top 10 for an assessment?

**Think it through:** A scoped threat model, detailed testing methodology, and evidence specific to the application.

## An awareness category starts a discussion

Imagine a fictional academy reviews its learner portal using the Top 10. Broken access control prompts questions about report ownership, while supply-chain failures prompt questions about dependencies and release credentials. These are different investigations, even when they appear on the same awareness list.

The list helps teams remember important classes of risk. It cannot identify every resource, business invariant, integration, or deployment path in this particular application. Those details come from architecture and workflow analysis.

## Convert a category into a concrete test

For report ownership, define two learner accounts and the resources each may access. For exceptional conditions, define a dependency outage and the intended safe result. Each test needs an expected behavior and observable evidence.

A scanner may assist some technical checks, but it cannot automatically infer all business permissions or one-time entitlement rules. Combine technical tooling with developers, resource owners, and authorized test scenarios.

## Keep the version and scope visible

The Top 10 changes between editions. A category number without its edition can be ambiguous, and an older report should not silently be presented as using the newest list. Record which reference guided an assessment and what the assessment actually covered.

For a paper exercise, choose three categories relevant to an invented portal. For each, write a risk question, an application requirement, a test actor, and expected evidence. Add one important workflow rule not fully captured by a category-level check. The result demonstrates how an awareness document supports a detailed security process without becoming a certification claim or an exhaustive checklist that guarantees safety.

## Keep exploring

- [[broken-access-control]]
- [[injection]]
- [[security-misconfiguration]]
- [[software-supply-chain]]