OWASP Top 10 (2025) Explained

Examine applications from an attacker's perspective, then apply security controls throughout design, implementation, delivery, and operations.

OWASP (Open Worldwide Application Security Project) is an open community focused on application security. OWASP Top 10 is its best-known awareness document: it summarizes ten critical categories of web application risk and provides a practical starting point for a secure development baseline.

This article covers the current official release, OWASP Top 10:2025. The Top 10 is a risk classification and educational resource—not a complete security standard and not a replacement for threat modeling, code review, or penetration testing.

The ten risks at a glance

Rank	Risk	In one sentence
A01	Broken Access Control	Users can perform actions beyond their permissions
A02	Security Misconfiguration	Unsafe defaults, exposed services, or mistakes create attack surface
A03	Software Supply Chain Failures	Dependencies, builds, and releases are affected by vulnerabilities or tampering
A04	Cryptographic Failures	Sensitive data is not encrypted and protected correctly
A05	Injection	Untrusted input is executed as a command, query, or code
A06	Insecure Design	Essential security constraints are missing from the design
A07	Authentication Failures	Login, session, or credential recovery controls can be bypassed or abused
A08	Software or Data Integrity Failures	Trust in code, updates, or critical data is not verified
A09	Security Logging and Alerting Failures	Attacks cannot be detected, traced, and handled promptly
A10	Mishandling of Exceptional Conditions	The system stops behaving securely during errors or resource exhaustion

A01: Broken Access Control

Access control determines who may perform which operation on which resource. Successful authentication establishes identity; it does not grant access to every object.

Typical cases include ordinary users reaching admin APIs, changing an order ID to view another user's order (IDOR), enforcing permissions only by hiding frontend controls, and SSRF that lets a server reach internal resources.

// Wrong: trust an id supplied by the client
const invoice = await db.invoice.findUnique({ where: { id: req.params.id } })

// Right: constrain the query by resource ownership
const invoice = await db.invoice.findFirst({
  where: { id: req.params.id, ownerId: req.user.id }
})

Defenses: deny by default; centralize server-side authorization; validate object ownership; apply least privilege; restrict cross-origin access; and alert on repeated authorization failures. Allowlist outbound destinations and isolate cloud metadata and private networks.

A02: Security Misconfiguration

Modern applications depend on frameworks, containers, cloud services, and extensive configuration. Debug mode, default accounts, public storage buckets, or stack traces in error pages all make an attack easier.

Defenses: use repeatable hardening templates for each environment; remove unnecessary features, examples, ports, and accounts; deploy security headers such as CSP and HSTS; avoid exposing internal errors; and scan infrastructure code, container images, and configuration drift in CI/CD.

A03: Software Supply Chain Failures

The 2025 category expands 2021's “Vulnerable and Outdated Components” to cover the whole supply chain. Risk may come from vulnerable dependencies, hijacked packages, poisoned build tools, leaked release credentials, or untrusted artifact repositories.

Defenses: maintain an SBOM; pin and review dependencies; use trusted package sources; run continuous SCA; protect CI/CD credentials and workers; sign releases; and verify provenance and integrity before deployment.

A04: Cryptographic Failures

These failures expose passwords, sessions, personal information, or payment data—for example, plaintext HTTP, reversibly encrypted passwords, obsolete algorithms, or keys committed to source control.

// Use a mature implementation of Argon2id, scrypt, or bcrypt for passwords.
const passwordHash = await argon2.hash(password, { type: argon2.argon2id })

Defenses: classify data and retain only what is required; use TLS in transit; use proven modern algorithms at rest; apply password-specific slow hashes; store keys in a key-management system and rotate them; never invent cryptographic algorithms or protocols.

A05: Injection

When untrusted input is concatenated into SQL, NoSQL, operating-system commands, templates, or LDAP queries, data can become instructions. Cross-site scripting (XSS) also belongs to this category.

// Wrong: string concatenation enables SQL injection
db.query(`SELECT * FROM users WHERE email = '${email}'`)

// Right: parameterized query
db.query('SELECT * FROM users WHERE email = ?', [email])

