Summary ASVS

ASVS is a community-driven effort to establish a framework of security requirements and
controls that focus on defining the functional and non-functional security controls required when
designing, developing and testing modern web applications and web services.
ASVS has two main goals:
 to help organizations develop and maintain secure applications.
 to allow security service vendors, security tools vendors, and consumers to align their
requirements and offerings.
3 levels in ASVS:
1. ASVS Level 1 is for low assurance levels, and is completely penetration testable
2. ASVS Level 2 is for applications that contain sensitive data, which requires protection
and is the recommended level for most apps
3. ASVS Level 3 is for the most critical applications - applications that perform high value
transactions, contain sensitive medical data, or any application that requires the highest
level of trust.
14 requirements in ASVS:
1. Architecture, Design and Threat Modeling Requirements
Security architecture is identical, we need authentication today, we will require
authentication tomorrow, and we will need it five years from now. In this chapter, the
ASVS covers off the primary aspects of any sound security architecture: availability,
confidentiality, processing integrity, non-repudiation, and privacy. Each of these security
principles must be built in
and be innate to all applications.
2. Authentication Verification Requirements
Advancements in modern authentication are necessary, so we have to introduce terminology that
will become commonplace in the future. In this case, ASVS covers off password security standards,
general authenticator, credential recovery, MFA mandatory, and cryptographic software
requirements.
3. Session Management Verification Requirements
Ensure that a verified application satisfies the following high-level session management requirements:
• Sessions are unique to each individual and cannot be guessed or shared.
• Sessions are invalidated when no longer required and timed out during periods of inactivity.
these requirements have been adapted to be a compliant subset of selected NIST 800-63b
controls, focused around common threats and commonly exploited authentication weaknesses.
4. Access Control Verification Requirements
Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure
that a verified application satisfies the following high-level requirements:
• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata is protected from replay or tampering.
5. Validation, Sanitization and Encoding Verification Requirements

Ensure that a verified application satisfies the following high-level requirements:
• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
• Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.
• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.
6. Stored Cryptography Verification Requirements

• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed.
7. Error Handling and Logging Verification Requirements
ASVS covers off high quality logs and error handling to provide useful information for the user,
administrators, and incident response teams. High quality logs must include:
• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
8. Data Protection Verification Requirements

Ensure that a verified application satisfies the following high-level data protection requirements:
• Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit
and when stored.
• Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized
attackers.
• Availability: Data should be available to authorized users as required.
9. Communications Verification Requirements

• TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
• The most recent, leading configuration advice is used to enable and order preferred algorithms and
ciphers
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
• Deprecated or known insecure algorithms and ciphers are disabled.
10. Malicious Code Verification Requirements

Ensure that code satisfies the following high level requirements:
• Malicious activity is handled securely and properly to not affect the rest of the application.
• Does not have time bombs or other time-based attacks.
• Does not "phone home" to malicious or unauthorized destinations.
• Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be
controlled by an attacker.
11. Business Logic Verification Requirements

Ensure that a verified application satisfies the following high level requirements:
• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds
transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases and malicious actors, and have protections
against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
12. File and Resources Verification Requirements

Ensure that a verified application satisfies the following high level requirements:
• Untrusted file data should be handled accordingly and in a secure manner.
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited
permissions.
13. API and Web Service Verification Requirements

Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or
GraphQL) has:
• Adequate authentication, session management and authorization of all web services.
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API
14. Configuration Verification Requirements

Ensure that a verified application has:
• A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or
insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default
security
posture.

Summary ASVS

Uploaded by

Copyright:

Available Formats

Summary ASVS

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Summary ASVS

Uploaded by

Copyright:

Available Formats

ASVS is a community-driven effort to establish a framework of security requirements and

5. Validation, Sanitization and Encoding Verification Requirements

6. Stored Cryptography Verification Requirements

8. Data Protection Verification Requirements

9. Communications Verification Requirements

10. Malicious Code Verification Requirements

11. Business Logic Verification Requirements

12. File and Resources Verification Requirements

13. API and Web Service Verification Requirements

14. Configuration Verification Requirements

You might also like