What an OWASP-based security assessment covers — and what it does not

Security assessment is a term with almost no fixed meaning. It is applied to an automated scan that takes twenty minutes and to a four-week engagement by a specialist team, and the two produce documents that superficially resemble each other.

This is what an OWASP-based assessment of a web application or API covers, what it deliberately does not, and how to tell which one you are being sold.

What "OWASP-based" means

OWASP — the Open Worldwide Application Security Project — publishes the closest thing the industry has to a shared reference for web application security. Two documents matter for scoping. The OWASP Top 10 is a widely recognised list of the most impactful web application risk categories. The Application Security Verification Standard is the far more detailed checklist that a serious assessment actually works through.

An assessment described as OWASP-based should mean the methodology follows those references systematically, rather than the tester poking at whatever they happen to think of. It is a statement about coverage and repeatability.

If a supplier says "OWASP-based" and cannot tell you which categories they covered and which they excluded, the phrase is decoration.

What is covered

For a typical web application and its API, an assessment works through categories including:

• Access control — whether a user can reach data or actions belonging to another user, or escalate their own role. Consistently the most commonly found serious issue, and the one scanners are worst at.
• Authentication and session handling — credential policy, session lifetime and invalidation, multi-factor handling, password reset flows, and what happens on logout.
• Injection — SQL, command, template and similar, across every input the application accepts, including ones not exposed by the interface.
• Cryptographic handling — data in transit and at rest, certificate and TLS configuration, storage of secrets and password hashing.
• Security misconfiguration — headers, error handling that leaks internals, default credentials, unnecessary exposed services, permissive CORS.
• Vulnerable dependencies — known issues in libraries the application relies on, and whether the affected code path is actually reachable.
• Business-logic flaws — sequences that are individually permitted and collectively harmful. Ordering with a negative quantity, skipping a payment step, replaying a one-time action.

The last category is the one that separates an assessment from a scan. Business-logic flaws are invisible to automated tools because every individual request is legitimate. Finding them requires someone who understands what the application is for.

What is not covered

Being clear about exclusions is more useful than an expansive list of inclusions.

• It is not a certified penetration test. If a customer contract, insurer or compliance framework requires a formal pentest with specific attestation, an assessment does not satisfy it. These are different products with different paperwork.
• It is not a network or infrastructure audit. The scope is the application and its API, not your firewall rules, VPN or endpoint estate.
• It is not a social-engineering exercise. Nobody phones your staff or tests whether they click links.
• It is not a compliance certification. An assessment can supply evidence toward SOC 2, ISO 27001 or a customer security questionnaire, but it is not itself an audit and no assessor can certify you.
• It is not permanent. It describes the application on the dates it was tested. Ship a significant feature and that snapshot ages immediately.

How to read the report

The report is the deliverable, and its quality is where suppliers differ most. A useful one contains, for every finding:

1. 01A severity rating with the reasoning behind it, not just a colour. Severity depends on exploitability and impact in your context — an identical technical issue can be critical in one application and negligible in another.
2. 02Reproduction steps precise enough for your developer to trigger it without contacting the assessor.
3. 03The actual impact, in business terms. "Any authenticated user can read any other user’s invoices" beats "IDOR vulnerability".
4. 04Specific remediation guidance for your stack, not a link to a generic article.
5. 05A retest position — whether the fix was verified, and when.

A report that is mostly a tool export with severity labels attached is a scan wearing a report as a costume. The tell is volume: hundreds of low-severity findings with near-identical wording, and nothing that required understanding the product.

When to get one

The three moments where an assessment reliably pays for itself: before a launch that will materially increase your exposure; when an enterprise customer sends a security questionnaire you cannot honestly complete; and after a significant architectural change, particularly one that touches authentication or authorisation.

The moment it pays least is immediately after a breach, when what you need first is incident response, not a methodical review.