Security Guide

OWASP Top 10:2025 Explained

A deep technical guide to the ten most critical web application security risks. No marketing language. No pointless theory. This article explains what each risk actually means, how it appears in real applications, how attackers abuse it, and what developers can do to prevent it.

The OWASP Top 10:2025 is the current released OWASP Top 10 for web application security. It is an awareness document based on application security data and community input, and it is intended to help developers and security teams understand and prioritize major application security risks.

The 2025 edition also changes several categories from 2021. Server-Side Request Forgery (SSRF) has been rolled into Broken Access Control, Software Supply Chain Failures expands the old vulnerable-components category, and Mishandling of Exceptional Conditions is a new category.

OWASP Top 10 2025 List
The OWASP Top 10 for 2025.

A01:2025 — Broken Access Control

Broken Access Control occurs when an application fails to properly enforce what an authenticated user is allowed to access or modify.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

A secure application must enforce both.

The Core Problem

Developers often verify that a user has a valid session or JWT but fail to verify whether that user is authorized to access the requested resource.

For example:

GET /api/users/123/orders/456
Authorization: Bearer <valid-user-token>

The application may correctly validate the token but then retrieve order 456 without verifying that the order belongs to the authenticated user.

An attacker could change:

/users/123/

to:

/users/456/

and potentially access another user's data.

This type of vulnerability is commonly associated with IDOR-style attacks, but Broken Access Control is much broader than IDOR.

Common Examples

SSRF is also incorporated into this category in the 2025 edition.

How to Prevent It

Authorization must be enforced on the server for every sensitive operation.

Do not rely on:

The server should determine whether the authenticated identity is allowed to perform the requested action on the requested resource.

A simplified authorization check might look like:

if resource.owner_id != authenticated_user.id:
    return 403 Forbidden

For more complex systems, use centralized authorization policies, role-based access control, attribute-based access control, or carefully designed tenant isolation.

A02:2025 — Security Misconfiguration

Security Misconfiguration occurs when an application, server, cloud service, framework, database, or other component is configured insecurely.

OWASP moved this category from #5 in 2021 to #2 in 2025. OWASP reports that all tested applications had some form of misconfiguration in the data used for this edition.

The Core Problem

Modern applications contain hundreds of configuration decisions.

One insecure setting can create a major vulnerability.

Examples include:

Example

A production application exposes a debug endpoint:

https://example.com/debug

The endpoint may reveal:

The application may contain no traditional coding vulnerability. The vulnerability exists because the system was configured incorrectly.

How to Prevent It

Use repeatable hardening procedures for development, testing, and production environments.

Remove unnecessary software and services.

Disable debug functionality in production.

Review cloud storage permissions.

Use secure security headers.

Use short-lived credentials or platform-managed identity mechanisms rather than hardcoding secrets.

Automate configuration checks wherever possible.

A03:2025 — Software Supply Chain Failures

This is one of the biggest changes in the 2025 edition.

The old A06:2021 Vulnerable and Outdated Components category has been expanded into Software Supply Chain Failures.

The category is no longer limited to vulnerable libraries. It considers weaknesses across dependencies, build systems, development tooling, and software distribution infrastructure.

The Core Problem

Modern applications rarely consist entirely of code written by the organization itself.

A typical application may depend on:

Application
 ├── Framework
 ├── Authentication library
 ├── Database driver
 ├── Logging library
 ├── Frontend packages
 ├── Build tools
 ├── Container images
 └── Third-party services

A compromise anywhere in this chain can affect the final application.

Real Risks

Log4Shell demonstrated how a vulnerability in a widely deployed dependency could have consequences far beyond the original library.

How to Prevent It

Maintain an accurate Software Bill of Materials (SBOM).

Continuously scan dependencies.

Pin or otherwise control dependency versions where appropriate.

Review new packages before adoption.

Protect CI/CD credentials.

Restrict build permissions.

Verify artifacts before deployment.

