OWASP Top 10:2025 in plain language: the main web application risks

The OWASP Top 10 is a list of the most common and dangerous classes of web application vulnerabilities, compiled by the open OWASP community from tests of real systems. The current edition is the OWASP Top 10:2025. For a business it works as a practical checklist: if your vendor cannot explain how each item is handled, the product is exposed.

Below are all ten items in plain language, with examples and what to ask your development team.

What is the OWASP Top 10 and why does everyone use it?

The OWASP Top 10 is a ranking of web application security risks from the non-profit Open Worldwide Application Security Project. It is updated every few years; according to OWASP itself, the 2025 edition draws on test data from more than 2.8 million applications contributed by 13 organisations.

It is widely used because it gives business, developers and auditors a shared language. "The application is protected against the OWASP Top 10" can go into a contract, be checked in an audit and be discussed with a team without a deep technical dive.

Keep its limits in mind: the Top 10 is a baseline, not a complete standard. Systems with stricter requirements, such as financial ones, use the more detailed OWASP ASVS.

Which vulnerabilities are in the OWASP Top 10:2025?

The OWASP Top 10:2025 contains ten categories, from access control failures to mishandled exceptional conditions. Compared with the 2021 edition, two categories are new — software supply chain failures and exceptional conditions — and server-side request forgery (SSRF) has been folded into access control.

#	Category	In plain language
A01	Broken Access Control	A user sees or changes someone else's data
A02	Security Misconfiguration	Unsafe server, framework or cloud settings
A03	Software Supply Chain Failures	Vulnerable or tampered dependencies and build tools
A04	Cryptographic Failures	Data stored or sent without proper encryption
A05	Injection	User input runs as code: SQL injection, XSS
A06	Insecure Design	The flaw is in the logic itself, not the code
A07	Authentication Failures	Weak passwords, brute force, leaked sessions
A08	Software or Data Integrity Failures	The system trusts data and updates without verifying them
A09	Security Logging and Alerting Failures	Nobody noticed the attack: no logs, no alerts
A10	Mishandling of Exceptional Conditions	Errors handled so the system fails open or crashes

What do these vulnerabilities look like in practice?

In practice most vulnerabilities look mundane: one missing check, a default setting left on, a library nobody updated. Here are the most frequent ones with simple examples.

Access control and injection

Access control is broken when the server checks that a user is signed in but not that the requested object belongs to them. The classic case is an order at /orders/1042: change the number to 1043 and you see someone else's order.

// Vulnerable: finds any order by its number
$order = Order::findOrFail($id);

// Safe: searches only the current user's orders
$order = $request->user()->orders()->findOrFail($id);

Injection happens when user data reaches a database query or HTML unchanged. Modern frameworks protect against it by default with parameterised queries and output escaping, so injection usually appears where a developer bypassed that protection with a raw query.

Photo: Unsplash

Configuration, dependencies and errors

• Misconfiguration — debug mode enabled in production, a public file bucket, default admin passwords.
• Supply chain — a library with a known vulnerability, or a malicious package with a look-alike name. The defence is automated dependency checks in CI and pinned versions.
• Exceptional conditions — for example, a failed permission check after which the code mistakenly lets the request through, or an error message that exposes file paths and database queries.

What should you ask a vendor about security?

Ask the vendor exactly how each class of risk is handled, and ask to see it in the code and the process rather than hear it in words. A good team answers specifically: which tools, where the check happens and who is responsible.

Questions we recommend asking:

1. How do you verify a user has access to this particular object? Are there tests for it?
2. How are vulnerabilities in dependencies tracked? What happens when a critical one appears?
3. Where are secrets stored — keys, database passwords, service tokens?
4. How are user passwords stored, and which data is encrypted?
5. Which security events are logged, and who receives alerts?
6. Was there an external audit or penetration test before launch?

If the answers are generic — "everything is secure" — security is running on luck.

How do you build security into the development process?

Build security into the process the way you build in testing: automated checks on every change plus regular manual review of critical areas. A one-off audit before launch is useful, but a month later the code is already different.

A minimum set for a product of any size:

• dependency scanning for known vulnerabilities in CI — for example, composer audit or npm audit;
• static analysis and secret scanning in the repository;
• access control tests for key scenarios;
• code review with special attention to authorisation and input handling;
• scheduled framework and library updates, not "when there is time";
• logs of sign-ins, permission changes and access errors, with alerts.

# CI step: the build fails if a dependency has a known vulnerability
- name: Audit dependencies
  run: |
    composer audit
    npm audit --audit-level=high

For products handling payments or personal data, add an external penetration test before launch and after major changes.

In short

• The OWASP Top 10:2025 is the current list of the main web application risks and works well as a business checklist.
• The most common problem is access control: a user gets someone else's data.
• New in 2025: software supply chain failures and mishandling of exceptional conditions.
• Ask your vendor how each item is handled and to show it in the code and CI.
• Security is part of the process: automated checks on every change, not a one-off audit.