OWASP Top 10 (2025) Explained with Real Examples
The OWASP Top 10 is the most widely referenced list of web application security risks. Auditors, customers and developers all use it as a shorthand for "the things you must get right." The 2025 edition reorganised several categories. Here is what each one means in practice.
A01: Broken Access Control
Users can act outside their intended permissions: viewing another user's data, editing records they do not own, or calling admin functions. In the 2025 edition, server-side request forgery (SSRF) is folded into this category.
Example: changing /api/orders/1001 to /api/orders/1002 shows another customer's order.
Prevent it: enforce authorisation on the server for every request, deny by default, and test with multiple users.
A02: Security Misconfiguration
Insecure defaults, verbose error messages, open cloud storage, unnecessary features enabled, and missing hardening.
Example: a debug mode left on in production exposes stack traces and environment variables.
Prevent it: hardened, repeatable configuration, minimal installs, and automated configuration checks.
A03: Software Supply Chain Failures
Vulnerable, compromised or unmaintained dependencies, build tools and pipelines. This expands the older "vulnerable and outdated components" category.
Example: a dependency with a known remote code execution flaw, or a compromised package pulled into a build.
Prevent it: dependency scanning, lockfiles, signed artifacts and a hardened CI/CD pipeline.
A04: Cryptographic Failures
Sensitive data exposed due to weak or missing cryptography.
Example: passwords stored with a fast hash like MD5, or data sent over plain HTTP.
Prevent it: TLS everywhere, strong password hashing such as Argon2 or bcrypt, and managed encryption keys.
A05: Injection
Untrusted input interpreted as code or commands: SQL injection, command injection, and cross-site scripting.
Example: a search box that builds SQL with string concatenation.
Prevent it: parameterised queries, context-aware output encoding and safe APIs.
A06: Insecure Design
Flaws in the design itself rather than the implementation, such as missing rate limits on sensitive flows or business logic that can be abused.
Example: a password reset flow that reveals whether an email address is registered and has no rate limiting.
Prevent it: threat modelling, secure design patterns and abuse case testing.
A07: Authentication Failures
Weaknesses in login, session management and credential handling.
Example: no protection against credential stuffing, or session tokens that never expire.
Prevent it: MFA, rate limiting, secure session management and breached password checks.
A08: Software or Data Integrity Failures
Trusting code or data without verifying integrity, including insecure deserialisation and unsigned updates.
Example: an application that deserialises objects from a cookie.
Prevent it: verify signatures, avoid unsafe deserialisation, and protect update channels.
A09: Security Logging and Alerting Failures
Attacks go unnoticed because events are not logged or alerts are not raised.
Example: thousands of failed logins with no alert.
Prevent it: log security-relevant events, centralise logs and alert on anomalies.
A10: Mishandling of Exceptional Conditions
New in 2025: applications that fail unsafely when errors occur, such as failing open, leaking information in errors, or leaving inconsistent state.
Example: an authorisation service timeout that results in access being granted.
Prevent it: fail closed, handle errors consistently and avoid exposing internals.
Testing against the OWASP Top 10
Every SecurityInfinity test covers OWASP Top 10 categories, with verified findings, evidence and the exact fix. Start free.
Frequently asked questions
Is the OWASP Top 10 a compliance standard?
No. It is an awareness document, but many standards and customer contracts reference it as a minimum baseline.
How often is the OWASP Top 10 updated?
Roughly every three to four years. The previous major edition was 2021, followed by 2025.
Does covering the OWASP Top 10 mean an app is secure?
No. It covers the most common risks, but business logic flaws and application-specific issues also need testing.