Understanding OWASP Top 10: Critical Vulnerabilities

Why the OWASP Top 10 Matters

Most breaches of web applications trace back to a small set of recurring mistakes, and the OWASP Top 10 is the industry's shared list of them. It gives developers, testers, auditors and managers one vocabulary for the risks that matter most.

The list is not a standard and not a complete checklist. It is an awareness document: a ranked summary of where applications fail most often and most badly. Regulators, auditors and frameworks such as PCI DSS point to it as a baseline, which is why it shows up in almost every penetration test report and secure coding policy.

What the List Is and How It Is Built

The OWASP Top 10 is published by the Open Worldwide Application Security Project, a non-profit community. The current edition is the OWASP Top 10:2025, the eighth since the project began and the first update since 2021.

The ranking is data-informed rather than purely data-driven:

• Testing data: Contributors supplied results for more than 2.8 million applications, covering 589 weakness types (CWEs).
• Prevalence, not volume: A category is scored by how many applications have at least one instance of a weakness, not by how many instances exist.
• Exploitability and impact: These scores come from CVSS ratings of published CVEs mapped to each weakness.
• Community survey: Eight categories come from the data and two from a practitioner survey, because test data lags behind newer risks.

Each category is a group of related CWEs, 248 in total across the ten. OWASP groups them by root cause, such as a cryptographic failure, rather than by symptom, such as data exposure. That makes each category easier to trace back to a fix.

The Top 10 at a Glance

Broken Access Control stays at number one, and two categories are new in this edition.

A01: Broken Access Control

Access control fails when a user can read, change or delete something they were never authorised to touch. OWASP found at least one of this category's 40 CWEs in 3.73% of tested applications, on average.

Example: A page loads a statement from /statement?account=1001. Changing the value to 1002 returns another customer's statement, because the server checks that the user is logged in but not that the account is theirs. This is an insecure direct object reference (IDOR).

Other forms include forced browsing to admin pages, tampering with tokens or hidden fields to raise privileges, permissive CORS, and server-side request forgery (SSRF).

How to prevent it:

• Deny by default; grant access only to what is explicitly public or permitted.
• Enforce every check on the server, in one reusable component.
• Verify ownership of each record, not just the user's role.
• Invalidate sessions on logout and keep tokens short-lived.
• Write access control tests for every role and run them in the pipeline.

A02: Security Misconfiguration

The application or its platform is set up insecurely, even though the code may be sound. On average, 3.00% of tested applications had one of the 16 CWEs here. The rise to second place reflects how much application behaviour now lives in configuration.

Example: A cloud storage bucket holding customer documents is left publicly readable. Other common cases are default admin credentials, sample applications on production servers, directory listing, verbose stack traces and missing security headers.

How to prevent it:

• Build every environment from the same hardened, automated baseline.
• Remove unused features, ports, accounts and sample content.
• Manage configuration as code and review changes like code.
• Scan cloud permissions and server settings on a schedule.
• Send security headers and return generic error pages.

A03: Software Supply Chain Failures

The risk comes from what you did not write: libraries, build tools, pipelines and update channels. This category has only 5 CWEs and little test data, but the highest average exploit and impact scores, and it topped the community survey.

Example: Log4Shell in 2021 exposed any application bundling a vulnerable Log4j version, often as an indirect dependency nobody knew was present. Malicious packages on public registries and compromised build servers follow the same path.

How to prevent it:

• Keep a software bill of materials (SBOM) covering direct and transitive dependencies.
• Run software composition analysis in the pipeline and act on findings.
• Pull only from trusted registries; pin versions and verify signatures or hashes.
• Harden CI/CD with least privilege, MFA and protected branches.
• Remove unused dependencies and plan for patching unsupported ones.

A04: Cryptographic Failures

Sensitive data is exposed because encryption is absent, weak or misused. On average, 3.80% of applications had one of the 32 CWEs in this category.

Example: Passwords are stored as unsalted MD5 hashes. After a database leak, an attacker recovers most of them within hours using precomputed tables. Other cases are clear-text transmission, hard-coded keys, predictable random values and skipped certificate validation.

How to prevent it:

• Classify data and avoid storing sensitive data you do not need.
• Encrypt in transit with current TLS and enforce it with HSTS.
• Encrypt at rest with authenticated modes such as AES-GCM.
• Hash passwords with Argon2id, bcrypt, scrypt or PBKDF2, each with a salt.
• Keep keys in a vault or HSM, rotate them, and never commit them to source.

