OWASP Top 10:2025 for Product Teams: What Changed and How to Test for Each Risk

The OWASP Top 10 is the most widely recognised list of web application security risks. It is used by developers to prioritise secure coding, by QA teams to plan security tests, by buyers to assess vendors and by auditors as a reference point. In 2025 OWASP published a new edition, replacing the 2021 list that many articles and checklists still describe.

This guide is written for product, engineering and QA teams. For each category it explains what the risk looks like in a real application, how to prevent it and how to test for it. For security review of AI-generated code specifically, see our review framework for AI-generated code.

What changed from 2021 to 2025

OWASP’s data for the 2025 edition came from contributors covering more than 2.8 million applications and analysed 589 weakness types (CWEs). Rankings are based on the share of applications with at least one instance of a weakness, not on how many times it occurred. Two categories were included partly on the basis of a community survey, to capture risks that testing data may under-represent.

A01: Broken Access Control

What it looks like: a customer changes an order ID in a URL and sees someone else’s order; a normal user calls an admin API directly; a file-upload feature can be made to fetch internal URLs (SSRF).

Prevent it: deny by default; enforce authorisation on the server for every request and every record; check ownership, not just authentication; centralise access-control logic; restrict outbound requests from servers to allow-listed destinations.

Test it: automated tests that call each endpoint as different roles and tenants and assert forbidden access; manual exploration of ID manipulation; SSRF tests with internal and metadata addresses.

A02: Security Misconfiguration

What it looks like: default credentials, verbose error pages in production, open cloud storage buckets, unnecessary services enabled, missing security headers, overly permissive CORS.

Prevent it: hardened, repeatable configurations defined as code; separate settings per environment; minimal installed components; automated configuration scanning of cloud accounts and containers.

Test it: infrastructure-as-code scanning in CI; cloud posture checks; header and TLS checks against staging and production; review of error responses.

A03: Software Supply Chain Failures

What it looks like: a vulnerable or abandoned library, a malicious package with a name similar to a real one, a compromised build plugin, or an unsigned artefact replaced in transit.

Prevent it: maintain an inventory of components (a software bill of materials); pin versions with lockfiles; review new dependencies; use trusted registries; protect build pipelines with least privilege; sign and verify artefacts.

Test it: dependency vulnerability scanning on every build; checks that new packages exist and come from expected publishers; pipeline permission reviews; verification of artefact signatures at deploy time.

A04: Cryptographic Failures

What it looks like: sensitive data sent over plain HTTP, passwords stored with fast or unsalted hashes, weak or home-made encryption, keys committed to source code.

Prevent it: classify data; encrypt sensitive data in transit and at rest; use modern, well-reviewed libraries and algorithms; hash passwords with a slow, salted algorithm designed for passwords; manage keys in a dedicated service.

Test it: TLS configuration scans; code review and static analysis for weak algorithms; secret scanning in repositories and build logs.

A05: Injection

What it looks like: SQL, NoSQL, OS command or LDAP injection through unsanitised input; cross-site scripting where user content is rendered without encoding. In AI features, prompt injection is a related risk covered by the OWASP Top 10 for LLM Applications.

Prevent it: parameterised queries and safe APIs; context-aware output encoding; server-side input validation; avoid passing user input to interpreters.

Test it: static application security testing; dynamic scanning in staging; targeted tests with injection payloads on high-risk inputs.

A06: Insecure Design

What it looks like: a password-reset flow that can be abused, a checkout that trusts prices sent by the browser, no rate limiting on a costly operation, business rules that can be bypassed by calling steps out of order.

Prevent it: threat modelling during design; security requirements in user stories; secure design patterns; abuse cases alongside use cases.

Test it: design reviews; abuse-case test scenarios; business-logic testing that tries to skip, repeat or reorder steps.

A07: Authentication Failures

What it looks like: credential stuffing succeeds because there is no rate limiting; weak password rules; session tokens that never expire; missing multi-factor authentication for privileged accounts.

Prevent it: use proven identity providers or libraries; multi-factor authentication; rate limiting and breached-password checks; secure session management with expiry and rotation.

Test it: automated checks of lockout and rate limits; session expiry tests; review of password reset and account recovery flows.

A08: Software or Data Integrity Failures

What it looks like: an application loads scripts from a third-party CDN without integrity checks; insecure deserialisation of untrusted data; auto-updates without signature verification.

Prevent it: verify signatures and integrity of code and data; use subresource integrity for third-party scripts; avoid deserialising untrusted data or use safe formats; protect CI/CD configuration.

Test it: checks for integrity attributes; review of deserialisation points; pipeline configuration review.

A09: Security Logging and Alerting Failures

What it looks like: a brute-force attack runs for days unnoticed; logs lack user and request identifiers; alerts exist but nobody receives them.

Prevent it: log authentication events, access-control failures and high-value transactions with context; protect logs from tampering; define alerts with owners and response procedures; keep personal data out of logs.

Test it: simulate attacks in staging and confirm alerts fire and reach the right people; review log content for completeness and sensitive data.

A10: Mishandling of Exceptional Conditions

What it looks like: an error in a payment callback marks an order as paid; an authorisation service timeout lets requests through (“failing open”); unhandled exceptions leak stack traces; inconsistent state after partial failures.

Prevent it: fail closed for security decisions; handle errors explicitly at boundaries; use transactions or compensating actions for multi-step operations; return generic error messages to users and detailed ones to logs.

Test it: fault-injection tests that make dependencies time out or return errors; tests that interrupt multi-step flows; review of default branches and catch blocks.

Building OWASP coverage into delivery

Writing security into user stories

Security works best when it appears in the same place as other requirements. Examples of acceptance criteria that map to the Top 10:

• Access control (A01): “Given a customer is logged in, when they request an invoice belonging to another account, then the API returns 404 and logs an access-control failure.”
• Insecure design (A06): “The discount code endpoint allows no more than five attempts per account per hour.”
• Exceptional conditions (A10): “If the payment provider times out, the order remains unpaid and the customer sees a retry option; no fulfilment is triggered.”
• Logging and alerting (A09): “Ten failed logins for one account within five minutes generate an alert to the on-call channel.”

Criteria like these turn abstract categories into tests the QA team can automate.

Worked example: mapping risks for a SaaS product

Consider a hypothetical multi-tenant B2B SaaS application with a web front end, a public API, file uploads, background jobs and third-party integrations. A one-day mapping workshop with engineering and QA might produce:

Prioritising remediation

Not every finding is equally urgent. A simple model:

Beyond the Top 10

The Top 10 is an awareness document. For detailed, testable requirements, OWASP’s Application Security Verification Standard (ASVS) is a common choice. If your product includes AI features, also review the OWASP Top 10 for LLM Applications, which covers risks such as prompt injection, sensitive information disclosure and excessive agency.

Frequently asked questions

Is the OWASP Top 10 a compliance standard?

No. It is an awareness document listing the most common and impactful categories of risk. Some standards and contracts reference it, but it is not a complete set of requirements.

Do we need to retest everything for the 2025 version?

Not necessarily. Map your existing controls and tests to the 2025 categories and look for gaps, especially in supply chain security and exception handling.

Can automated scanners cover the Top 10?

They catch many injection, misconfiguration, dependency and cryptography issues. Access control, insecure design and business-logic flaws usually need human review and targeted tests.

How often is the list updated?

Roughly every three to four years. The previous editions were 2017 and 2021.