OWASP ASVS - Application Security Verification Standard - Standard 4.0
CWE
Common Weakness Enumeration. Common software security weaknesses, serving as a common language and measuring stick for software security tools.
CSP
Credential Service Provider, provide federated (i.e. verified) identity for users.
DAST
Dynamic Application Security Testing, detects security vulnerabilities in an application's running state.
Memorized Secret
Passwords, PINs, unlock patterns, pick the correct image, and passphrases; "something you know".
PII
Personally Identifiable Information, information about individuals that can be used to identify a person.
PIE
Position-independent Executable, an executable that executes properly no matter its absolute address in memory
PKI
Public Key Infrastructure, a group of technologies that bind public keys to the identity of entities.
SDLC
Software Development Lifecycle
SAST
Static Application Security Testing, detects security vulnerabilities in application by analyzing source code and compiled binaries.
Secure Software Development Lifecycle Requirements: 1.1.7
Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.
Secure Software Development Lifecycle Requirements: 1.1.5
Verify definition and security analysis of the application's high-level architecture and all connected remote services.
Secure Software Development Lifecycle Requirements: 1.1.4
Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.
Access Control Architectural Requirements: 1.4.3
Verify enforcement of the principle of least privilege in functions, data files, URLs, controllers, services, and other resources. This implies protection against spoofing and elevation of privilege.
Credential Recovery Requirements: 2.5.6
Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as TOTP or other soft token, mobile push, or another offline recovery mechanism.
General Authenticator Requirements: 2.2.4
Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.
Secure Software Development Lifecycle Requirements: 1.1.6
Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls.
General Authenticator Requirements: 2.2.7
Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.
Credential Recovery Requirements: 2.5.3
Verify password credential recovery does not reveal the current password in any way.
Credential Recovery Requirements: 2.5.2
Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.
Single or Multi Factor One Time Verifier Requirements: 2.8.6
Verify physical single factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location.
General Authenticator Requirements: 2.2.6
Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes.
Credential Recovery Requirements: 2.5.4
Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
Authenticator Lifecycle Requirements: 2.3.1
Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.
Password Security Requirements: 2.1.11
Verify that "paste" functionality, browser password helpers, and external password managers are permitted.
Password Security Requirements: 2.1.4
Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
Errors, Logging and Auditing Architectural Requirements: 1.7.1
Verify that a common logging format and approach is used across the system.
Password Security Requirements: 2.1.8
Verify that a password strength meter is provided to help users set a stronger password.
Malicious Software Architectural Requirements: 1.10.1
Verify that a source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. The source code control system should have access control and identifiable users to allow traceability of any changes.
Credential Recovery Requirements: 2.5.1
Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.
Authentication Architectural Requirements: 1.2.4
Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.
Business Logic Architectural Requirements: 1.11.3
Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.
Business Logic Architectural Requirements: 1.11.2
Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.
Cryptographic Architectural Requirements: 1.6.3
Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.
Data Protection and Privacy Architectural Requirements: 1.8.2
Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture.
Data Protection and Privacy Architectural Requirements: 1.8.1
Verify that all sensitive data is identified and classified into protection levels.
Secure Software Development Lifecycle Requirements: 1.1.3
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".
Credential Storage Requirements: 2.4.5
Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module).
General Authenticator Requirements: 2.2.1
Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
Communications Architectural Requirements: 1.9.2
Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains.
Configuration Architectural Requirements: 1.14.5
Verify that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization.
Single or Multi Factor One Time Verifier Requirements: 2.8.3
Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
Access Control Architectural Requirements: 1.4.5
Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.
Out of Band Verifier Requirements: 2.7.1
Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.
Authentication Architectural Requirements: 1.2.2
Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.
Cryptographic Architectural Requirements: 1.6.2
Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
Authenticator Lifecycle Requirements: 2.3.2
Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.
Credential Recovery Requirements: 2.5.7
Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.
Credential Storage Requirements: 2.4.3
Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations.
Single or Multi Factor One Time Verifier Requirements: 2.8.5
Verify that if a time-based multi factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.
Credential Recovery Requirements: 2.5.5
Verify that if an authentication factor is changed or replaced, that the user is notified of this event.
Credential Storage Requirements: 2.4.4
Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13.
Configuration Architectural Requirements: 1.14.2
Verify that if deploying binaries to untrusted devices makes use of binary signatures, trusted connections, and verified endpoints.
Input and Output Architectural Requirements: 1.5.1
Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance.
Input and Output Architectural Requirements: 1.5.3
Verify that input validation is enforced on a trusted service layer.
Errors, Logging and Auditing Architectural Requirements: 1.7.2
Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation.
Look-up Secret Verifier Requirements: 2.6.3
Verify that lookup secrets are resistant to offline attacks, such as predictable values.
Look-up Secret Verifier Requirements: 2.6.1
Verify that lookup secrets can be used only once.
Look-up Secret Verifier Requirements: 2.6.2
Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash.
Input and Output Architectural Requirements: 1.5.4
Verify that output encoding occurs close to or by the interpreter for which it is intended.
Password Security Requirements: 2.1.6
Verify that password change functionality requires the user's current and new password.
Password Security Requirements: 2.1.2
Verify that passwords 64 characters or longer are permitted.
Credential Storage Requirements: 2.4.1
Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved oneway key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash.
Password Security Requirements: 2.1.3
Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
Password Security Requirements: 2.1.7
Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password.
Authenticator Lifecycle Requirements: 2.3.3
Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.
General Authenticator Requirements: 2.2.3
Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.
Input and Output Architectural Requirements: 1.5.2
Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.
Single or Multi Factor One Time Verifier Requirements: 2.8.2
Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.
Cryptographic Architectural Requirements: 1.6.4
Verify that symmetric keys, passwords, or API secrets generated by or shared with clients are used only in protecting low risk secrets, such as encrypting local storage, or temporary ephemeral uses such as parameter obfuscation. Sharing secrets with clients is clear-text equivalent and architecturally should be treated as such.
Authentication Architectural Requirements: 1.2.3
Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.
Configuration Architectural Requirements: 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.
Configuration Architectural Requirements: 1.14.3
Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.
Access Control Architectural Requirements: 1.4.2
Verify that the chosen access control solution is flexible enough to meet the application's needs.
Out of Band Verifier Requirements: 2.7.6
Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).
Out of Band Verifier Requirements: 2.7.4
Verify that the out of band authenticator and verifier communicates over a secure independent channel.
Out of Band Verifier Requirements: 2.7.3
Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.
Out of Band Verifier Requirements: 2.7.2
Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.
Out of Band Verifier Requirements: 2.7.5
Verify that the out of band verifier retains only a hashed version of the authentication code.
Credential Storage Requirements: 2.4.2
Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored.
General Authenticator Requirements: 2.2.2
Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.
Password Security Requirements: 2.1.12
Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.
Password Security Requirements: 2.1.9
Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
Password Security Requirements: 2.1.10
Verify that there are no periodic credential rotation or password history requirements.
Cryptographic Architectural Requirements: 1.6.1
Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57.
Single or Multi Factor One Time Verifier Requirements: 2.8.4
Verify that time-based OTP can be used only once within the validity period.
Single or Multi Factor One Time Verifier Requirements: 2.8.1
Verify that time-based OTPs have a defined lifetime before expiring.
Access Control Architectural Requirements: 1.4.1
Verify that trusted enforcement points such as at access control gateways, servers, and serverless functions enforce access controls. Never enforce access controls on the client.
Password Security Requirements: 2.1.1
Verify that user set passwords are at least 12 characters in length.
Secure File Upload Architectural Requirements: 1.12.2
Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable content security policy to reduce the risk from XSS vectors or other attacks from the uploaded file.
Secure File Upload Architectural Requirements: 1.12.1
Verify that user-uploaded files are stored outside of the web root.
General Authenticator Requirements: 2.2.5
Verify that where a credential service provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.
Configuration Architectural Requirements: 1.14.6
Verify the application does not use unsupported, insecure, or deprecated clientside technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.
Communications Architectural Requirements: 1.9.1
Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
Access Control Architectural Requirements: 1.4.4
Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths.
Business Logic Architectural Requirements: 1.11.1
Verify the definition and documentation of all application components in terms of the business or security functions they provide.
Configuration Architectural Requirements: 1.14.1
Verify the segregation of components of differing trust levels through welldefined security controls, firewall rules, API gateways, reverse proxies, cloudbased security groups, or similar mechanisms.
Secure Software Development Lifecycle Requirements: 1.1.1
Verify the use of a secure software development lifecycle that addresses security in all stages of development.
Secure Software Development Lifecycle Requirements: 1.1.2
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.
Authentication Architectural Requirements: 1.2.1
Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.
Password Security Requirements: 2.1.5
Verify users can change their password.
