> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/owasp-asvs.md).

# OWASP ASVS

What the OWASP Application Security Verification Standard is, how its levels and chapters work, and how Heeler uses it.

The **OWASP Application Security Verification Standard** — ASVS — is an open list of the security requirements a web application or API is expected to meet. It is maintained by the OWASP Foundation, and it is one of the standards Heeler assesses against.

Its usefulness is that it is *specific*. Where a policy might say "handle input safely," ASVS says:

> **v5.0.0-1.2.5** — Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.

That is a claim you can hold a codebase to. Heeler assesses against **ASVS 5.0.0**.

## Levels

ASVS defines three **assurance levels**. They are **cumulative** — Level 2 contains every Level 1 requirement and adds to it.

| Level  | Requirements | Roughly, for                                                                   |
| ------ | ------------ | ------------------------------------------------------------------------------ |
| **L1** | 70           | Any application. The baseline everything should meet.                          |
| **L2** | 253          | Applications handling sensitive data or transactions — most business software. |
| **L3** | 345          | The highest-assurance applications, where a breach is severe.                  |

This is why an application's score reads *"209 of 253 require manual verification"* rather than a percentage of some absolute total: the denominator is the level you are being measured against.

Heeler assesses every level for every application, but shows one as the **target**. See [how the target level is chosen](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#the-target-level).

## Chapters

The 345 requirements are grouped into 17 chapters. The **Chapters** panel on an assessment breaks the score down by chapter, which is usually how you decide what to work on first.

|                                             |                                      |                                        |
| ------------------------------------------- | ------------------------------------ | -------------------------------------- |
| **V1** Encoding and Sanitization            | **V2** Validation and Business Logic | **V3** Web Frontend Security           |
| **V4** API and Web Service                  | **V5** File Handling                 | **V6** Authentication                  |
| **V7** Session Management                   | **V8** Authorization                 | **V9** Self-contained Tokens           |
| **V10** OAuth and OIDC                      | **V11** Cryptography                 | **V12** Secure Communication           |
| **V13** Configuration                       | **V14** Data Protection              | **V15** Secure Coding and Architecture |
| **V16** Security Logging and Error Handling | **V17** WebRTC                       |                                        |

## Reading a requirement key

Requirement keys look like `v5.0.0-11.3.1`, and every part carries meaning:

| Part     | Means                                                                                                |
| -------- | ---------------------------------------------------------------------------------------------------- |
| `v5.0.0` | The ASVS version. Keys embed it so an assessment from six months ago still means what it meant then. |
| `11`     | The chapter — here **V11 Cryptography**.                                                             |
| `3.1`    | The section and requirement within that chapter.                                                     |

Elsewhere in Heeler you will see the shorter display form with the level attached — **V11.3.1 (L1)** — on [guardrail bundle](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md) controls and on a SAST finding's Rule Details.

## What Heeler adds

ASVS is a list of requirements, not a tool. What Heeler contributes is the mapping from those requirements to **evidence it already collects** — your SAST findings, dependency vulnerabilities, secrets, endpoint authentication, SBOM coverage, CI/CD posture and enforced guardrails — so that a subset of the standard can be answered from what your code actually does rather than from a questionnaire.

That mapping is deliberately conservative, and [Assessments](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md) explains where its limits are.

{% hint style="info" %}
Requirement text throughout Heeler is reproduced from OWASP ASVS 5.0.0, © OWASP Foundation, licensed CC BY-SA 4.0. The attribution appears at the foot of every assessment view.
{% endhint %}

## Related

* [Assessments](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md) — how Heeler scores an application against the standard.
* [Guardrail Bundles](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md) — enforcing the parts of a level that can be enforced.
* [EU Cyber Resilience Act](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/eu-cyber-resilience-act.md) and [DORA](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/dora.md): the other standards Heeler assesses against.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/owasp-asvs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.