“We need an OWASP test before launch.” It’s a reasonable request, but the next conversation needs to be about the application: which users it serves, what they can do, and what would go wrong if a control failed.
A customer portal with invoice downloads needs different attention from a public content site. Both are web applications. Giving each the same checklist can leave important behaviour unexplored.
Which OWASP reference do you mean?
Several OWASP resources are useful here, and they do different jobs.
The Top 10:2025 describes major web application risk categories. It gives teams a common vocabulary, but it isn’t an exhaustive testing scope.
The Web Security Testing Guide v4.2 describes testing techniques. ASVS 5.0.0 provides security requirements that can inform development and verification. The API Security Top 10:2023 adds an API perspective, including object-level and function-level authorisation risks.
An assessment can draw on several of these. Its scope should identify which versions and which applicable controls or tests it uses. “Latest OWASP” won’t tell a future reader what was assessed.
Work through a feature the business cares about
Take a portal that lets a customer export invoices. Start with the intended behaviour: a customer should be able to download invoices belonging to their own account, and an employee’s access should follow their role.
Now turn that into test questions. Can the customer request an invoice belonging to someone else? Can a read-only employee start an export? What happens to an existing download link after access is removed? Does a queued export use the same customer boundary as the request that created it?
Those questions also tell you what preparation is needed. You need more than one account, suitable roles, sample invoices, and access to the relevant export workflow. Without them, parts of the assessment may remain unverified.
Keep a record of coverage, including the gaps
A short coverage record can be more informative than a long list of scanner results:
| Area | What the record should show |
|---|---|
| Invoice ownership | The account used, the requested invoice, and the observed response |
| Export permissions | The user’s role and whether an export was created |
| Revoked access | The permission change and the behaviour afterwards |
| Queued exports | The job’s identity and the customer context used during processing |
Record exclusions and checks that couldn’t be completed. A feature that was not tested should never look the same as a feature that was tested without a finding. This matters when someone uses the report to decide whether a release can proceed.
Write for the engineer who will fix it
“Broken access control” is a category, not enough information to repair a defect. A useful finding identifies the endpoint or workflow, the access needed to reproduce it, the steps taken, and the result. It then explains the impact supported by that evidence.
For the invoice example, say which ownership check was missing and where it needs to be enforced. Include a test the developer can run after the change. If a wider impact is plausible but wasn’t verified, say so rather than presenting it as an observed result.
Retesting should record whether the original issue remains, which version was checked, and any limitations. Closing one finding doesn’t establish that every related feature is secure.
The report’s value is in those specifics. OWASP references help organise the work, but they do not confer provider certification or guarantee that every vulnerability will be found. Likewise, checking selected ASVS requirements should not be described as full verification of an ASVS level.
References
Reviewed 10 November 2026. The invoice portal is a worked example.
Have a question about your application?
Talk to Actiotech →