OWASP Top 10 Testing Checklist for Web Apps (2025 Edition)

To test a web app against the OWASP Top 10, turn each of the ten 2025 categories into concrete checks: cross-account requests for access control, header and config review for misconfiguration, dependency audits for supply chain, and so on. Run the access-control tests first, because Broken Access Control is A01. The checklist below gives each category's tests and a pass condition.

If you would rather have this run for you, see how RAITHub would test this at the end. This is defensive, educational guidance for testing your own application. It is not a substitute for a certified penetration test where a standard or contract requires one.

Is the OWASP Top 10 2025 final, and what changed?

Yes. OWASP's project page lists the 2025 edition as "the most current released version" (OWASP Top Ten project). Compared with the 2021 list, it adds two categories, Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10), and folds server-side request forgery into Broken Access Control (OWASP Top 10:2025). Security Misconfiguration moved up to A02.

The Top 10 is an awareness document, not a test plan. For the detailed method, OWASP publishes the Web Security Testing Guide (WSTG), and for requirements you can verify, the Application Security Verification Standard (ASVS), whose version 5.0 came out in 2025. This checklist sits between them: one page, ten categories, the checks that catch most real problems in business apps.

What is on the OWASP Top 10 testing checklist?

ID	Category (2025)	What to test	Pass when
A01	Broken Access Control	As user B, request user A's records by ID through the UI and the API; as a normal user, call admin endpoints; as tenant X, request tenant Y's data; try server-side fetches of internal URLs where the app fetches a user-supplied URL	Every attempt returns 403 or 404 and no data
A02	Security Misconfiguration	Response headers, default accounts, directory listing, verbose errors, open cloud storage, CORS rules, debug modes in production	Headers present, no defaults, errors generic, CORS limited to known origins
A03	Software Supply Chain Failures	Dependency audit, lockfile committed, packages exist and are the intended ones, CI secrets scoped, build pipeline protected	No unexplained high or critical advisories; every dependency is known and pinned
A04	Cryptographic Failures	TLS everywhere, HSTS, password hashing algorithm, secrets at rest, sensitive data in URLs or logs	Modern TLS only; passwords hashed with a slow algorithm; no secrets in URLs or logs
A05	Injection	Textbook inputs such as ' OR '1'='1 in search and filter fields, <script>alert(1)</script> in names and comments, shell metacharacters where files are processed	Input treated as data: no query change, no script runs, no error leak
A06	Insecure Design	Business rules under abuse: negative quantities, coupon reuse, skipping a step in a multi-step flow, race conditions on balances and stock	The server enforces every rule, whatever order requests arrive in
A07	Authentication Failures	Rate limits on login and reset, account enumeration in error messages, session expiry and rotation, MFA bypass, reset-token reuse	Limits trigger; messages are identical for known and unknown users; tokens single-use
A08	Software or Data Integrity Failures	Webhook signature checks, unsigned updates or serialized objects accepted from clients, CI deploying unreviewed code	Unsigned or tampered payloads are rejected
A09	Security Logging and Alerting Failures	Failed logins, permission denials and admin actions are logged with who and when; an alert reaches a person	A burst of failed logins produces a log trail and an alert someone reads
A10	Mishandling of Exceptional Conditions	Malformed JSON, missing fields, huge payloads, timeouts from downstream services, partial failures mid-transaction	The app fails closed: access denied, transaction rolled back, no stack trace

How do I test for broken access control (A01)?

With two accounts per role and a list of every endpoint that returns or changes data. For each one, make the request as the wrong user. This is the insecure direct object reference test, or IDOR, and no scanner does it for you, because both requests look valid to a tool that does not know who owns what.

Write the cases as automated tests so they run on every build. A minimal Playwright API test:

import { test, expect } from '@playwright/test'

const endpoints = ['/api/orders/', '/api/invoices/', '/api/customers/']

for (const path of endpoints) {
  test('tenant B cannot read tenant A data at ' + path, async ({ request }) => {
    const res = await request.get(path + process.env.TENANT_A_RECORD_ID, {
      headers: { Authorization: 'Bearer ' + process.env.TENANT_B_TOKEN },
    })
    expect([403, 404]).toContain(res.status())
  })
}

Sundor Skin, a B2B wholesale platform RAITHub built, runs a 21-case IDOR suite in CI that tries to read other buyers' data, backed by PostgreSQL row-level security (Sundor Skin case study). If your product is multi-tenant, the row-level security guide shows how to enforce the boundary in the database, and what to do if users can already see another tenant's data covers the incident.

How do I check security misconfiguration and headers (A02)?

Start with one command against production: curl -sI https://your-app.example. Look for Strict-Transport-Security, Content-Security-Policy, a frame-ancestors rule or X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Then break a request on purpose and read the error. A stack trace, SQL fragment or file path in the response is a finding. Finally check CORS: a response that echoes any Origin back with credentials allowed is a serious one.

How do I test the supply chain (A03)?