A05: Injection

Untrusted input reaches an interpreter and is executed as part of a command or query. Injection has the most CVEs of any category across its 38 CWEs. It spans cross-site scripting (frequent, lower impact) through SQL injection (rarer, severe).

Example: A login query is built by string concatenation:

SELECT * FROM users WHERE name = '" + name + "' AND pass = '" + pass + "'

Entering ' OR '1'='1' -- as the name turns the condition true and bypasses the password check. The same flaw appears in OS commands, LDAP, NoSQL queries and server-side templates.

How to prevent it:

• Use parameterised queries or a safe API; never build queries from strings.
• Validate input on the server against an allowlist.
• Encode output for the context it lands in: HTML, attribute, JavaScript or URL.
• Add a Content Security Policy as a second layer against XSS.
• Run database accounts with least privilege to limit damage.

A06: Insecure Design

The flaw is in what was designed, not how it was coded, so a perfect implementation still leaves the gap. OWASP notes the industry has improved here since 2021, with more threat modelling and attention to secure design.

Example: A password reset flow relies on security questions whose answers are easy to find or guess. A shopping site that lets one buyer reserve unlimited stock, with no cap or bot defence, is another case: the business logic itself is abusable.

How to prevent it:

• Threat model new features and significant changes before building them.
• Write abuse cases alongside user stories and test them.
• Reuse vetted design patterns and reference architectures.
• Set limits on what one user or session can consume or transact.
• Separate tiers and tenants so one compromise does not spread.

A07: Authentication Failures

The application cannot reliably confirm who the user is or keep their session safe. The 36 CWEs here remain important, though OWASP sees standard authentication frameworks reducing how often they occur.

Example: A login page has no rate limit and no multi-factor authentication. An attacker replays username and password pairs leaked from other sites (credential stuffing) and takes over every account that reused a password.

How to prevent it:

• Require multi-factor authentication, especially for privileged and high-value actions.
• Reject weak and known-breached passwords; do not ship default credentials.
• Throttle repeated failures and alert on stuffing patterns.
• Return the same message for all login and recovery failures to stop enumeration.
• Issue a fresh random session ID at login and destroy it on logout and timeout.

A08: Software or Data Integrity Failures

Code or data crosses a trust boundary and is accepted without proof that it is genuine and unaltered. OWASP places this below supply chain failures in scope: it concerns individual artefacts rather than the whole ecosystem.

Example: An application deserialises an object from a cookie the user controls. The attacker alters the object and achieves remote code execution. Auto-updates without signature checks and scripts loaded from a third-party CDN without integrity attributes are similar.

How to prevent it:

• Verify digital signatures on updates, packages and critical data.
• Avoid deserialising untrusted data; where unavoidable, restrict types and check integrity.
• Use Subresource Integrity for externally hosted scripts and styles.
• Require review and approval for code and configuration changes.
• Protect the pipeline so unsigned or unreviewed artefacts cannot be deployed.

A09: Security Logging and Alerting Failures

Attacks succeed quietly because nothing records them or nobody is told. The 2025 name stresses alerting: good logs that trigger no action are of little use. Test data rarely captures this risk, so the community survey voted it onto the list again.

Example: An attacker tries thousands of passwords over a week. Failed logins are written to a local file that no one reviews, and the breach is discovered months later by a third party.

How to prevent it:

• Log logins, failed logins, access control failures and high-value transactions with user and time context.
• Send logs to a central, tamper-resistant store with adequate retention.
• Define alert thresholds and route alerts to people who can act.
• Encode log entries to block log injection, and keep secrets out of logs.
• Maintain and rehearse an incident response plan.

A10: Mishandling of Exceptional Conditions

The application behaves unsafely when something unexpected happens: an error, a timeout, missing input or exhausted resources. This new category groups 24 CWEs covering improper error handling, logic errors and failing open.

Example: A funds transfer debits one account, then an exception interrupts the credit. Without a rollback, the system is left in an inconsistent state. Elsewhere, an error inside a permission check is swallowed and the request proceeds as if it were allowed.

How to prevent it:

• Fail closed: on any error, deny the action rather than allow it.
• Catch exceptions where they occur and add a global handler as a backstop.
• Roll back the whole transaction when any step fails.
• Show users a generic message and keep the detail in server logs.
• Apply rate limits, quotas and timeouts, and test failure paths deliberately.

Putting the Top 10 to Work

The list is most useful as a starting point for each role, not as the finish line: