Use the OWASP Top 10 to start a risk conversation and find areas worth examining. To create a test plan, translate a category into the application’s actual assets, actors, entry points, expected controls, versioned requirements, methods and evidence. “We scanned for all ten categories” does not say which paths were exercised or reviewed, which controls were checked, or whether the results are complete. OWASP calls the Top 10:2025 an awareness document and a starting place, not a complete list. The right plan changes with the application: a multi-tenant export API needs different cases from a static information site, even though both can be discussed under the same Top 10 heading.
The Top 10 is useful precisely because it is memorable. The current 2025 edition names categories such as Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Insecure Design and Mishandling of Exceptional Conditions. Those categories describe broad risk families. They are not ten executable checks. A single category may touch many endpoints, background jobs, identities and deployment choices.
The three documents do different jobs
| Resource | Best use | What it does not supply on its own |
|---|---|---|
| OWASP Top 10:2025 | Explain major classes of web application risk to stakeholders and prompt initial discovery. | A complete application-specific scope or pass/fail verdict. |
| ASVS 5.0.0 | Choose versioned, verifiable security requirements and an appropriate target level. | An automatic method for proving each requirement in this deployment. |
| OWASP Web Security Testing Guide | Plan and conduct defined web application testing activities. | Knowledge of your private business rules, ownership model and deployment. |
OWASP itself explains that ASVS requirements intentionally avoid prescribing a particular implementation or verification method. Its guidance points developers to the Cheat Sheet Series for implementation and verifiers to the WSTG for methods. This is a useful separation: decide what must hold, decide how to check it here, then record what actually happened. See “What is the ASVS?”.
Two categories produce different evidence plans
Synthetic planning exercise: Meridian Tasks lets a member read a project and start an export. Its policy service is external to the API process. The sponsor asks for “Top 10 coverage,” but two relevant risk families require different work.
The 2025 A01 Broken Access Control category prompts an object-access question. A10:2025 Mishandling of Exceptional Conditions prompts a failure-path question: what happens when the policy service times out? The source currently catches the timeout and substitutes an empty permission object. Without inspecting the downstream interpretation, that object could mean deny, allow-by-default or an application error. The category label does not decide it.
| Planning card | Object access | Exceptional condition |
|---|---|---|
| Application rule | Member may read only an entitled project | If current authority cannot be established, no new protected read/export is admitted; failure remains observable |
| Input/complication | Own project, same-account project without entitlement, foreign project, and any explicitly shared project | Policy timeout before read, after admission and during retry |
| Requirement input | Selected ASVS v5.0.0-8.2.2 and 8.4.1, exact text retained | Select relevant ASVS error/resource/authorization requirements from catalog; no assumed one-to-one A10 mapping |
| Source evidence | Identity binding, mandatory object decision, query and output | Catch/fallback semantics, default permission interpretation, retry and cleanup branches |
| Configuration evidence | Actual identity/policy routing | Timeout/retry settings and alternate endpoint behavior |
| Proposed controlled observation | Allowed own-project and denied foreign-project pair | Induced timeout yields no protected content or admitted job; ordinary retry recovers without duplicate effect |
| Required output | Scoped object-access conclusion | Failure-state transition and bounded operational event, with any residual work named |
These are proposed checks, not performed tests. Product must first confirm the intended failure rule and whether already admitted work has a separate mandate. A generic “fail closed” instruction cannot decide how to settle an already completed payment or clean up a canceled job. The plan names the exact protected action and boundary.
The cards also expose a third kind of work. A welcome discount that is intended once per account but issued once per order needs an explicit product invariant and ledger analysis. It can be discussed under broad risk categories, but neither a category name nor ten scanner checkboxes supplies that rule. The business-logic guide shows the different evidence progression.
The plan is complete enough to start when the reviewer knows the input, expected effect, decisive control, method and outcome record for each question. It is not complete merely because every category has a row.
Turn a category into a usable plan
1. Pin the release and map the flows. Identify the deployed revision or artifact, not just the default branch. List entry points, identity providers, data stores, background consumers, external APIs and relevant configuration. If the inventory is incomplete, the scope is incomplete too.
2. Write expected behavior in plain language. State actor, permitted action, object, tenant or owner, and denial rule. “A user cannot access another customer’s project” is useful; “check A01” is not. Have the feature owner confirm the rule and any legitimate exceptions.
3. Choose versioned requirements. Select applicable ASVS 5.0.0 requirements and explain any N/A. The ASVS guidance on applicability notes that unused technologies can make sections irrelevant. It does not permit skipping a requirement simply because a scanner lacks a detector.
4. Choose methods matched to the question. Source review may establish how a check is written and called. Configuration review can identify actual gateway or storage policy. A controlled check in an authorized environment can show behavior for selected cases. Architecture or operational records may be necessary for documentation and process requirements. No single method automatically supplies all evidence. The WSTG is a method resource, not a substitute for the app-specific rule.
5. Predefine outcomes. Record checked and supported, failed with verified evidence, unresolved because evidence is missing, or not applicable with rationale. A scanner alert is a lead. A missing alert is not a pass. An observed denial in one case is not proof that every route enforces the rule.
6. Report both findings and coverage. Give the count and status of verified issues, but also the paths and requirements examined, exclusions, failed work and unknown deployment assumptions. This lets a reader tell a narrow clean result from a thorough assessment.
Walk the failure card through three different outcomes
The Meridian timeout card is useful because it defines a specific protected action. Extend it with three possible findings from an authorized review; these are invented branches, not observed behavior.
In the first branch, the downstream permission interpreter treats the empty object as no grants. The API refuses the new export and emits a bounded operational error. The reviewer records support for the inspected timeout-before-admission path, with deployment and other failure cases limited to the evidence supplied. The original suspicious catch block does not become a vulnerability merely because its code looked unusual. The important fact is how the fallback value is used before the protected effect.
In the second branch, the interpreter treats a missing role field as a default member role and admits the export. The reviewer now has a concrete source-supported concern: failure to obtain current authority can lead to a protected action through the defaulting path. The next work is to check the real policy contract, deployment and relevant countercontrols, then select a proportionate correction. The category explains why the question mattered; the path evidence explains the candidate.
In the third branch, a timeout happens after a job has already been admitted under a valid decision. The retry handler creates another job because it cannot determine whether the first request completed. The main question becomes duplicate-effect prevention and how admission is recorded. Calling this simply “fail open” would blur the mechanism. The plan needs a separate state-transition question and expected handling for the ambiguous result.
These branches demonstrate why a category checklist cannot substitute for application knowledge. All concern exceptional conditions, but they produce a supported narrow behavior, an authorization candidate, and a duplicate-work question. Their owners and corrective changes differ.
Make expected behavior explicit for legitimate exceptions
Meridian permits some projects to be shared with invited members. The object-access card must include that path, or a test that denies every cross-account request could look secure while breaking a promised feature. Have the product owner state who can share, which operations are granted, how the recipient is identified, and what revocation means. Then ask whether the service enforces that rule for detail, export and delivery.
A same-account member without project entitlement is equally important. A check that proves tenant equality may still be insufficient for the feature's policy. The plan should distinguish tenant membership from permission to the selected project. Those facts can contribute to the same access decision without being interchangeable.
Write positive and negative expectations in terms of the business rule. “Invited collaborator can read the shared project but cannot export an unrelated project” is more useful than “cross-tenant request denied.” It gives the reviewer an expected success case, a forbidden case and a reason each result matters. Any real exercise still needs authorization, synthetic data and a bound environment.
Report completed questions under the category
At the reporting stage, keep the category as a navigation label. Beneath it, list the actual questions, methods and outcomes. For Meridian, object-read authorization may be supported for selected routes while export delegation remains unresolved; the timeout-before-admission case may be reviewed while the post-admission retry remains unassessed. A single green A01 or A10 cell would collapse those differences.
If the sponsor asks whether the team covered all ten categories, answer with the planning boundary: which categories informed discovery, which application questions were selected, and which work was performed. Offer the requirement and evidence map for the detailed view. This preserves the Top 10's value as an accessible conversation starter while giving engineers a plan they can carry out and buyers a result they can inspect.
A one-paragraph plan you can reuse
Category prompt: OWASP Top 10:2025 A01 Broken Access Control. Application rule: members may operate only on projects for which the service establishes their current entitlement; account ownership is necessary in the ordinary tenant flow but does not grant every member every project. Scope: Meridian Tasks API, export worker and delivery configuration at release
M92F. Requirements: ASVS 5.0.08.2.2and8.4.1; evaluate8.3.3for service handoff. Method: trace server-side authorization and data reads, inspect deployed policy, perform authorized cross-account checks on selected routes. Outcome rule: record evidence per path; unavailable worker or deployment mapping makes the relevant result unresolved. Owner: security engineer, with API and platform owners supplying missing evidence.
The Top 10 helps you choose where to look. The plan says what you will decide and how you will know. Begin with one important user action and complete that paragraph. Then read how to choose an ASVS level if you need a stable requirement baseline, or how to measure monorepo scope when the plan spans more code than one review can finish.