Use tools such as dependency scanners, container scanners, and repository security controls.

A04:2025 — Cryptographic Failures

Cryptographic Failures occur when sensitive information is not adequately protected through appropriate cryptographic controls.

The Core Problem

Encryption can fail in many ways.

It is not enough to say:

“Our application uses AES.”

Security depends on the entire cryptographic system:

Common Problems

Passwords should generally be handled with dedicated password-hashing algorithms such as Argon2id, bcrypt, or another appropriately configured password hashing scheme, rather than plain SHA-256 or MD5.

Secrets should not be committed into source code.

Instead, use appropriate secret-management mechanisms such as environment-based secret injection or dedicated secret-management systems.

Important TLS Point

Do not write that “anything below TLS 1.3 is automatically insecure.”

TLS 1.2 can still be securely deployed when configured with strong algorithms and appropriate settings. The correct security requirement is to disable obsolete protocols and weak cipher suites and follow current platform and industry guidance.

A05:2025 — Injection

Injection occurs when untrusted input is interpreted as part of a command, query, expression, or other instruction.

SQL Injection

Unsafe:

SELECT * FROM users WHERE username = 'USER_INPUT'

If input is concatenated directly into SQL, an attacker may manipulate the query structure.

Use parameterized queries or prepared statements instead.

NoSQL Injection

NoSQL databases are not automatically immune to injection.

Applications that accept attacker-controlled objects or operators can introduce unexpected query behavior.

Input should be validated according to the expected data type and structure.

OS Command Injection

Dangerous pattern:

os.system("ping " + user_input)

The problem is not the ping command itself.

The problem is passing attacker-controlled input into a command interpreter.

Use safe process APIs, strict input validation, and avoid shell interpretation when it is unnecessary.

Other Injection Classes

Injection can also involve:

Prompt injection deserves special attention in AI-enabled applications, but it should not be confused with traditional SQL-style injection. The correct defense depends on the architecture and trust boundaries of the AI system.

A06:2025 — Insecure Design

Insecure Design is different from a coding mistake.

The application can be written exactly as designed and still be insecure because the design itself is flawed.

OWASP describes this category as covering architectural and business-logic weaknesses and emphasizes threat modeling and secure design practices before implementation.

Example: Password Reset

Suppose an application responds differently depending on whether an email exists:

[email protected]
→ Account exists

and:

[email protected]
→ Account does not exist

An attacker can automate these responses to enumerate registered users.

The problem may not be a programming bug.

The problem is the design of the password-reset workflow.

A safer design provides a generic response such as:

If an account exists for this address, instructions have been sent.

Other Design Failures

How to Prevent It

Threat-model security-sensitive features before implementation.

Define:

Security needs to exist in the architecture, not merely in the final code.

A07:2025 — Authentication Failures

Authentication Failures happen when the application incorrectly handles identity verification or session management.

Common Problems

Example

Suppose a login endpoint accepts unlimited password attempts:

POST /login

An attacker can repeatedly submit credentials without meaningful rate limiting or detection.

Even a strong password can eventually become a problem if credentials are reused elsewhere and the application is exposed to credential-stuffing attacks.

Better Authentication

Use:

MFA is powerful, but it does not eliminate every authentication threat. Social engineering and MFA-fatigue attacks can still target users.

A08:2025 — Software or Data Integrity Failures

This category concerns failures to properly verify the integrity of software, code, data, or serialized objects.

The Core Problem

The application trusts something it should have verified.

Examples include:

Insecure Deserialization

Imagine an application receives a serialized object from the client and deserializes it without properly validating or restricting what can be constructed.

Depending on the language and framework, this can result in serious attacks, potentially including remote code execution.

The exact exploit depends heavily on the serialization technology.

CI/CD Example

A compromised build process can modify an otherwise legitimate application before deployment.

Developers may review the source code and see nothing malicious while the production artifact has already been altered.

How to Prevent It

Verify the integrity and provenance of artifacts.

