October 21, 2019

Last Updated on January 15, 2024

The OWASP Application Security Verification Standard (ASVS) Version 4 updates and extends the previous ASVS 3 release. We’ve been using ASVS 4 in our practice and gaining experience with how changes in the current standard impact application testing, verification and control implementation.
Among the significant changes with ASVS 4.0 are the new verification requirements at Level 1. Level 1 is now designed to be largely penetration testable via automation, without access to source code, documentation or developers. However, the total number of verifications for Level 1 has increased from 90 to 131.
Even at Level 1, ASVS 4.0 is fairly comprehensive for teams that don’t want to get into code review or architecture review or other areas that Levels 2 and above dive into.
One thing I find interesting about ASVS 4.0 is that it unabashedly “pushes the envelope” of current practice. Many current applications won’t “meet” ASVS 4’s Level 1 standard—because they don’t support multifactor authentication (MFA) and only ever ask users for a username and password. Consequently, such apps would automatically “not conform” with about 20 or more verifications.
MFA is well established as a best practice for authentication. It’s where every application “should be.” But it’s usually not an option today except on a comparatively few major platforms (e.g., Facebook, Instagram, Twitter, Bank of America, Citibank, Google Play, YouTube).
Because of the push to MFA, ASVS 4.0 has dropped requirements around password complexity, password rotation and password history that MFA renders moot. According to the standard:

When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. … This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls always have been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it’s time to move on.

Of all the sections in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that’s perfectly okay. We have to start the transition to a post-password future now. [Emphasis mine]

In other words: to achieve even a “low assurance” level of security, you need to implement MFA, period.
One potential problem with this approach is that ASVS users could get a “mixed message” when they see verifications for “don’t require complex passwords” and so on. If teams remove these controls but fail to implement MFA, they would materially weaken their security posture while “passing” more of the ASVS verifications.

“I’m excited that the OWASP ASVS 4.0 is pushing application owners in the direction of MFA due to its great security value.”


To remediate weaknesses effectively with ASVS 4.0, you need to understand the verifications are interconnected. You can’t “cherry pick” what you want to cover but must view the controls holistically when choosing a remediation path.
It might not be practical across the entire standard, but it could be useful to represent the ASVS dependencies as a “decision tree” or to flag dependent controls as subcontrols (e.g., listing “don’t require long passwords” as a subcontrol under “implement MFA”).
As a security professional on the front lines, working with ASVS 4.0 on production applications, I’m excited that the OWASP ASVS 4.0 is pushing application owners in the direction of MFA due to its great security value. But I’m concerned that this push might limit ASVS adoption because so many applications don’t yet support MFA for whatever reason(s) and will thus “fail” the base level of ASVS testing.
Will teams hoping for an ASVS “certification” or “compliance” for sales/marketing reasons choose to forego testing on that basis? I hope not…
If you’re interested verifying an application against the OWASP ASVS 4.0, or in submitting your application to a simulated attack to expose vulnerabilities, contact Pivot Point Security. We tailor our approach to your business needs.
For more information:

Free OWASP ASVS Testing Guide

If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!