asvs/overview

51 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

ASVS Definition and Purpose

The Application Security Verification Standard is a list of application security requirements that architects, developers, testers, security professionals, tool vendors, and consumers can use to define, build, test, and verify secure applications.

ASVS 5.0 key principles: Refined Scope and Focus

ASVS 5.0 aligns directly with the foundational pillars: Application, Security, Verification, and Standard. Requirements have been rewritten to emphasize the prevention of security flaws rather than mandating specific technical implementations. Requirement texts are intended to be self-explanatory, explaining why they exist.

ASVS 5.0 key principles: Support for Documented Security Decisions

ASVS 5.0 introduces requirements for documenting key security decisions. This enhances traceability and supports context-sensitive implementations, allowing organizations to tailor their security posture to their specific needs and risks.

ASVS 5.0 restructured and expanded content

ASVS 5.0 chapters have been reorganized for clarity and usability. A two-way mapping between v4.0 and v5.0 is provided to facilitate migration from the previous version.

ASVS 5.0 three-level model

ASVS 5.0 retains its three-tier model with evolved level definitions. Level 1 is designed as the initial step to adopting the ASVS, providing the first layer of defense. Level 2 represents a comprehensive view of standard security practices. Level 3 addresses advanced, high-assurance requirements.

ASVS 5.0 scope and content

ASVS 5.0 includes approximately 350 requirements across 17 chapters. The standard is designed to provide a comprehensive set of security requirements for designing, developing, and testing modern web applications and services.

Penetration testing requirements beyond black box testing

Testing without access to necessary additional information is an inefficient and ineffective mechanism for security verification, as it misses the opportunity to review source code, identify threats and missing controls, and perform a more thorough test in a shorter timeframe. Documentation or source code-led (hybrid) penetration testing with full access to application developers and documentation is strongly encouraged and will be necessary to verify many ASVS requirements.

Automated testing principles for ASVS verification

For less straightforward ASVS requirements, application-specific verifications need to be written to achieve automated testing coverage. These may be similar to unit and integration tests that an organization already uses. Using existing test automation infrastructure to write ASVS-specific tests requires short-term investment but provides long-term benefits of continual verification.

ASVS certification report requirements

An ASVS certification report should include: scope, a summary of all requirements checked, the requirements where exceptions were noted, and guidance on resolving issues. Requirements that are non-applicable must be noted in the report, such as session management in stateless APIs.

OWASP does not certify ASVS compliance

OWASP, as a vendor-neutral nonprofit, does not certify any vendors, verifiers, or software. Any assurance, trust mark, or certification claiming ASVS compliance is not officially endorsed by OWASP. Organizations should be cautious of third-party claims of ASVS certification.

Scope specification in verification reports

The verifier should make the scope of verification clear by identifying which Level the organization is attempting to achieve and which requirements were included. The scope should be presented from the perspective of what was included rather than what was not included. The verifier should also provide an opinion on the rationale for excluding requirements that haven't been implemented.

Testing methods must be disclosed and repeatable

Certifying organizations can choose their testing methods but should disclose them in the report. The testing methods should ideally be repeatable. Different methods, such as manual penetration tests or source code analysis, may be used to verify aspects like input validation depending on the application and requirements.

Evidence requirements for ASVS verification

It is standard practice to provide robust evidence of findings with detailed documentation for ASVS verification, which may include work papers, screenshots, scripts, and testing logs. Merely running an automated tool without thorough testing is insufficient for certification, as each requirement must be verifiably tested.

Limitations of automated security testing for ASVS

Automated security testing tools such as DAST and SAST may identify some security issues and can provide coverage of basic technical requirements relating to output encoding or sanitization. However, these tools are unable to entirely verify many of the more complicated ASVS requirements or those that relate to business logic and access control.

V2 Validation and Business Logic - Control Objectives

The V2 chapter aims to ensure that a verified application meets the following high-level goals: Input received by the application matches business or functional expectations. The business logic flow is sequential, processed in order, and cannot be bypassed. Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers or adding a million friends one at a time. High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks.

ASVS 5.0 new chapters: Self-contained Tokens and Web Frontend Security

Self-contained tokens, formerly grouped under session management, are now recognized as a distinct mechanism and foundational element for stateless communication such as in OAuth and OIDC. Due to their unique security implications, they are addressed in a dedicated chapter with some new requirements introduced in version 5.x. Web Frontend Security requirements have been separated into their own chapter with the increasing complexity of browser-based applications and the rise of API-only architectures.

ASVS 5.0 scope and focus changes from 4.x