Use signed releases where appropriate.

Protect CI/CD systems.

Avoid unsafe deserialization of untrusted data.

Establish clear trust boundaries.

Never assume that data or software is trustworthy simply because it came from another internal system.

A09:2025 — Security Logging and Alerting Failures

Logging without useful alerting is not enough.

The 2025 edition renamed this category from Security Logging and Monitoring Failures to Security Logging and Alerting Failures to emphasize that security events must generate actionable responses.

The Core Problem

An application may be compromised while the organization has no practical way to detect it.

For example:

Failed login
Failed login
Failed login
...
Failed login

If these events are not logged properly, investigated, and connected to useful detection rules, the security team may never know an attack is occurring.

Important Events to Log

Depending on the application, this may include:

Logs should also avoid exposing sensitive information such as passwords, private keys, access tokens, or unnecessary personal data.

Detection Matters

A useful security monitoring system should be able to identify suspicious patterns.

For example:

100 failed login attempts
+
same account
+
multiple source addresses
+
short time period

This may justify an alert and investigation.

OWASP specifically emphasizes that effective logging must be connected to alerting and actionable response procedures.

A10:2025 — Mishandling of Exceptional Conditions

This is a new category in OWASP Top 10:2025.

It focuses on what happens when software encounters unexpected or abnormal conditions.

The Core Problem

Developers often design the application around the normal path:

Request
→ Validate
→ Process
→ Success

But real systems fail.

Networks fail.

Databases fail.

Dependencies time out.

Files disappear.

Memory becomes constrained.

Transactions partially fail.

Permissions change.

Unexpected input reaches code.

Security problems can appear when the application handles those exceptional situations incorrectly.

Example: Fail Open

Suppose an authorization component normally returns:

ALLOW

or:

DENY

But when the authorization service fails, the application accidentally treats the error as:

ALLOW

That is a dangerous failure mode.

A security control should generally fail securely rather than silently granting access when its required verification cannot be completed.

Other Problems

How to Prevent It

Design and test failure states deliberately.

Ask:

“What happens when this component fails?”

Then verify that the resulting state is secure.

Test:

Security testing should not only test the successful path.

It should also test what happens when everything goes wrong.

What Changed From OWASP Top 10:2021?

The 2025 edition is not simply a renamed version of the 2021 list.

The most important structural changes include:

A03:2025 — Software Supply Chain Failures

This expands the old A06:2021 — Vulnerable and Outdated Components category to cover a broader range of supply-chain risks.

A10:2025 — Mishandling of Exceptional Conditions

This is a new category focused on improper handling of abnormal conditions, errors, and related logic failures.

SSRF

Server-Side Request Forgery is no longer a standalone OWASP Top 10 category. OWASP incorporated SSRF into A01:2025 — Broken Access Control.

A09

The former “Security Logging and Monitoring Failures” category is now Security Logging & Alerting Failures, emphasizing the need for actionable alerts rather than merely collecting logs.

OWASP Top 10:2025 — Quick Reference

Rank Category
A01:2025 Broken Access Control
A02:2025 Security Misconfiguration
A03:2025 Software Supply Chain Failures
A04:2025 Cryptographic Failures
A05:2025 Injection
A06:2025 Insecure Design
A07:2025 Authentication Failures
A08:2025 Software or Data Integrity Failures
A09:2025 Security Logging and Alerting Failures
A10:2025 Mishandling of Exceptional Conditions

Final Thoughts

The OWASP Top 10 is useful, but it should not be treated as a complete penetration-testing checklist.

An application can have none of the obvious Top 10 weaknesses and still contain serious security problems.

For mature security testing, you also need to consider:

OWASP itself describes the Top 10 as an awareness document rather than a complete representation of every possible application security problem.

The correct approach is therefore not:

“We passed the OWASP Top 10, so our application is secure.”

The correct approach is:

“We use OWASP Top 10 as one part of a broader application-security program.”