Run your package manager's audit, for example npm audit --omit=dev, in a clean clone, and read the advisories rather than counting them. Confirm the lockfile is committed and CI installs from it. Check that every dependency is one you meant to add: researchers at USENIX Security 2025 found that code-generating models suggest packages that do not exist, which attackers can then register (Spracklen et al., USENIX Security 2025). Review who can change CI secrets and deploy settings.

How do I test injection safely (A05)?

Use textbook inputs on your own app in a test environment, never on systems you do not own. A single quote in a search box should not change the results or produce a database error. A script tag saved as a display name should render as text. The fix is almost always the same: parameterised queries, an output-encoding template engine, and server-side validation of every field. If injection tests pass but the code builds SQL by joining strings, treat it as a finding anyway; it is one refactor away from failing.

How do I test business logic and exceptions (A06 and A10)?

Read the rules first, then try to break them in ways a real user could. Send the checkout request twice at once to see whether stock or credit is spent twice. Skip the payment step and call the confirmation endpoint directly. Send a malformed body and a timeout from a mocked payment provider, and check that the order is not marked paid. A10 is new in 2025 for a reason: an app that "fails open" on an unexpected error, for example granting access when the permission service times out, turns an outage into a breach.

Payment flows deserve their own tests; testing payments and webhooks covers signature checks (A08) and retries.

How long does a full OWASP Top 10 pass take?

For a small app with two or three roles and under 50 endpoints, a developer who knows the stack can do a first pass in 2–4 days, plus time to fix what it finds. A multi-tenant SaaS with many roles takes longer, mostly in A01 and A06. The main risk of doing it yourself is blind spots: the person who wrote the access rules tends to test the cases they already thought of. A second person, or a second company, finds the rest.

Is the OWASP checklist the same as a penetration test?

No. Checking an app against the Top 10 is application-level security testing. A penetration test is a scoped engagement by an independent tester, usually with a formal report that auditors and buyers accept. If PCI DSS, a SOC 2 auditor, a regulator or an enterprise contract asks for a pentest, you need a certified pentest vendor. Penetration testing vs vulnerability scanning vs security testing explains the difference, and the security testing cost guide gives market prices.

Buy, build or hire?

Route	Choose this when
A tool or SaaS testing platform (scanner, DAST, dependency scanning)	You want continuous coverage of A02, A03 and parts of A05. It will not find most A01 and A06 issues.
Freelancers or crowdtesting	Your app is public and stable, and you can triage a stream of reports. Testers rarely get the multi-role access deep logic testing needs.
An in-house QA or security hire	You ship often, hold sensitive data and have a year's worth of testing work.
A managed QAaaS team	You want the whole checklist run with real roles and written up as tests in your CI, without hiring. Not a certified pentest.

Why RAITHub for this

• Access control first. RAITHub's own builds enforce isolation in the database and test it in CI, as on Sundor Skin with its IDOR suite and 530+ tests.
• Findings become tests. Each confirmed issue comes back with a fix and a test that fails if it returns.
• Plain limits. RAITHub is not SOC 2 or ISO 27001 certified and does not issue pentest attestations, and says so before you buy.

When you don't need RAITHub

• You need a certified pentest report for PCI DSS, an auditor or a contract. Use an accredited firm.
• Your app has one role and no stored personal data. The 20-point security checklist and a scanner may be enough.

How RAITHub would test this

• Scope: a role and endpoint map, tenants and money flows, agreed in writing.
• Testing: all ten OWASP Top 10:2025 categories, following the WSTG, with the heaviest effort on A01, A06 and A07.
• Automation: cross-account and cross-tenant cases written as API tests in your CI.
• Report: findings with severity, steps to reproduce and fixes, then a retest.

Buy it as a fixed-price one-off security audit, as part of a monthly QA plan, or through a dedicated QA team RAITHub manages. You receive the report, the tests in your repository and full IP under NDA. See security testing and QA as a service. Next step: book the free 15-minute technical audit, then get a written fixed quote.

Last reviewed: 7 October 2026.

Frequently asked questions

What are the OWASP Top 10 2025 categories?

A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions.

Which OWASP Top 10 category should I test first?

A01 Broken Access Control. Sign in as one user and try to read or change another user's or tenant's records through the API. It is the category scanners miss most and the one that exposes customer data.

Can an automated scanner cover the OWASP Top 10?

Partly. Scanners help with misconfiguration, known-vulnerable dependencies and some injection. They cannot judge access control or business rules, so A01 and A06 need a person or tests written with knowledge of who owns what.

Is the OWASP Top 10 a compliance standard?

No. It is an awareness document about the most common web application risks. For verifiable requirements, OWASP publishes the ASVS. Standards such as PCI DSS reference secure coding practices but set their own requirements.

How often should I run the OWASP checklist?

Run the automated parts, such as access-control tests and dependency audits, on every build. Repeat the manual pass before major releases, after changes to roles or authentication, and at least once a year.

Does passing the checklist mean my app is secure?

It means the most common classes of flaw were tested and not found. It is not a guarantee, and it is not a penetration test. Keep the tests running, and add a certified pentest when a buyer or standard requires one.