The OWASP top risks, explained simply
The OWASP Top 10 is an awareness document for the most common web application security risks, and the current released version is the 2025 list. It is not a checklist that proves…
The OWASP Top 10 is an awareness document for the most common web application security risks, and the current released version is the 2025 list. It is not a checklist that proves an application is safe, but it is a shared starting point that helps teams talk about risk, prioritise work and decide what to test. This post walks through each category in plain language: what it means, what it looks like in practice and how to prevent it.
A01 Broken access control
Broken access control means users can do something they should not be allowed to do.
Examples include reading another user's record by changing an ID in a URL, using an admin endpoint as a normal user, or modifying a request to bypass a workflow step.
Prevent it by enforcing authorisation on the server for every protected action. Do not rely on hidden buttons, client side checks or route names.
A02 Security misconfiguration
Security misconfiguration means a system is deployed with unsafe settings.
Examples include default credentials, verbose error messages, open cloud storage, missing security headers, unnecessary services and overly broad network access.
Prevent it with hardened defaults, automated configuration checks, repeatable infrastructure and parity between environments.
A03 Software supply chain failures
Software supply chain failures happen when the application depends on compromised, vulnerable or untrusted software.
Examples include vulnerable packages, malicious dependency updates, unsigned artefacts and unverified build steps.
Prevent it by tracking dependencies, pinning and reviewing updates, scanning for known vulnerabilities, verifying artefacts and protecting build pipelines.
A04 Cryptographic failures
Cryptographic failures happen when sensitive data is not protected correctly.
Examples include sending data over plaintext connections, using weak algorithms, reusing keys incorrectly, storing passwords with fast hashes, or exposing encryption keys.
Prevent it by classifying sensitive data, using current libraries, applying TLS correctly, storing passwords with a slow password hashing function, and managing keys separately from data.
A05 Injection
Injection happens when untrusted input is interpreted as part of a command, query or expression.
SQL injection is the classic example, but the same pattern appears in operating system commands, LDAP queries, template engines and other interpreters.
Prevent it with parameterised APIs, safe frameworks, input validation, and by avoiding string concatenation for commands or queries.
A06 Insecure design
Insecure design is a flaw in the intended behaviour of a system, not just a coding mistake.
Examples include password reset flows that trust weak proof, business rules that allow abuse, or workflows that assume users will not tamper with requests.
Prevent it with threat modelling, secure design reviews, abuse case analysis and explicit security requirements before implementation.
A07 Authentication failures
Authentication failures let attackers pretend to be another user.
Examples include weak password reset flows, missing multi factor authentication, exposure to credential stuffing, predictable session tokens and poor session invalidation.
Prevent it with strong authentication flows, multi factor authentication for important accounts, safe session handling, rate limiting and secure recovery processes.
A08 Software or data integrity failures
Software or data integrity failures occur when code, updates or data can be changed without reliable detection.
Examples include trusting unsigned updates, deserialising untrusted data, running unverified CI artefacts or allowing unprotected changes to critical configuration.
Prevent it with signed artefacts, protected pipelines, integrity checks, careful deserialisation and change control for critical data.
A09 Security logging and alerting failures
Security logging and alerting failures mean attacks can happen without timely detection.
Examples include missing audit logs for login, privilege changes, access denial, payment events or administrative actions. Logs that exist but are never monitored have limited value.
Prevent it by logging security relevant events, protecting logs from tampering, setting useful alerts and testing incident response.
A10 Mishandling of exceptional conditions
Mishandling of exceptional conditions means the application behaves unsafely when something unexpected happens.
Examples include exposing stack traces, continuing after a failed security check, leaking sensitive values in errors, failing open when a dependency is unavailable, or leaving partial state after a failed transaction.
Prevent it with explicit error handling, safe defaults, tested failure paths and consistent user facing error messages.
How to use the list
The Top 10 is not a complete security programme. It is a starting point for awareness, prioritisation and review.
Use it to guide training, code review, threat modelling and testing. Then add controls that match your application, data, users, architecture and deployment environment.
Conclusion
The OWASP Top 10 gives teams a shared language for common web application risks. The value is not memorising the names. The value is using the categories to find real weaknesses before attackers do.