Defenses: prefer parameterized queries and safe APIs; validate input against business rules; encode output for its HTML, URL, or JavaScript context; minimize interpreters and shell use; and use CSP to reduce XSS impact.

A06: Insecure Design

Correct implementation does not guarantee a secure design. Unlimited coupon stacking, transfers without limits, and account-enumerating password recovery are missing business and security constraints that scanners rarely discover.

Defenses: threat-model before development; write abuse cases for high-risk workflows; define trust boundaries and security requirements; add rate limits, confirmation, and state validation to sensitive operations; use defense in depth; test security invariants.

A07: Authentication Failures

Examples include weak password policy, unlimited login attempts, session IDs that are not rotated, tokens that remain valid after logout, bypassable MFA, and unsafe account recovery.

Defenses: use proven identity platforms and standard protocols; deploy phishing-resistant MFA for high-risk actions; detect credential stuffing; rotate session IDs after login; set HttpOnly, Secure, and appropriate SameSite cookie attributes; enforce idle and absolute expiration; do not reveal whether an account exists.

A08: Software or Data Integrity Failures

Applications often trust updates, plugins, serialized input, or pipeline artifacts by default. Without signatures and integrity checks, an attacker may replace code or alter data. This overlaps A03 but focuses on the trust boundary around specific code and data artifacts.

Defenses: verify digital signatures; constrain deserialization types; never deserialize untrusted objects; protect repository and pipeline approvals; audit critical data changes; use Subresource Integrity or host trusted copies of external scripts.

A09: Security Logging and Alerting Failures

Logs without actionable alerts can leave attacks unnoticed. Logging passwords or tokens creates a new disclosure risk.

Defenses: record authentication and authorization failures, admin actions, and critical data changes; use consistent time and structured formats; protect logs against tampering; establish access and retention rules; configure actionable alerts; regularly exercise incident response from alert to resolution.

A10: Mishandling of Exceptional Conditions

This category is new in 2025. Timeouts, missing parameters, insufficient permissions, exhausted resources, and unexpected states can trigger failures. A system that fails open, performs only half a transaction, or returns internal errors can enable bypass, corruption, or denial of service.

try {
  await authorizeAndTransfer(command)
} catch (error) {
  logger.error({ errorId, userId: user.id }, 'transfer failed')
  return reply.status(500).send({ error: 'TRANSFER_FAILED', errorId })
}

Defenses: centralize exception handling; fail securely; use transactions for atomicity; bound timeouts, retries, and circuit breakers; limit memory, connections, and request size; return generic errors with correlation IDs; test partial failure and resource-exhaustion paths.

What changed from 2021 to 2025?

• Broken Access Control remains first, with SSRF merged into the category.
• Security Misconfiguration moves from fifth to second.
• Vulnerable and Outdated Components expands into Software Supply Chain Failures.
• Authentication has a shorter name but retains its core focus.
• Logging now explicitly emphasizes alerting and response.
• Mishandling of Exceptional Conditions is a new category.

Delivery checklist

1. Design: identify assets, trust boundaries, abuse cases, and security requirements through threat modeling.
2. Coding: standardize authorization, parameterized queries, output encoding, password hashing, and exception handling.
3. Commit: scan secrets, source code, dependencies, and licenses; protect the main branch.
4. Build: isolate pipelines, produce an SBOM, sign artifacts, and verify provenance.
5. Test: cover authorization, authentication, business logic, exceptional paths, and configuration.
6. Deploy: enforce least privilege, manage secrets, scan cloud and container configuration, disable debugging.
7. Operate: centralize logs, configure useful alerts, patch vulnerabilities, and exercise incident response.

Conclusion

The value of OWASP Top 10 is not memorizing ten names. It gives product, development, operations, and security teams a shared language. Turn each risk into your own design rules, coding standards, automated checks, and incident exercises instead of treating security as a one-time pre-release inspection.

References

• OWASP Top 10:2025
• OWASP Top 10:2025 — Introduction
• OWASP Cheat Sheet Series
• OWASP Application Security Verification Standard

This article is for security education. Examples are simplified; real projects should tailor controls to business risk, technology, and compliance obligations.