Implementing OWASP ASVS

The Application Security Verification Standard (ASVS), developed by the OWASP foundation, contains a list of requirements for building and maintaining secure applications. In this blog, I will share my insights from implementing this standard in an existing project, from a backend developer perspective.

ASVS logo: source

Introduction to ASVS

ASVS is a comprehensive framework for verifying application security. It can be used as an overview guideline for pen-testing, an application-content-oriented secure coding checklist, or security architecture guidance. By following ASVS, you can identify and mitigate security risks, ensuring your application meets industry best practices.

If you are looking for more detailed information about how to use it in your project, I recommend a blog post by one of the ASVS maintainers: How to use OWASP ASVS.

ASVS is divided into 14 chapters, including areas like Authentication, Access Control, Data Protection, API Security, Configuration Hardening, Threat Modeling, etc., providing 286 specific requirements/controls in total. They can be referred to and organized in <version>-<chapter>.<section>.<requirement> format.

ASVS is also organized into three verification levels:

• Level 1: Covers vulnerabilities that are easy to discover - a bare minimum. It can be completely checked by penetration testing without accessing the source code.
• Level 2: Defends against most of the risks in the software world today. Recommended for most applications.
• Level 3: This level is reserved for applications that require a significant level of security, typically data in sectors such as finance, medical, and military.

ASVS verification levels

The latest ASVS stable version is v4.0.3, released in 2021. The next major version is being actively developed, and according to the Roadmap to version 5.0 from the end of 2024, we are in the final countdown to the ASVS 5.0.

Example of the ASVS requirement

Let’s look at an example of ASVS requirement v4.0.3-3.2.1 from Chapter 3: Session Management:

Requirement v4.0.3-3.2.1, source: OWASP ASVS

It highlights the need to generate a new session token upon user authentication, a critical control to prevent session fixation attacks. We can see it applies to all ASVS levels (L1, L2, L3).

Every requirement consists of a description of 1-3 sentences and an ID of specific Common Weakness Enumeration (CWE) - a list of common software and hardware security weaknesses, maintained by the MITRE Corporation.

Some of the requirements also include a link to the specific chapter of OWASP Top 10 Proactive Controls - in the example: C6: Implement Digital Identity.

Chapter 2: Authentication & Chapter 3 are also associated with NIST 800-63b - a U.S. government agency authentication-related standard.

Implementing ASVS level 2

Recently, together with a team, I was faced with the requirement of implementing ASVS on level 2 - it was set from the top as the organization standard. To be clear, there is no official OWASP “certification” for achieving the ASVS level. Verification would be made by penetration testing and internal security team audit based on a self-assessment sheet with acceptable comments confirming each of the requirements. Additionally, the ASVS compliance check would be performed annually, ensuring the system remains aligned with the standard over time.

The project I worked on, was a microservice-based system deployed on Kubernetes in the Azure public cloud. It exposed a few UIs written in React. The backend was written in Scala, so it runs on the JVM and uses Scala/Java libraries.

The project is around 3 years old, so it can be considered as mature and was rather developed with application security in mind.

ASVS v4.0.3 level 2 consists of 267 requirements. After checking each requirement step-by-step, we found that:

• More than half of the requirements were easy to identify and were already met.
• 80 requirements were determined to be not applicable in our case.
• Some requirements required deeper research to confirm our compliance.
• A subset of requirements was not passed and fixes or improvements were needed.

It showed that while many controls may already be in place, reaching the full ASVS targeted level often requires careful review, in-depth research, and targeted fixes.

Insights from implementation

ASVS level 2, consists of a range of requirements - among all 267, some are straightforward, while others are more challenging. Here are some specific ASVS v4.0.3 requirements from many different areas, divided into categories, that I think might be interesting.

Easy Requirements

1.11.1 Verify the definition and documentation of all application components in terms of the business or security functions they provide. L2, L3 - CWE 1059

• The easiest requirement to confirm, as we keep our system documentation up-to-date from the very beginning.

5.5.2 Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features, such as resolving external entities are disabled to prevent XXE. L1, L2, L3 - CWE 611

• XML eXternal Entity injection (XXE) was included at number 4 in OWASP Top Ten in 2017.
• To prevent XXE attack, we are following the respective recommendations from OWASP Cheat Sheet about XML Entity Prevention - completely disabling DTDs (Document Type Definition) & External Entities.

val xmlInputFactory = XMLInputFactory.newFactory()
xmlInputFactory.setProperty(
    XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false)
xmlInputFactory.setProperty(
    XMLInputFactory.SUPPORT_DTD, false)

Non-Applicable Requirements

2.1.1 - 2.1.12 The whole section about password security. L1