Version 5.0 removed requirements that did not align with the intended scope of the standard and excluded requirements that did not meet the scope criteria for 5.0 or were not verifiable.

ASVS 5.0 shift to security goals over mechanisms

In version 5.0, requirements are centered on security goals, referencing particular mechanisms only when they are the sole practical solution, or providing them as examples or supplementary guidance. This approach recognizes that multiple methods may exist to achieve a given security objective and avoids unnecessary prescriptiveness that could limit organizational flexibility. Requirements addressing the same security concern have been consolidated where appropriate.

ASVS 5.0 documented security decisions

Documented security decisions represent an evolution of earlier requirements related to policy application and threat modeling in version 4.0. Previously, some requirements implicitly demanded analysis to inform the implementation of security controls. In version 5.0, these expectations are now explicitly defined as documentation requirements, making them clear, actionable, and verifiable.

ASVS 5.0 new chapters: OAuth, OIDC, and WebRTC

Version 5.0 introduces entirely new chapters for OAuth and OIDC, given the widespread adoption of these protocols for access delegation and single sign-on. WebRTC is also now addressed in a dedicated section as this technology gains popularity and its unique security considerations are relevant.

ASVS 5.0 new chapter: Secure Coding and Architecture

Version 5.0 includes a new chapter for Secure Coding and Architecture that groups new requirements addressing general security practices that did not fit within existing chapters.

ASVS 5.0 input validation reorganization

Input validation requirements were moved alongside business logic in version 5.0, reflecting their role in enforcing business rules, rather than being grouped with sanitization and encoding.

ASVS 5.0 removal of V1 Architecture chapter

The former V1 Architecture chapter has been removed from version 5.0. Its initial section contained requirements that were out of scope, while subsequent sections have been redistributed to relevant chapters, with requirements deduplicated and clarified as necessary.

ASVS 5.0 removal of direct mappings to other standards

Direct mappings to other standards have been removed from the main body of version 5.0. The aim is to prepare a mapping with the OWASP Common Requirement Enumeration (CRE) project, which in turn will link ASVS to a range of OWASP projects and external standards. Direct mappings to CWE and NIST are no longer maintained.

ASVS 5.0 reduced coupling with NIST Digital Identity Guidelines

In version 4.x, certain chapters were closely aligned with NIST's structure and terminology. While these guidelines remain an important reference, strict alignment introduced challenges including less widely recognized terminology, duplication of similar requirements, and incomplete mappings. Version 5.0 moves away from this approach to improve clarity and relevance.

ASVS 5.0 moving away from Common Weakness Enumeration mappings

Version 5.0 discontinues direct CWE mappings due to challenges such as category-only CWEs, difficulties in mapping requirements to a single CWE, and the presence of imprecise mappings in version 4.x.

ASVS 5.0 move away from black-box testability for Level 1

A key factor in selecting controls for Level 1 in version 4.x was their suitability for assessment through black box external penetration testing. However, this approach was not fully aligned with the intent of Level 1 as the minimum set of security controls. Relying on testability as a criterion is both relative and misleading. In version 5.0, the level decisions were made primarily based on risk reduction and also keeping in mind the effort to implement.

ASVS 5.0 level definitions no longer prescriptive

Version 5.0 moves away from prescriptive, risk-based levels that mandate a specific level for certain applications, recognizing this approach has proven to be overly rigid. Organizations are encouraged to achieve the level that they feel like they should be achieving based on their maturity and the message they want to send to their users. Prioritization and implementation of security controls depend on multiple factors, including both risk reduction and the effort required for implementation.

V17.1 TURN Server scope

V17.1 TURN Server requirements apply to systems that operate their own TURN (Traversal Using Relays around NAT) servers. TURN servers assist in relaying media in restrictive network environments but can pose risks if misconfigured.

V17.3 Signaling server scope

V17.3 Signaling requirements apply to systems that operate their own WebRTC signaling servers. Signaling coordinates peer-to-peer communication and must be resilient against attacks that could disrupt session establishment or control.

V17 WebRTC scope and applicability

V17 WebRTC requirements apply to Product Developers, Communication Platforms as a Service (CPaaS) providers, and Service Providers who utilize open-source solutions, use commercial WebRTC products, or develop internally-built WebRTC solutions. These requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors, as CPaaS providers are typically responsible for underlying security concerns.

V17.2 Media server scope

V17.2 Media requirements apply only to systems that host their own WebRTC media servers, such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers. Systems that rely solely on peer-to-peer media communication between web browsers without intermediate media servers are excluded from these requirements.

V16 Security Logging and Error Handling control objective

