OWASP ASVS

ASVS, the OWASP Application Security Verification Standard, is OWASP's framework of security requirements for web applications and APIs. It's the standard MASVS was originally forked from, adapted here for a different artifact: a web application or API service running on infrastructure the organization controls, rather than a compiled binary running on a device it doesn't.

The current version, ASVS 5.0.0, organizes roughly 350 requirements into 17 chapters, verified across three levels of assurance.

What does ASVS stand for?

ASVS stands for Application Security Verification Standard. First launched in 2008, it's one of OWASP's oldest and most established projects, predating MASVS by roughly a decade. ASVS 4.0 arrived in March 2019, a minor update (4.0.3) followed in 2021, and version 5.0.0 launched on stage at Global AppSec EU Barcelona on May 30, 2025, the most significant restructuring in the project's history.

Why ASVS matters

A shared, versioned reference matters more as the number of people asked to sign off on "secure enough" grows. A developer, a pentester, a procurement team, and an auditor rarely mean the same thing by that phrase on their own. ASVS gives all four a common set of numbered requirements to refer to, rather than a subjective judgment call.

That's part of why ASVS shows up inside so many other frameworks and RFPs. Rather than restating the same security requirements in different words, compliance programs and vendor questionnaires frequently reference specific ASVS requirement IDs directly.

The 17 ASVS chapters (v5.0.0)

ASVS 5.0 groups its 17 chapters, numbered V1 through V17, into a few major domains:

Input handling

Encoding and Sanitization (V1), Validation and Business Logic (V2), and File Handling (V5), the defenses against injection, malformed input, and unsafe file uploads.

The web and API surface

Web Frontend Security (V3) and API and Web Service (V4), covering browser-side hardening, content security policy, clickjacking defenses, and backend API design.

Identity

Authentication (V6), Session Management (V7), and Authorization (V8).

Tokens and delegated access

Self-Contained Tokens (V9) and OAuth and OIDC (V10) are now new standalone chapters in 5.0. Material that sat as sub-sections of larger chapters in 4.0.3 was elevated to full chapter status, reflecting how central token-based authentication and OAuth flows have become.

Cryptography and communication

Cryptography (V11) and Secure Communication (V12).

The remaining chapters cover configuration, data protection, and related domains, running through to V17: WebRTC, an entirely new chapter in 5.0 covering real-time communication security, a technology that wasn't common enough to warrant its own chapter in 4.0.3.

What's new in ASVS 5.0

Beyond the chapter reorganization, three things changed:

Requirement count grew

ASVS 4.0.3 had roughly 286 requirements across 14 chapters. 5.0 expanded to roughly 350 requirements across 17 chapters, driven mostly by the new standalone chapters covering tokens, OAuth, and WebRTC.

Levels were streamlined, not restructured

Unlike MASVS, which moved its verification levels out into a separate testing guide (MASTG) during its own 2023 refactor, ASVS kept its three levels, L1, L2, and L3, inside ASVS itself. Level 1 was simplified for easier adoption; Levels 2 and 3 scale up from there.

Requirements now document the "why," not just the "what."

ASVS 5.0 introduced Documented Security Decisions: each chapter opens with documentation requirements capturing how a control was applied and why, rather than a bare pass/fail checklist item.

ASVS vs. MASVS

These two share more than a naming pattern. MASVS was explicitly built as a fork of ASVS, adapted for mobile.

The split is scope, not depth. ASVS 5.0 explicitly defines its focus as applications and APIs, and explicitly excludes mobile security; that's MASVS's job.

• Where ASVS covers browser-side concerns like content security policy and clickjacking (V3), MASVS has no equivalent, since there's no browser involved in a native mobile app.
• Where MASVS covers resilience against reverse engineering of a compiled binary (MASVS-RESILIENCE), ASVS has no direct equivalent, since a web application isn't typically distributed as a binary a user's device can be made to reverse-engineer.

However, the two overlap in identity and API design. ASVS's Authentication, Session Management, and API and Web Service chapters cover much of the same ground MASVS-AUTH and MASVS-NETWORK cover for mobile, just applied to a server instead of a client.

For the mobile-specific standard,

See: What is MASVS?

ASVS vs. the OWASP Top 10

The relationship mirrors MASVS's relationship to the Mobile Top 10. The Top 10 raises awareness of which risks matter most; ASVS gives a testable, versioned standard to verify an application against.

In short: you verify against ASVS, and you raise awareness with the Top 10.

Where Appknox fits

Worth being precise here: Appknox is a mobile security platform, not a general web application testing vendor, so the practical scope of this connection is narrower than full ASVS compliance.

Appknox's current ASVS mapping is built against version 4.0.3, not the newer 5.0 structure described above. Its API security testing evaluates the backend APIs a mobile app depends on, which overlaps with 4.0.3's identity and API-focused chapters, Authentication (V2), Session Management (V3), Access Control (V4), and API and Web Service (V13), rather than the full 14-chapter standard.

Chapters that call for architecture and threat modeling review, source-level malicious code analysis, or business-logic-specific manual assessment fall outside the scope of what an automated mobile testing platform can verify on its own.

For the mobile-specific standard,

See: What is MASVS?

Frequently asked questions

What does ASVS stand for?

ASVS stands for Application Security Verification Standard, OWASP's framework of security requirements for web applications and APIs.

What's the difference between ASVS and MASVS?

ASVS covers web applications and APIs. MASVS is a mobile-specific fork of ASVS, adapted for compiled binaries, on-device storage, and other realities that don't exist on the web. Where they overlap most is identity and API design.

How many levels does ASVS have?

ASVS has three levels: Level 1, Level 2, and Level 3, scaling from baseline hygiene to high-assurance requirements for critical applications. Unlike MASVS, these levels live inside ASVS itself rather than in a separate testing guide.

What changed in ASVS 5.0?

The chapter count grew from 14 to 17 and requirements grew from roughly 286 to roughly 350, with new standalone chapters for Web Frontend Security, Self-Contained Tokens, OAuth and OIDC, and WebRTC. It also introduced Documented Security Decisions, requiring teams to record how and why a control was applied.

Does Appknox test against the full ASVS standard?

No. Appknox's current mapping covers ASVS 4.0.3, not the newer 5.0 structure. Within 4.0.3, coverage is scoped to a mobile-focused platform's actual reach: API security testing overlaps with the identity and API chapters (Authentication, Session Management, Access Control, and API and Web Service), since those apply to the backend a mobile app talks to. Chapters requiring architecture review or manual business-logic assessment fall outside the scope of an automated testing platform.

Related: What is MASVS? | What is OWASP Mobile Top 10? | Appknox API Security Testing

By Aadarsh Anand, Security Researcher, Appknox Security Research Team

Appknox is an enterprise mobile application security testing platform. Appknox's security research team wrote this page based on direct experience mapping API security testing findings to ASVS and MASVS control requirements across financial services, healthcare, and enterprise mobile app portfolios. This page was drafted with AI assistance and reviewed and verified by the Appknox security research team.