• This section covers password security best practices, focusing on strong, user-friendly policies like long passwords, paste functionality, and breached password checks.
• Azure Entra ID is being used for login and password settings - it can be properly configured to meet security standards. You can also check Entra’s recommended best practices to increase your security level.
• In our specific case, requirements can be treated as non-applicable as we don’t have control over Entra ID - it is managed by another internal team that also needs to pass the ASVS check.

2.5.1 Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. L1, L2, L3 - CWE 640

• Since the system is internal (requires email in the company domain), there is no typical registration. The recovery function is realized by Entra ID, in our case managed by another internal team.

Engaging Requirements

1.2.1 Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. L2, L3 - CWE 250

• Thanks to this requirement, we identified several docker images that needed migration from root-based accounts to low-privilege accounts to ensure each service runs with minimal permissions - running containers as a non-root user reduces the potential impact of a security breach.
• This is something that could have been handled correctly from the very beginning of each docker file.
• To learn more about the risks associated with running containers as root, check out Container is running in privileged mode on Snyk Academy.

1.14.4 Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts. L2, L3 - CWE 923

• Automating secure deployment could be challenging due to the need to integrate multiple tools, balance speed with security, or manage false positives.
• We meet this requirement by using:
  1. Secret Scanning and Code Linting - in the pre-commit phase
  2. Fortify & SonarQube- in pipeline SAST (static application security testing) - weekly scan
  3. Qualys - in pipeline DAST (dynamic application security testing) - monthly scan
  4. Snyk - in pipeline SCA (software composition analysis) - weekly scan

14.4.3 Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities. L1, L2, L3 - CWE 1021

• Configuring CSP involved extensive configuration, testing, and collaboration with external services to ensure maximum protection against XSS while maintaining application functionality.
• By the use of Kubernetes' ingress controller - specifically, Project Contour which runs Envoy underneath - the incoming traffic can be managed, and response headers can be rewritten with appropriate CSP configuration. This solution centralizes and ensures consistency across all services.
• Introducing CSP late in development may not have been the most challenging - OWASP Content Security Policy Cheat Sheet was very helpful - but again, this is something that could have been handled more efficiently from the very beginning of the project.

Interesting Requirements

6.3.2 Verify that random GUIDs are created using the GUID v4 algorithm, and a cryptographically-secure pseudo-random number generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable. L2, L3 - CWE 338

• I found this interesting because it highlights the importance of randomness quality, even for GUIDs
• While standard pseudo-random number generators (like java.util.random()) are not cryptographically secure but would be caught by some SAST scans, I can imagine a situation where developers accidentally used GUID versions older than v4.
• To meet this requirement by using java.util.UUID.randomUUID() in the backend and random_password resource in Terraform which are cryptographically secure.

8.3.7 Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. L2, L3 - CWE 327

• In short, we are using an encryption process that secures data exchanged between services. There is a need to hide some of the sensitive data from not entitled services. The originating service, which interacts with many other services, encrypts data using a custom Encryption Service which provides data encryption-at-rest. Only strictly defined receiving services decrypt data securely when needed.
• We are using the AES/ECB/PKCS5Padding encryption algorithm. ECB mode (electronic code book) is the simplest and generally not recommended encryption mode - it would for sure attract the attention of every auditor.
• However, in our use-case, this approach is acceptable due to nuances of internal architecture (in short words, generating a unique secret key for each value which is max 128 bit (1 block) size).
• This example underscores how security requirements can be satisfied through thoughtful design choices, even when e.g., using encryption modes that typically raise red flags.

13.2.2 Verify that JSON schema validation is in place and verified before accepting input. L1 - CWE 20

• We use Circe, a JSON library for Scala to parse and validate JSON request entities.
• However, while Circe validates against Scala’s case class structures, this process occurs during parsing and may not strictly meet the requirement of validating input before acceptance, as defined in the formal JSON Schema standard.
• What’s interesting - (as per the following ASVS github discussion) - in the next major ASVS version, this requirement has been moved from L1 to L3 verification level - due to that, we decided to leave this as is.

Summary

The OWASP ASVS is a practical framework for improving application security by providing clear requirements - as a structured secure coding checklist.

What I also like is that you can also adopt only parts of ASVS as needed. For example, if you’re introducing a new API, you can focus on the API Security chapter to ensure secure endpoints. Similarly, if adding a new authentication module, you can apply the Authentication chapter to enforce secure login practices. ASVS is flexible, allowing you to strengthen security incrementally as your system evolves.

Through the examples shared in this blog, I hope it’s clear how ASVS can be handled and implemented, in, e.g., existing projects - by carefully reviewing requirements, making thoughtful design choices, and integrating security practices into your workflow.

If you're looking for developers who build systems using the highest standards of Secure Software Development Lifecycle (SSDLC), reach out to us - we leverage the best tools and practices, including our technological partnership with Snyk, to ensure your software is secure.

Additionally, check out our free eBook: Cybersecurity: developing a security-first mindset, for valuable insights on building secure applications.

Reviewed by: Krzysztof Ciesielski