Security logs record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls like input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs. Logs should not include sensitive personal data unless legally required. Logging must not compromise privacy or system security. Applications must fail securely, avoiding unnecessary disclosure or disruption.

V5 File Handling - Control Objective

Chapter V5 addresses security risks from file handling in applications, including denial of service, unauthorized access, and storage exhaustion.

Secure coding checklist availability process

Verify the availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. This was removed from ASVS 5.0 but remains a recommended process.

Source code security monitoring process

Verify that an ongoing process exists to ensure that the application source code is free from backdoors, malicious code (e.g., salami attacks, logic bombs, time bombs), and undocumented or hidden features (e.g., Easter eggs, insecure debugging tools). Complying with this requires complete access to source code including third-party libraries, and is therefore probably only suitable for applications requiring the very highest levels of security. This was removed from ASVS 5.0 but remains a recommended process.

Security constraints in user stories process

Verify that all user stories and features contain functional security constraints, such as 'As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile'. This was removed from ASVS 5.0 but remains a recommended process.

Password strength meter recommendation

A password strength meter should be provided to help users set a stronger password. This is an in-scope recommendation for ASVS 5.0 that should not be made mandatory but is strongly recommended.

Security.txt file recommendation

Create a publicly available security.txt file at the root or .well-known directory of the application that clearly defines a link or email address for people to contact owners about security issues. This is an in-scope recommendation for ASVS 5.0.

Search engine visibility prevention recommendation

Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, the X-Robots-Tag response header, or a robots html meta tag. This is an in-scope recommendation for ASVS 5.0.

Secure software development lifecycle process

Verify the use of a secure software development lifecycle that addresses security in all stages of development. This was removed from ASVS 5.0 but remains a recommended process. The OWASP SAMM project may be a good source for implementation.

Threat modeling process recommendation

Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing. This was removed from ASVS 5.0 but remains a recommended process.

V4 API and Web Service chapter overview

Chapter V4 covers security considerations that apply specifically to applications that expose APIs for use by web browsers or other consumers, commonly using JSON, XML, or GraphQL. The chapter includes requirements for generic web service security, HTTP message structure validation, GraphQL security, and WebSocket security. Authentication, session management, and input validation concerns from other chapters also apply to APIs and should not be tested in isolation.

ASVS definition and scope

The Application Security Verification Standard (ASVS) defines security requirements for web applications and services. It establishes which requirements are included or excluded with the overarching goal of identifying the security principles that must be achieved.

ASVS scope components: Application, Security, Verification, Standard

The scope of ASVS is defined by its name. Application refers to the software product being developed into which security controls must be integrated. Security means every requirement must have demonstrable impact on security. Verification means requirements must be verifiable with clear fail or pass decisions. Standard means ASVS is a collection of security requirements with requirements limited to defining the security goal to achieve.

ASVS requirement definition

The word requirement in ASVS describes what must be achieved to satisfy it. ASVS contains only requirements (must) and does not contain recommendations (should) as the main condition. Recommendations do not satisfy the definition to be a requirement.

Documentation requirements in ASVS

Documentation requirements mandate that the application developer's approach and configuration to certain controls must be documented, which can then be reviewed for appropriateness and the actual implementation can be compared to the documentation. Documentation requirements are always in the first section of a chapter (although not every chapter has them) and always have a related implementation requirement. The point is that verifying documentation is in place and that the actual implementation are two separate activities.

Three ASVS verification levels: L1, L2, L3

ASVS defines three security verification levels: Level 1 (L1), Level 2 (L2), and Level 3 (L3), with each level increasing in depth and complexity. Each level indicates security requirements required to achieve from that level, with higher level requirements as recommendations. Some requirements apply to a particular level but have more stringent conditions for higher levels.

ASVS Level 1 characteristics

Level 1 contains the minimum requirements to consider when securing an application and represents a critical starting point. It contains around 20% of ASVS requirements. The goal is to have as few requirements as possible to decrease the barrier to entry. Requirements are generally critical or basic, first-layer of defense requirements for preventing common attacks that do not require other vulnerabilities or preconditions to be exploitable.

ASVS Level 2 characteristics

Most applications should strive to achieve Level 2 security. Around 50% of ASVS requirements are L2, meaning an application needs to implement around 70% of ASVS requirements (all L1 and L2 requirements) to comply with L2. Requirements generally relate to either less common attacks or more complicated protections against common attacks.

ASVS Level 3 characteristics

Level 3 should be the goal for applications looking to demonstrate the highest levels of security and provides the final approximately 30% of requirements to comply with. Requirements in this section are generally either defense-in-depth mechanisms or other useful but hard-to-implement controls.

Give your agent this brain