diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml new file mode 100644 index 0000000000..3ba13e0cec --- /dev/null +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -0,0 +1 @@ +blank_issues_enabled: false diff --git a/.github/ISSUE_TEMPLATE/standard-asvs-issue.md b/.github/ISSUE_TEMPLATE/standard-asvs-issue.md new file mode 100644 index 0000000000..0e53eabe5b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/standard-asvs-issue.md @@ -0,0 +1,21 @@ +--- +name: Standard ASVS issue +about: This template should be used for all ASVS issues. +title: '' +labels: '' +assignees: '' + +--- + + diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000000..72e1eb9634 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,8 @@ + + +This Pull Request relates to issue #... diff --git a/4.0/OWASP Application Security Verification Standard 4.0-DE.pdf b/4.0/OWASP Application Security Verification Standard 4.0-DE.pdf new file mode 100644 index 0000000000..e90b71a35b Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0-DE.pdf differ diff --git a/4.0/OWASP Application Security Verification Standard 4.0-en.csv b/4.0/OWASP Application Security Verification Standard 4.0-en.csv deleted file mode 100644 index c6ec9b0c4c..0000000000 --- a/4.0/OWASP Application Security Verification Standard 4.0-en.csv +++ /dev/null @@ -1,287 +0,0 @@ -Section,Name,Item,Description,L1,L2,L3,CWE,NIST -V1,Architecture,1.1.1,Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,, -V1,Architecture,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.",,X,X,1053, -V1,Architecture,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""",,X,X,1110, -V1,Architecture,1.1.4,"Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.",,X,X,1059, -V1,Architecture,1.1.5,Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,1059, -V1,Architecture,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. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,637, -V1,Architecture,1.1.7,"Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.",,X,X,637, -V1,Architecture,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.",,X,X,284, -V1,Architecture,1.11.1,Verify the definition and documentation of all application components in terms of the business or security functions they provide.,,X,X,1059, -V1,Architecture,1.11.2,"Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.",,X,X,362, -V1,Architecture,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.",,,X,367, -V1,Architecture,1.12.1,Verify that user-uploaded files are stored outside of the web root.,,X,X,552, -V1,Architecture,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.",,X,X,646, -V1,Architecture,1.14.1,"Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.",,X,X,923, -V1,Architecture,1.14.2,"Verify that if deploying binaries to untrusted devices makes use of binary signatures, trusted connections, and verified endpoints.",,X,X,494, -V1,Architecture,1.14.3,Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.,,X,X,1104, -V1,Architecture,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.",,X,X,, -V1,Architecture,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. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,265, -V1,Architecture,1.14.6,"Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.",,X,X,477, -V1,Architecture,1.2.1,"Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,250, -V1,Architecture,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. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,306, -V1,Architecture,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.",,X,X,306, -V1,Architecture,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.",,X,X,306, -V1,Architecture,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.",,X,X,602, -V1,Architecture,1.4.2,Verify that the chosen access control solution is flexible enough to meet the application's needs.,,X,X,284, -V1,Architecture,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.",,X,X,272, -V1,Architecture,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. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,284, -V1,Architecture,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. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,275, -V1,Architecture,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.",,X,X,1029, -V1,Architecture,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.",,X,X,502, -V1,Architecture,1.5.3,Verify that input validation is enforced on a trusted service layer. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,602, -V1,Architecture,1.5.4,Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,116, -V1,Architecture,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.,,X,X,320, -V1,Architecture,1.6.2,Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.,,X,X,320, -V1,Architecture,1.6.3,Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.,,X,X,320, -V1,Architecture,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.",,X,X,320, -V1,Architecture,1.7.1,Verify that a common logging format and approach is used across the system. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,1009, -V1,Architecture,1.7.2,"Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,, -V1,Architecture,1.8.1,Verify that all sensitive data is identified and classified into protection levels.,,X,X,, -V1,Architecture,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.",,X,X,, -V1,Architecture,1.9.1,"Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,319, -V1,Architecture,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.",,X,X,295, -V2,Authentication,2.1.1,Verify that user set passwords are at least 12 characters in length. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,521,5.1.1.2 -V2,Authentication,2.1.10,Verify that there are no periodic credential rotation or password history requirements.,X,X,X,263,5.1.1.2 -V2,Authentication,2.1.11,"Verify that ""paste"" functionality, browser password helpers, and external password managers are permitted.",X,X,X,521,5.1.1.2 -V2,Authentication,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.",X,X,X,521,5.1.1.2 -V2,Authentication,2.1.2,Verify that passwords 64 characters or longer are permitted. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,521,5.1.1.2 -V2,Authentication,2.1.3,Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,521,5.1.1.2 -V2,Authentication,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.",X,X,X,521,5.1.1.2 -V2,Authentication,2.1.5,Verify users can change their password.,X,X,X,620,5.1.1.2 -V2,Authentication,2.1.6,Verify that password change functionality requires the user's current and new password.,X,X,X,620,5.1.1.2 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,521,5.1.1.2 -V2,Authentication,2.1.8,Verify that a password strength meter is provided to help users set a stronger password.,X,X,X,521,5.1.1.2 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,521,5.1.1.2 -V2,Authentication,2.10.1,"Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.",,OS assisted,HSM,287,5.1.1.1 -V2,Authentication,2.10.2,"Verify that if passwords are required, the credentials are not a default account.",,OS assisted,HSM,255,5.1.1.1 -V2,Authentication,2.10.3,"Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.",,OS assisted,HSM,522,5.1.1.1 -V2,Authentication,2.10.4,"Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware trusted platform module (TPM), or a hardware security module (L3) is recommended for password storage.",,OS assisted,HSM,798, -V2,Authentication,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.",X,X,X,307,5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2 -V2,Authentication,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.",X,X,X,304,5.2.10 -V2,Authentication,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.",X,X,X,620, -V2,Authentication,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.",,,X,308,5.2.5 -V2,Authentication,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.",,,X,319,5.2.6 -V2,Authentication,2.2.6,"Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes.",,,X,308,5.2.8 -V2,Authentication,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.,,,X,308,5.2.9 -V2,Authentication,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.",X,X,X,330,5.1.1.2 / A.3 -V2,Authentication,2.3.2,"Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.",,X,X,308,6.1.3 -V2,Authentication,2.3.3,Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.,,X,X,287,6.1.4 -V2,Authentication,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 one-way 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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,916,5.1.1.2 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,916,5.1.1.2 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,916,5.1.1.2 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,916,5.1.1.2 -V2,Authentication,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).",,X,X,916,5.1.1.2 -V2,Authentication,2.5.1,Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,640,5.1.1.2 -V2,Authentication,2.5.2,"Verify password hints or knowledge-based authentication (so-called ""secret questions"") are not present.",X,X,X,640,5.1.1.2 -V2,Authentication,2.5.3,Verify password credential recovery does not reveal the current password in any way. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,640,5.1.1.2 -V2,Authentication,2.5.4,"Verify shared or default accounts are not present (e.g. ""root"", ""admin"", or ""sa"").",X,X,X,16,5.1.1.2 / A.3 -V2,Authentication,2.5.5,"Verify that if an authentication factor is changed or replaced, that the user is notified of this event.",X,X,X,304,6.1.2.3 -V2,Authentication,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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,640,5.1.1.2 -V2,Authentication,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.",,X,X,308,6.1.2.3 -V2,Authentication,2.6.1,Verify that lookup secrets can be used only once.,,X,X,308,5.1.2.2 -V2,Authentication,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.",,X,X,330,5.1.2.2 -V2,Authentication,2.6.3,"Verify that lookup secrets are resistant to offline attacks, such as predictable values.",,X,X,310,5.1.2.2 -V2,Authentication,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.",X,X,X,287,5.1.3.2 -V2,Authentication,2.7.2,"Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.",X,X,X,287,5.1.3.2 -V2,Authentication,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.",X,X,X,287,5.1.3.2 -V2,Authentication,2.7.4,Verify that the out of band authenticator and verifier communicates over a secure independent channel.,X,X,X,523,5.1.3.2 -V2,Authentication,2.7.5,Verify that the out of band verifier retains only a hashed version of the authentication code.,,X,X,256,5.1.3.2 -V2,Authentication,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).",,X,X,310,5.1.3.2 -V2,Authentication,2.8.1,Verify that time-based OTPs have a defined lifetime before expiring.,X,X,X,613,5.1.4.2 / 5.1.5.2 -V2,Authentication,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.",,X,X,320,5.1.4.2 / 5.1.5.2 -V2,Authentication,2.8.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",,X,X,326,5.1.4.2 / 5.1.5.2 -V2,Authentication,2.8.4,Verify that time-based OTP can be used only once within the validity period.,,X,X,287,5.1.4.2 / 5.1.5.2 -V2,Authentication,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.",,X,X,287,5.1.5.2 -V2,Authentication,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.",,X,X,613,5.2.1 -V2,Authentication,2.8.7,Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.,,o,X,308,5.2.3 -V2,Authentication,2.9.1,"Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage.",,X,X,320,5.1.7.2 -V2,Authentication,2.9.2,"Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.",,X,X,330,5.1.7.2 -V2,Authentication,2.9.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",,X,X,327,5.1.7.2 -V3,Session,3.1.1,Verify the application never reveals session tokens in URL parameters or error messages.,X,X,X,598, -V3,Session,3.2.1,Verify the application generates a new session token on user authentication. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,384,7.1 -V3,Session,3.2.2,Verify that session tokens possess at least 64 bits of entropy. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,331,7.1 -V3,Session,3.2.3,Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.,X,X,X,539,7.1 -V3,Session,3.2.4,Verify that session token are generated using approved cryptographic algorithms. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,331,7.1 -V3,Session,3.3.1,"Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,613,7.1 -V3,Session,3.3.2,"If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",30 days,"12 hours or 30 minutes of inactivity, 2FA optional","12 hours or 15 minutes of inactivity, with 2FA",613,7.2 -V3,Session,3.3.3,"Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties.",,X,X,613, -V3,Session,3.3.4,Verify that users are able to view and log out of any or all currently active sessions and devices.,,X,X,613,7.1 -V3,Session,3.4.1,Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,614,7.1.1 -V3,Session,3.4.2,Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,1004,7.1.1 -V3,Session,3.4.3,Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,16,7.1.1 -V3,Session,3.4.4,"Verify that cookie-based session tokens use ""__Host-"" prefix (see references) to provide session cookie confidentiality.",X,X,X,16,7.1.1 -V3,Session,3.4.5,"Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,16,7.1.1 -V3,Session,3.5.1,Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to terminate trust relationships with linked applications.,,X,X,290,7.1.2 -V3,Session,3.5.2,"Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.",,X,X,798, -V3,Session,3.5.3,"Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.",,X,X,345, -V3,Session,3.6.1,Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a session within that period.,,,X,613,7.2.1 -V3,Session,3.6.2,"Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.",,,X,613,7.2.1 -V3,Session,3.7.1,Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.,X,X,X,778, -V4,Access,4.1.1,"Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.",X,X,X,602, -V4,Access,4.1.2,Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.,X,X,X,639, -V4,Access,4.1.3,"Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,285, -V4,Access,4.1.4,Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,276, -V4,Access,4.1.5,Verify that access controls fail securely including when an exception occurs. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,285, -V4,Access,4.2.1,"Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.",X,X,X,639, -V4,Access,4.2.2,"Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.",X,X,X,352, -V4,Access,4.3.1,Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.,X,X,X,419, -V4,Access,4.3.2,"Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.",X,X,X,548, -V4,Access,4.3.3,"Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.",,X,X,732, -V5,Validation,5.1.1,"Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).",X,X,X,235, -V5,Validation,5.1.2,"Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,915, -V5,Validation,5.1.3,"Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting). ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,20, -V5,Validation,5.1.4,"Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,20, -V5,Validation,5.1.5,"Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.",X,X,X,601, -V5,Validation,5.2.1,Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,116, -V5,Validation,5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,X,X,X,138, -V5,Validation,5.2.3,Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.,X,X,X,147, -V5,Validation,5.2.4,"Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.",X,X,X,95, -V5,Validation,5.2.5,Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.,X,X,X,94, -V5,Validation,5.2.6,"Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports.",X,X,X,918, -V5,Validation,5.2.7,"Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.",X,X,X,159, -V5,Validation,5.2.8,"Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.",X,X,X,94, -V5,Validation,5.3.1,"Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,116, -V5,Validation,5.3.10,Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,643, -V5,Validation,5.3.2,"Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,176, -V5,Validation,5.3.3,"Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,79, -V5,Validation,5.3.4,"Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,89, -V5,Validation,5.3.5,"Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,89, -V5,Validation,5.3.6,"Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,830, -V5,Validation,5.3.7,"Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,943, -V5,Validation,5.3.8,Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,78, -V5,Validation,5.3.9,Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.,X,X,X,829, -V5,Validation,5.4.1,"Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.",,X,X,120, -V5,Validation,5.4.2,"Verify that format strings do not take potentially hostile input, and are constant.",,X,X,134, -V5,Validation,5.4.3,"Verify that sign, range, and input validation techniques are used to prevent integer overflows.",,X,X,190, -V5,Validation,5.5.1,Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,502, -V5,Validation,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.,X,X,X,611, -V5,Validation,5.5.3,"Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).",X,X,X,502, -V5,Validation,5.5.4,"Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.",X,X,X,95, -V6,Cryptography,6.1.1,"Verify that regulated private data is stored encrypted while at rest, such as personally identifiable information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.",,X,X,311, -V6,Cryptography,6.1.2,"Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.",,X,X,311, -V6,Cryptography,6.1.3,"Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records.",,X,X,311, -V6,Cryptography,6.2.1,"Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.",X,X,X,310, -V6,Cryptography,6.2.2,"Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,327, -V6,Cryptography,6.2.3,"Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.",,X,X,326, -V6,Cryptography,6.2.4,"Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,326, -V6,Cryptography,6.2.5,"Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.",,X,X,326, -V6,Cryptography,6.2.6,"Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.",,X,X,326, -V6,Cryptography,6.2.7,"Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.",,,X,326, -V6,Cryptography,6.2.8,"Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.",,,X,385, -V6,Cryptography,6.3.1,"Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.",,X,X,338, -V6,Cryptography,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.",,X,X,338, -V6,Cryptography,6.3.3,"Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances.",,,X,338, -V6,Cryptography,6.4.1,"Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,798, -V6,Cryptography,6.4.2,Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,320, -V7,Error,7.1.1,"Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,532, -V7,Error,7.1.2,Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,532, -V7,Error,7.1.3,"Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,778, -V7,Error,7.1.4,Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,778, -V7,Error,7.2.1,"Verify that all authentication decisions are logged, without storing sensitive session identifiers or passwords. This should include requests with relevant metadata needed for security investigations.",,X,X,778, -V7,Error,7.2.2,Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations.,,X,X,285, -V7,Error,7.3.1,Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,117, -V7,Error,7.3.2,Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,117, -V7,Error,7.3.3,Verify that security logs are protected from unauthorized access and modification. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,200, -V7,Error,7.3.4,Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,, -V7,Error,7.4.1,"Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,210, -V7,Error,7.4.2,Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,544, -V7,Error,7.4.3,"Verify that a ""last resort"" error handler is defined which will catch all unhandled exceptions. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,460, -V8,Data,8.1.1,Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.,,X,X,524, -V8,Data,8.1.2,Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.,,X,X,524, -V8,Data,8.1.3,"Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.",,X,X,233, -V8,Data,8.1.4,"Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.",,X,X,770, -V8,Data,8.1.5,Verify that regular backups of important data are performed and that test restoration of data is performed.,,,X,19, -V8,Data,8.1.6,Verify that backups are stored securely to prevent data from being stolen or corrupted.,,,X,19, -V8,Data,8.2.1,Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.,X,X,X,525, -V8,Data,8.2.2,"Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.",X,X,X,922, -V8,Data,8.2.3,"Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.",X,X,X,922, -V8,Data,8.3.1,"Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.",X,X,X,319, -V8,Data,8.3.2,Verify that users have a method to remove or export their data on demand.,X,X,X,212, -V8,Data,8.3.3,Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.,X,X,X,285, -V8,Data,8.3.4,"Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,200, -V8,Data,8.3.5,"Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required.",,X,X,532, -V8,Data,8.3.6,"Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.",,X,X,226, -V8,Data,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. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,327, -V8,Data,8.3.8,"Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.",,X,X,285, -V9,Communications,9.1.1,"Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,319, -V9,Communications,9.1.2,"Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.",X,X,X,326, -V9,Communications,9.1.3,"Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.",X,X,X,326, -V9,Communications,9.2.1,"Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.",,X,X,295, -V9,Communications,9.2.2,"Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols.",,X,X,319, -V9,Communications,9.2.3,Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.,,X,X,287, -V9,Communications,9.2.4,"Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.",,X,X,299, -V9,Communications,9.2.5,Verify that backend TLS connection failures are logged.,,,X,544, -V10,Malicious,10.1.1,"Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.",,,X,749, -V10,Malicious,10.2.1,"Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.",,X,X,359, -V10,Malicious,10.2.2,"Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.",,X,X,272, -V10,Malicious,10.2.3,"Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.",,,X,507, -V10,Malicious,10.2.4,Verify that the application source code and third party libraries does not contain time bombs by searching for date and time related functions.,,,X,511, -V10,Malicious,10.2.5,"Verify that the application source code and third party libraries does not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.",,,X,511, -V10,Malicious,10.2.6,Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.,,,X,507, -V10,Malicious,10.3.1,"Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.",X,X,X,16, -V10,Malicious,10.3.2,"Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.",X,X,X,353, -V10,Malicious,10.3.3,"Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.",X,X,X,350, -V11,BusLogic,11.1.1,Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.,X,X,X,841, -V11,BusLogic,11.1.2,"Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.",X,X,X,779, -V11,BusLogic,11.1.3,Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.,X,X,X,770, -V11,BusLogic,11.1.4,"Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.",X,X,X,770, -V11,BusLogic,11.1.5,"Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies.",X,X,X,841, -V11,BusLogic,11.1.6,"Verify the application does not suffer from ""time of check to time of use"" (TOCTOU) issues or other race conditions for sensitive operations.",,X,X,367, -V11,BusLogic,11.1.7,"Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,754, -V11,BusLogic,11.1.8,Verify the application has configurable alerting when automated attacks or unusual activity is detected.,,X,X,390, -V12,Files,12.1.1,Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.,X,X,X,400, -V12,Files,12.1.2,"Verify that compressed files are checked for ""zip bombs"" - small input files that will decompress into huge files thus exhausting file storage limits.",,X,X,409, -V12,Files,12.1.3,"Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.",,X,X,770, -V12,Files,12.2.1,Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.,,X,X,434, -V12,Files,12.3.1,Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal.,X,X,X,22, -V12,Files,12.3.2,"Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).",X,X,X,73, -V12,Files,12.3.3,"Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI), which may also lead to SSRF.",X,X,X,98, -V12,Files,12.3.4,"Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.",X,X,X,641, -V12,Files,12.3.5,"Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.",X,X,X,78, -V12,Files,12.3.6,"Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.",,X,X,829, -V12,Files,12.4.1,"Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.",X,X,X,922, -V12,Files,12.4.2,Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.,X,X,X,509, -V12,Files,12.5.1,"Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.",X,X,X,552, -V12,Files,12.5.2,Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.,X,X,X,434, -V12,Files,12.6.1,Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from.,X,X,X,918, -V13,API,13.1.1,Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.,X,X,X,116, -V13,API,13.1.2,Verify that access to administration and management functions is limited to authorized administrators.,X,X,X,419, -V13,API,13.1.3,"Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.",X,X,X,598, -V13,API,13.1.4,"Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.",,X,X,285, -V13,API,13.1.5,Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).,,X,X,434, -V13,API,13.2.1,"Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.",X,X,X,650, -V13,API,13.2.2,Verify that JSON schema validation is in place and verified before accepting input.,X,X,X,20, -V13,API,13.2.3,"Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern (see [references](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)), CSRF nonces, or ORIGIN request header checks.",X,X,X,352, -V13,API,13.2.4,"Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.",,X,X,779, -V13,API,13.2.5,"Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/JSON.",,X,X,436, -V13,API,13.2.6,Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.,,X,X,345, -V13,API,13.3.1,"Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.",X,X,X,20, -V13,API,13.3.2,Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.,,X,X,345, -V13,API,13.4.1,"Verify that query whitelisting or a combination of depth limiting and amount limiting should be used to prevent GraphQL or data layer expression denial of service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used.",,X,X,770, -V13,API,13.4.2,Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.,,X,X,285, -V14,Config,14.1.1,"Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.",,X,X,, -V14,Config,14.1.2,"Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.",,X,X,120, -V14,Config,14.1.3,Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.,,X,X,16, -V14,Config,14.1.4,"Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.",,X,X,, -V14,Config,14.1.5,Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.,,,X,, -V14,Config,14.2.1,"Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,1026, -V14,Config,14.2.2,"Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.",X,X,X,1002, -V14,Config,14.2.3,"Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.",X,X,X,714, -V14,Config,14.2.4,"Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",,X,X,829, -V14,Config,14.2.5,Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,, -V14,Config,14.2.6,Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),,X,X,265, -V14,Config,14.3.1,"Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.",X,X,X,209, -V14,Config,14.3.2,"Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.",X,X,X,497, -V14,Config,14.3.3,Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.,X,X,X,200, -V14,Config,14.4.1,"Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).",X,X,X,173, -V14,Config,14.4.2,"Verify that all API responses contain Content-Disposition: attachment; filename=""api.json"" (or other appropriate filename for the content type).",X,X,X,116, -V14,Config,14.4.3,"Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.",X,X,X,1021, -V14,Config,14.4.4,Verify that all responses contain X-Content-Type-Options: nosniff.,X,X,X,116, -V14,Config,14.4.5,"Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.",X,X,X,523, -V14,Config,14.4.6,"Verify that a suitable ""Referrer-Policy"" header is included, such as ""no-referrer"" or ""same-origin"".",X,X,X,116, -V14,Config,14.4.7,Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be embedded in a third-party site.,X,X,X,346, -V14,Config,14.5.1,"Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.",X,X,X,749, -V14,Config,14.5.2,"Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.",X,X,X,346, -V14,Config,14.5.3,"Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the ""null"" origin.",X,X,X,346, -V14,Config,14.5.4,"Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.",,X,X,306, \ No newline at end of file diff --git a/4.0/OWASP Application Security Verification Standard 4.0-en.pdf b/4.0/OWASP Application Security Verification Standard 4.0-en.pdf deleted file mode 100644 index e5f8b2dc07..0000000000 Binary files a/4.0/OWASP Application Security Verification Standard 4.0-en.pdf and /dev/null differ diff --git a/4.0/OWASP Application Security Verification Standard 4.0-fa.pdf b/4.0/OWASP Application Security Verification Standard 4.0-fa.pdf new file mode 100644 index 0000000000..bd80436647 Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0-fa.pdf differ diff --git a/4.0/OWASP Application Security Verification Standard 4.0-tr.pdf b/4.0/OWASP Application Security Verification Standard 4.0-tr.pdf new file mode 100644 index 0000000000..ccbad36e8b Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0-tr.pdf differ diff --git a/4.0/OWASP Application Security Verification Standard 4.0.2-en.pdf b/4.0/OWASP Application Security Verification Standard 4.0.2-en.pdf new file mode 100644 index 0000000000..9b55635713 Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0.2-en.pdf differ diff --git a/4.0/OWASP-Application-Security-Verification-Standard-4.0-ja.pdf b/4.0/OWASP-Application-Security-Verification-Standard-4.0-ja.pdf new file mode 100644 index 0000000000..360c6e1337 Binary files /dev/null and b/4.0/OWASP-Application-Security-Verification-Standard-4.0-ja.pdf differ diff --git a/4.0/asvs.py b/4.0/asvs.py index fecffa457c..841d548e6f 100644 --- a/4.0/asvs.py +++ b/4.0/asvs.py @@ -3,8 +3,9 @@ ''' ASVS document parser and converter class. Based upon code written for MASVS By Bernhard Mueller - - Copyright (c) 2017 OWASP Foundation + Significant improvement by Jonny Schnittger @JonnySchnittger + Additional modifications by Josh Grossman @tghosth + Copyright (c) 2020 OWASP Foundation Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal @@ -31,6 +32,7 @@ import json from xml.sax.saxutils import escape import csv +import dicttoxml try: from StringIO import StringIO @@ -39,29 +41,137 @@ class ASVS: - ''' Creates requirements list out of markdown files. ''' - requirements = [] + asvs = {} + asvs['Name'] = "Application Security Verification Standard Project" + asvs['ShortName'] = "ASVS" + asvs['Version'] = "" + asvs['Description'] = "The OWASP Application Security Verification Standard (ASVS) Project " \ + "provides a basis for testing web application technical security controls and also " \ + "provides developers with a list of requirements for secure development." + + asvs_flat = [] + + def __init__(self, language): + + regex = re.compile('Version (([\d.]+){3})') + + for line in open(os.path.join(language, "0x01-Frontispiece.md"), encoding="utf8"): + m = re.search(regex, line) + if m: + self.asvs['Version'] = m.group(1) + break + + regex = re.compile('## About the Standard\n\n(.*)') - def __init__(self): - for file in os.listdir("en"): + with open(os.path.join(language, "0x01-Frontispiece.md"), encoding="utf8") as content: + m = re.search(regex, content.read()) + if m: + self.asvs['Description'] = m.group(1) + + self.asvs['Requirements'] = chapters = [] + + + for file in os.listdir(language): if re.match("0x\d{2}-V", file): - for line in open(os.path.join("en", file)): - regex = re.compile('\\*\\*([\d\.]+)\\*\\*\s\|\s{0,1}(.*?)\s{0,1}\|') + chapter = {}; + chapter['Shortcode'] = "" + chapter['Ordinal'] = "" + chapter['ShortName'] = "" + chapter['Name'] = "" + chapter['Items'] = [] + + section = {} + section['Shortcode'] = "" + section['Ordinal'] = "" + section['Name'] = "" + section['Items'] = [] + + regex = re.compile('0x\d{2}-(V([0-9]{1,3}))-(\w[^-.]*)') + m = re.search(regex, file) + if m: + chapter = {}; + chapter['Shortcode'] = m.group(1) + chapter['Ordinal'] = int(m.group(2)) + chapter['ShortName'] = m.group(3) + chapter['Name'] = "" + chapter['Items'] = [] + + section = {} + section['Shortcode'] = m.group(1) + section['Ordinal'] = int(m.group(2)) + section['Name'] = m.group(3) + section['Items'] = [] + + chapters.append(chapter) + + for line in open(os.path.join("en", file), encoding="utf8"): + regex = re.compile('# (V([0-9]{1,2})): ([\w\s][^\n]*)') m = re.search(regex, line) if m: - req = {} - req['id'] = m.group(1) - req['text'] = m.group(2) - req['file'] = file + chapter['Name'] = m.group(3) - self.requirements.append(req) + + regex = re.compile('## (V[0-9]{1,2}.([0-9]{1,3})) ([\w\s][^\n]*)') + m = re.search(regex, line) + if m: + section = {} + section['Shortcode'] = m.group(1) + section['Ordinal'] = int(m.group(2)) + section['Name'] = m.group(3) + section['Items'] = [] + + chapter['Items'].append(section) + + regex = re.compile("\*\*([\d\.]+)\*\*\s\|\s{0,1}(.*?)\s{0,1}\|([\w\d,\. ✓]*)"\ + "\|([\w\d,\. ✓]*)\|([\w\d,\. ✓]*)\|([0-9,\s]*)\|([A-Z0-9/\s,.]*)\|{0,1}") + m = re.search(regex, line) + if m: + + req_flat = {} + req_flat['chapter_id'] = chapter['Shortcode'] + req_flat['chapter_name'] = chapter['Name'] + req_flat['section_id'] = section['Shortcode'] + req_flat['section_name'] = section['Name'] + + req = {} + req_flat['req_id'] = req['Shortcode'] = "V" + m.group(1) + req['Ordinal'] = int(m.group(1).rsplit('.', 1)[1]) + req_flat['req_description'] = req['Description'] = m.group(2) + + level1 = {} + level2 = {} + level3 = {} + + req_flat['level1'] = m.group(3).strip(' ') + req_flat['level2'] = m.group(4).strip(' ') + req_flat['level3'] = m.group(5).strip(' ') + + level1['Required'] = m.group(3).strip() != '' + level2['Required'] = m.group(4).strip() != '' + level3['Required'] = m.group(5).strip() != '' + + level1['Requirement'] = ("Optional" if m.group(3).strip('✓ ') == "o" else m.group(3).strip('✓ ')) + level2['Requirement'] = ("Optional" if m.group(4).strip('✓ ') == "o" else m.group(4).strip('✓ ')) + level3['Requirement'] = ("Optional" if m.group(5).strip('✓ ') == "o" else m.group(5).strip('✓ ')) + + req['L1'] = level1 + req['L2'] = level2 + req['L3'] = level3 + + req['CWE'] = [int(i.strip()) for i in filter(None, m.group(6).strip().split(','))] + req_flat['cwe'] = m.group(6).strip() + req['NIST'] = [str(i.strip()) for i in filter(None,m.group(7).strip().split('/'))] + req_flat['nist'] = m.group(7).strip() + + section['Items'].append(req) + self.asvs_flat.append(req_flat) def to_json(self): ''' Returns a JSON-formatted string ''' - return json.dumps(self.requirements) + return json.dumps(self.asvs, indent = 2, sort_keys = False).strip() - def to_xml(self): + def to_xmlOLD(self): ''' Returns XML ''' xml = '' @@ -70,13 +180,15 @@ def to_xml(self): xml += "" + escape(r['text']) + "\n" return xml - + def to_xml(self): + return dicttoxml.dicttoxml(self.asvs, attr_type=False).decode('utf-8') + def to_csv(self): ''' Returns CSV ''' si = StringIO() - writer = csv.DictWriter(si, ['id', 'text']) + writer = csv.DictWriter(si, ['chapter_id', 'chapter_name', 'section_id', 'section_name', 'req_id', 'req_description', 'level1', 'level2', 'level3', 'cwe', 'nist']) writer.writeheader() - writer.writerows(self.requirements) + writer.writerows(self.asvs_flat) return si.getvalue() diff --git a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.csv b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.csv new file mode 100644 index 0000000000..f3f4b1598d --- /dev/null +++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.csv @@ -0,0 +1,288 @@ +chapter_id,chapter_name,section_id,section_name,req_id,req_description,level1,level2,level3,cwe,nist +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.1,Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.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.",,✓,✓,1053, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.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""",,✓,✓,1110, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.4,"Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.",,✓,✓,1059, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.5,Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,1059, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.6,"Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,637, +V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.7,"Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.",,✓,✓,637, +V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.1,"Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,250, +V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.2,"Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,306, +V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.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.",,✓,✓,306, +V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.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.",,✓,✓,306, +V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.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.",,✓,✓,602, +V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.2,Verify that the chosen access control solution is flexible enough to meet the application's needs. ,,✓,✓,284, +V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.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.",,✓,✓,272, +V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,284, +V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,275, +V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.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. ",,✓,✓,1029, +V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.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.",,✓,✓,502, +V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.3,Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,602, +V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.4,Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,116, +V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.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.,,✓,✓,320, +V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.2,Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.,,✓,✓,320, +V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.3,Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.,,✓,✓,320, +V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.4,"Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.",,✓,✓,320, +V1,"Architecture, Design and Threat Modeling Requirements",V1.7,"Errors, Logging and Auditing Architectural Requirements",V1.7.1,Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,1009, +V1,"Architecture, Design and Threat Modeling Requirements",V1.7,"Errors, Logging and Auditing Architectural Requirements",V1.7.2,"Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,, +V1,"Architecture, Design and Threat Modeling Requirements",V1.8,Data Protection and Privacy Architectural Requirements,V1.8.1,Verify that all sensitive data is identified and classified into protection levels.,,✓,✓,, +V1,"Architecture, Design and Threat Modeling Requirements",V1.8,Data Protection and Privacy Architectural Requirements,V1.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.",,✓,✓,, +V1,"Architecture, Design and Threat Modeling Requirements",V1.9,Communications Architectural Requirements,V1.9.1,"Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,319, +V1,"Architecture, Design and Threat Modeling Requirements",V1.9,Communications Architectural Requirements,V1.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.",,✓,✓,295, +V1,"Architecture, Design and Threat Modeling Requirements",V1.10,Malicious Software Architectural Requirements,V1.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.",,✓,✓,284, +V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.11.1,Verify the definition and documentation of all application components in terms of the business or security functions they provide.,,✓,✓,1059, +V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.11.2,"Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.",,✓,✓,362, +V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.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.",,,✓,367, +V1,"Architecture, Design and Threat Modeling Requirements",V1.12,Secure File Upload Architectural Requirements,V1.12.1,Verify that user-uploaded files are stored outside of the web root.,,✓,✓,552, +V1,"Architecture, Design and Threat Modeling Requirements",V1.12,Secure File Upload Architectural Requirements,V1.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 (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.",,✓,✓,646, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.1,"Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.",,✓,✓,923, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.2,"Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.",,✓,✓,494, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.3,Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.,,✓,✓,1104, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.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.",,✓,✓,, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.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. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,265, +V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.6,"Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.",,✓,✓,477, +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.1,Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.2,Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.3,"Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.4,"Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.",✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.5,Verify users can change their password.,✓,✓,✓,620,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.6,Verify that password change functionality requires the user's current and new password.,✓,✓,✓,620,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.8,Verify that a password strength meter is provided to help users set a stronger password.,✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.10,Verify that there are no periodic credential rotation or password history requirements.,✓,✓,✓,263,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.11,"Verify that ""paste"" functionality, browser password helpers, and external password managers are permitted.",✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.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 built-in functionality.",✓,✓,✓,521,5.1.1.2 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.",✓,✓,✓,307,5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.",✓,✓,✓,304,5.2.10 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.",✓,✓,✓,620, +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.",,,✓,308,5.2.5 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.",,,✓,319,5.2.6 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.6,"Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.",,,✓,308,5.2.8 +V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.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.,,,✓,308,5.2.9 +V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.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.",✓,✓,✓,330,5.1.1.2 / A.3 +V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.3.2,"Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.",,✓,✓,308,6.1.3 +V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.3.3,Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.,,✓,✓,287,6.1.4 +V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.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 one-way 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 +V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 +V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 +V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 +V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.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).",,✓,✓,916,5.1.1.2 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.1,Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,640,5.1.1.2 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.2,"Verify password hints or knowledge-based authentication (so-called ""secret questions"") are not present.",✓,✓,✓,640,5.1.1.2 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.3,Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,640,5.1.1.2 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.4,"Verify shared or default accounts are not present (e.g. ""root"", ""admin"", or ""sa"").",✓,✓,✓,16,5.1.1.2 / A.3 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.5,"Verify that if an authentication factor is changed or replaced, that the user is notified of this event.",✓,✓,✓,304,6.1.2.3 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.6,"Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,640,5.1.1.2 +V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.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.",,✓,✓,308,6.1.2.3 +V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.6.1,Verify that lookup secrets can be used only once.,,✓,✓,308,5.1.2.2 +V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.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.",,✓,✓,330,5.1.2.2 +V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.6.3,"Verify that lookup secrets are resistant to offline attacks, such as predictable values.",,✓,✓,310,5.1.2.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.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.",✓,✓,✓,287,5.1.3.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.2,"Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.",✓,✓,✓,287,5.1.3.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.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.",✓,✓,✓,287,5.1.3.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.4,Verify that the out of band authenticator and verifier communicates over a secure independent channel.,✓,✓,✓,523,5.1.3.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.5,Verify that the out of band verifier retains only a hashed version of the authentication code.,,✓,✓,256,5.1.3.2 +V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.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).",,✓,✓,310,5.1.3.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.1,Verify that time-based OTPs have a defined lifetime before expiring.,✓,✓,✓,613,5.1.4.2 / 5.1.5.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.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.",,✓,✓,320,5.1.4.2 / 5.1.5.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.",,✓,✓,326,5.1.4.2 / 5.1.5.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.4,Verify that time-based OTP can be used only once within the validity period.,,✓,✓,287,5.1.4.2 / 5.1.5.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.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.",,✓,✓,287,5.1.5.2 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.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.",,✓,✓,613,5.2.1 +V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.7,Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.,,o,✓,308,5.2.3 +V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.1,"Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage.",,✓,✓,320,5.1.7.2 +V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.2,"Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.",,✓,✓,330,5.1.7.2 +V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",,✓,✓,327,5.1.7.2 +V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.1,"Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.",,OS assisted,HSM,287,5.1.1.1 +V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.2,"Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).",,OS assisted,HSM,255,5.1.1.1 +V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.3,"Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.",,OS assisted,HSM,522,5.1.1.1 +V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.4,"Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.",,OS assisted,HSM,798, +V3,Session Management Verification Requirements,V3.1,Fundamental Session Management Requirements,V3.1.1,Verify the application never reveals session tokens in URL parameters. ,✓,✓,✓,598, +V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.1,Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,384,7.1 +V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.2,Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,331,7.1 +V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.3,Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.,✓,✓,✓,539,7.1 +V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.4,Verify that session token are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,331,7.1 +V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.1,"Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,613,7.1 +V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.2,"If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",30 days,"12 hours or 30 minutes of inactivity, 2FA optional","12 hours or 15 minutes of inactivity, with 2FA",613,7.2 +V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.3,"Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.",,✓,✓,613, +V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.4,Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.,,✓,✓,613,7.1 +V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.1,Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,614,7.1.1 +V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.2,Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,1004,7.1.1 +V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.3,Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,16,7.1.1 +V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.4,"Verify that cookie-based session tokens use ""__Host-"" prefix (see references) to provide session cookie confidentiality.",✓,✓,✓,16,7.1.1 +V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.5,"Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,16,7.1.1 +V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.1,Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. ,,✓,✓,290,7.1.2 +V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.2,"Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.",,✓,✓,798, +V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.3,"Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.",,✓,✓,345, +V3,Session Management Verification Requirements,V3.6,Re-authentication from a Federation or Assertion,V3.6.1,Verify that relying parties specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the subscriber if they haven't used a session within that period.,,,✓,613,7.2.1 +V3,Session Management Verification Requirements,V3.6,Re-authentication from a Federation or Assertion,V3.6.2,"Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.",,,✓,613,7.2.1 +V3,Session Management Verification Requirements,V3.7,Defenses Against Session Management Exploits,V3.7.1,"Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.",✓,✓,✓,306, +V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.1,"Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.",✓,✓,✓,602, +V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.2,Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.,✓,✓,✓,639, +V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.3,"Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,285, +V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.4,Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,276, +V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.5,Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,285, +V4,Access Control Verification Requirements,V4.2,Operation Level Access Control,V4.2.1,"Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.",✓,✓,✓,639, +V4,Access Control Verification Requirements,V4.2,Operation Level Access Control,V4.2.2,"Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.",✓,✓,✓,352, +V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.1,Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.,✓,✓,✓,419, +V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.2,"Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.",✓,✓,✓,548, +V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.3,"Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.",,✓,✓,732, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.1,"Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).",✓,✓,✓,235, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.2,"Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,915, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.3,"Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,20, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.4,"Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,20, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.5,"Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.",✓,✓,✓,601, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.1,Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,116, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,✓,✓,✓,138, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.3,Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.,✓,✓,✓,147, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.4,"Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.",✓,✓,✓,95, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.5,Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.,✓,✓,✓,94, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.6,"Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.",✓,✓,✓,918, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.7,"Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.",✓,✓,✓,159, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.8,"Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.",✓,✓,✓,94, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.1,"Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,116, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.2,"Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,176, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.3,"Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,79, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.4,"Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,89, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.5,"Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,89, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.6,"Verify that the application protects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, Content Security Policy (CSP) bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,830, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.7,"Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,90, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.8,Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,78, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.9,Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.,✓,✓,✓,829, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.10,Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,643, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.1,"Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.",,✓,✓,120, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.2,"Verify that format strings do not take potentially hostile input, and are constant.",,✓,✓,134, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.3,"Verify that sign, range, and input validation techniques are used to prevent integer overflows.",,✓,✓,190, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.1,Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,502, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.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 XML eXternal Entity (XXE) attacks. ,✓,✓,✓,611, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.3,"Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). ",✓,✓,✓,502, +V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.4,"Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.",✓,✓,✓,95, +V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.1,"Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.",,✓,✓,311, +V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.2,"Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.",,✓,✓,311, +V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.3,"Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records.",,✓,✓,311, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.1,"Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.",✓,✓,✓,310, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.2,"Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,327, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.3,"Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.",,✓,✓,326, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.4,"Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,326, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.5,"Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.",,✓,✓,326, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.6,"Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.",,✓,✓,326, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.7,"Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.",,,✓,326, +V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.8,"Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.",,,✓,385, +V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.3.1,"Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.",,✓,✓,338, +V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.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.",,✓,✓,338, +V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.3.3,"Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances.",,,✓,338, +V6,Stored Cryptography Verification Requirements,V6.4,Secret Management,V6.4.1,"Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,798, +V6,Stored Cryptography Verification Requirements,V6.4,Secret Management,V6.4.2,Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,320, +V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.1,"Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,532, +V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.2,Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,532, +V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.3,"Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,778, +V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.4,Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,778, +V7,Error Handling and Logging Verification Requirements,V7.2,Log Processing Requirements,V7.2.1,"Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. ",,✓,✓,778, +V7,Error Handling and Logging Verification Requirements,V7.2,Log Processing Requirements,V7.2.2,Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations.,,✓,✓,285, +V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.1,Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,117, +V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.2,Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,117, +V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.3,Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,200, +V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.4,Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, +V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.1,"Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,210, +V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.2,Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,544, +V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.3,"Verify that a ""last resort"" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,431, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.1,Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.,,✓,✓,524, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.2,Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.,,✓,✓,524, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.3,"Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.",,✓,✓,233, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.4,"Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.",,✓,✓,770, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.5,Verify that regular backups of important data are performed and that test restoration of data is performed.,,,✓,19, +V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.6,Verify that backups are stored securely to prevent data from being stolen or corrupted.,,,✓,19, +V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.1,Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.,✓,✓,✓,525, +V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.2,"Verify that data stored in browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII.",✓,✓,✓,922, +V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.3,"Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.",✓,✓,✓,922, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.1,"Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.",✓,✓,✓,319, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.2,Verify that users have a method to remove or export their data on demand.,✓,✓,✓,212, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.3,Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.,✓,✓,✓,285, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.4,"Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,200, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.5,"Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required.",,✓,✓,532, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.6,"Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.",,✓,✓,226, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.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. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,327, +V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.8,"Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.",,✓,✓,285, +V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.1,"Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,319, +V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.2,"Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.",✓,✓,✓,326, +V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.3,"Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.",✓,✓,✓,326, +V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.1,"Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.",,✓,✓,295, +V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.2,"Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols.",,✓,✓,319, +V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.3,Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.,,✓,✓,287, +V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.4,"Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.",,✓,✓,299, +V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.5,Verify that backend TLS connection failures are logged.,,,✓,544, +V10,Malicious Code Verification Requirements,V10.1,Code Integrity Controls,V10.1.1,"Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.",,,✓,749, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.1,"Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.",,✓,✓,359, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.2,"Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.",,✓,✓,272, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.3,"Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.",,,✓,507, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.4,Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.,,,✓,511, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.5,"Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.",,,✓,511, +V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.6,Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.,,,✓,507, +V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.1,"Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.",✓,✓,✓,16, +V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.2,"Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.",✓,✓,✓,353, +V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.3,"Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.",✓,✓,✓,350, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.1,Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.,✓,✓,✓,841, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.2,"Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.",✓,✓,✓,799, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.3,Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.,✓,✓,✓,770, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.4,"Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.",✓,✓,✓,770, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.5,"Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.",✓,✓,✓,841, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.6,"Verify the application does not suffer from ""Time Of Check to Time Of Use"" (TOCTOU) issues or other race conditions for sensitive operations.",,✓,✓,367, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.7,"Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,754, +V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.8,Verify the application has configurable alerting when automated attacks or unusual activity is detected.,,✓,✓,390, +V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.1,Verify that the application will not accept large files that could fill up storage or cause a denial of service.,✓,✓,✓,400, +V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.2,"Verify that compressed files are checked for ""zip bombs"" - small input files that will decompress into huge files thus exhausting file storage limits.",,✓,✓,409, +V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.3,"Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.",,✓,✓,770, +V12,File and Resources Verification Requirements,V12.2,File Integrity Requirements,V12.2.1,Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.,,✓,✓,434, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.1,Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.,✓,✓,✓,22, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.2,"Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).",✓,✓,✓,73, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.3,Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. ,✓,✓,✓,98, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.4,"Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.",✓,✓,✓,641, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.5,"Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.",✓,✓,✓,78, +V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.6,"Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.",,✓,✓,829, +V12,File and Resources Verification Requirements,V12.4,File Storage Requirements,V12.4.1,"Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.",✓,✓,✓,922, +V12,File and Resources Verification Requirements,V12.4,File Storage Requirements,V12.4.2,Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.,✓,✓,✓,509, +V12,File and Resources Verification Requirements,V12.5,File Download Requirements,V12.5.1,"Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.",✓,✓,✓,552, +V12,File and Resources Verification Requirements,V12.5,File Download Requirements,V12.5.2,Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.,✓,✓,✓,434, +V12,File and Resources Verification Requirements,V12.6,SSRF Protection Requirements,V12.6.1,Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.,✓,✓,✓,918, +V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.1,Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.,✓,✓,✓,116, +V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.2,Verify that access to administration and management functions is limited to authorized administrators.,✓,✓,✓,419, +V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.3,"Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.",✓,✓,✓,598, +V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.4,"Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.",,✓,✓,285, +V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.5,Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).,,✓,✓,434, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.1,"Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.",✓,✓,✓,650, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.2,Verify that JSON schema validation is in place and verified before accepting input.,✓,✓,✓,20, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.3,"Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks.",✓,✓,✓,352, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.4,"Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.",,✓,✓,770, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.5,"Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.",,✓,✓,436, +V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.6,Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.,,✓,✓,345, +V13,API and Web Service Verification Requirements,V13.3,SOAP Web Service Verification Requirements,V13.3.1,"Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.",✓,✓,✓,20, +V13,API and Web Service Verification Requirements,V13.3,SOAP Web Service Verification Requirements,V13.3.2,Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.,,✓,✓,345, +V13,API and Web Service Verification Requirements,V13.4,GraphQL and other Web Service Data Layer Security Requirements,V13.4.1,"Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used.",,✓,✓,770, +V13,API and Web Service Verification Requirements,V13.4,GraphQL and other Web Service Data Layer Security Requirements,V13.4.2,Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.,,✓,✓,285, +V14,Configuration Verification Requirements,V14.1,Build,V14.1.1,"Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.",,✓,✓,, +V14,Configuration Verification Requirements,V14.1,Build,V14.1.2,"Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.",,✓,✓,120, +V14,Configuration Verification Requirements,V14.1,Build,V14.1.3,Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.,,✓,✓,16, +V14,Configuration Verification Requirements,V14.1,Build,V14.1.4,"Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.",,✓,✓,, +V14,Configuration Verification Requirements,V14.1,Build,V14.1.5,Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.,,,✓,, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.1,"Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,1026, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.2,"Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.",✓,✓,✓,1002, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.3,"Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.",✓,✓,✓,829, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.4,"Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,829, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.5,Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, +V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.6,Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,265, +V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.1,"Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.",✓,✓,✓,209, +V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.2,"Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.",✓,✓,✓,497, +V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.3,Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.,✓,✓,✓,200, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.1,"Verify that every HTTP response contains a Content-Type header. text/*, */*+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1).",✓,✓,✓,173, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.2,"Verify that all API responses contain a Content-Disposition: attachment; filename=""api.json"" header (or other appropriate filename for the content type).",✓,✓,✓,116, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.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.",✓,✓,✓,1021, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.4,Verify that all responses contain a X-Content-Type-Options: nosniff header.,✓,✓,✓,116, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.5,"Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.",✓,✓,✓,523, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.6,"Verify that a suitable ""Referrer-Policy"" header is included, such as ""no-referrer"" or ""same-origin"".",✓,✓,✓,116, +V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.7,Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.,✓,✓,✓,346, +V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.1,"Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.",✓,✓,✓,749, +V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.2,"Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.",✓,✓,✓,346, +V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.3,"Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the ""null"" origin.",✓,✓,✓,346, +V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.4,"Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.",,✓,✓,306, + diff --git a/4.0/OWASP Application Security Verification Standard 4.0-en.docx b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx similarity index 73% rename from 4.0/OWASP Application Security Verification Standard 4.0-en.docx rename to 4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx index a6b3bb4e90..ae9b718019 100644 Binary files a/4.0/OWASP Application Security Verification Standard 4.0-en.docx and b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx differ diff --git a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.json b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.json new file mode 100644 index 0000000000..2a5c35f039 --- /dev/null +++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.json @@ -0,0 +1,6750 @@ +{ + "Name": "Application Security Verification Standard Project", + "ShortName": "ASVS", + "Version": "4.0.2", + "Description": "The Application Security Verification Standard is a list of application security requirements or tests that can be used by architects, developers, testers, security professionals, tool vendors, and consumers to define, build, test and verify secure applications.", + "Requirements": [ + { + "Shortcode": "V1", + "Ordinal": 1, + "ShortName": "Architecture", + "Name": "Architecture, Design and Threat Modeling Requirements", + "Items": [ + { + "Shortcode": "V1.1", + "Ordinal": 1, + "Name": "Secure Software Development Lifecycle Requirements", + "Items": [ + { + "Shortcode": "V1.1.1", + "Ordinal": 1, + "Description": "Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V1.1.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1053 + ], + "NIST": [] + }, + { + "Shortcode": "V1.1.3", + "Ordinal": 3, + "Description": "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\"", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1110 + ], + "NIST": [] + }, + { + "Shortcode": "V1.1.4", + "Ordinal": 4, + "Description": "Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1059 + ], + "NIST": [] + }, + { + "Shortcode": "V1.1.5", + "Ordinal": 5, + "Description": "Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1059 + ], + "NIST": [] + }, + { + "Shortcode": "V1.1.6", + "Ordinal": 6, + "Description": "Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 637 + ], + "NIST": [] + }, + { + "Shortcode": "V1.1.7", + "Ordinal": 7, + "Description": "Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 637 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.2", + "Ordinal": 2, + "Name": "Authentication Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.2.1", + "Ordinal": 1, + "Description": "Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 250 + ], + "NIST": [] + }, + { + "Shortcode": "V1.2.2", + "Ordinal": 2, + "Description": "Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 306 + ], + "NIST": [] + }, + { + "Shortcode": "V1.2.3", + "Ordinal": 3, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 306 + ], + "NIST": [] + }, + { + "Shortcode": "V1.2.4", + "Ordinal": 4, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 306 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.3", + "Ordinal": 3, + "Name": "Session Management Architectural Requirements", + "Items": [] + }, + { + "Shortcode": "V1.4", + "Ordinal": 4, + "Name": "Access Control Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.4.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 602 + ], + "NIST": [] + }, + { + "Shortcode": "V1.4.2", + "Ordinal": 2, + "Description": "Verify that the chosen access control solution is flexible enough to meet the application's needs. ", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 284 + ], + "NIST": [] + }, + { + "Shortcode": "V1.4.3", + "Ordinal": 3, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 272 + ], + "NIST": [] + }, + { + "Shortcode": "V1.4.4", + "Ordinal": 4, + "Description": "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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 284 + ], + "NIST": [] + }, + { + "Shortcode": "V1.4.5", + "Ordinal": 5, + "Description": "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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 275 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.5", + "Ordinal": 5, + "Name": "Input and Output Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.5.1", + "Ordinal": 1, + "Description": "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. ", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1029 + ], + "NIST": [] + }, + { + "Shortcode": "V1.5.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 502 + ], + "NIST": [] + }, + { + "Shortcode": "V1.5.3", + "Ordinal": 3, + "Description": "Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 602 + ], + "NIST": [] + }, + { + "Shortcode": "V1.5.4", + "Ordinal": 4, + "Description": "Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.6", + "Ordinal": 6, + "Name": "Cryptographic Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.6.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [] + }, + { + "Shortcode": "V1.6.2", + "Ordinal": 2, + "Description": "Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [] + }, + { + "Shortcode": "V1.6.3", + "Ordinal": 3, + "Description": "Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [] + }, + { + "Shortcode": "V1.6.4", + "Ordinal": 4, + "Description": "Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.7", + "Ordinal": 7, + "Name": "Errors, Logging and Auditing Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.7.1", + "Ordinal": 1, + "Description": "Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1009 + ], + "NIST": [] + }, + { + "Shortcode": "V1.7.2", + "Ordinal": 2, + "Description": "Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.8", + "Ordinal": 8, + "Name": "Data Protection and Privacy Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.8.1", + "Ordinal": 1, + "Description": "Verify that all sensitive data is identified and classified into protection levels.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V1.8.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.9", + "Ordinal": 9, + "Name": "Communications Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.9.1", + "Ordinal": 1, + "Description": "Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 319 + ], + "NIST": [] + }, + { + "Shortcode": "V1.9.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 295 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.10", + "Ordinal": 10, + "Name": "Malicious Software Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.10.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 284 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.11", + "Ordinal": 11, + "Name": "Business Logic Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.11.1", + "Ordinal": 1, + "Description": "Verify the definition and documentation of all application components in terms of the business or security functions they provide.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1059 + ], + "NIST": [] + }, + { + "Shortcode": "V1.11.2", + "Ordinal": 2, + "Description": "Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 362 + ], + "NIST": [] + }, + { + "Shortcode": "V1.11.3", + "Ordinal": 3, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 367 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.12", + "Ordinal": 12, + "Name": "Secure File Upload Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.12.1", + "Ordinal": 1, + "Description": "Verify that user-uploaded files are stored outside of the web root.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 552 + ], + "NIST": [] + }, + { + "Shortcode": "V1.12.2", + "Ordinal": 2, + "Description": "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 (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 646 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V1.13", + "Ordinal": 13, + "Name": "API Architectural Requirements", + "Items": [] + }, + { + "Shortcode": "V1.14", + "Ordinal": 14, + "Name": "Configuration Architectural Requirements", + "Items": [ + { + "Shortcode": "V1.14.1", + "Ordinal": 1, + "Description": "Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 923 + ], + "NIST": [] + }, + { + "Shortcode": "V1.14.2", + "Ordinal": 2, + "Description": "Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 494 + ], + "NIST": [] + }, + { + "Shortcode": "V1.14.3", + "Ordinal": 3, + "Description": "Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1104 + ], + "NIST": [] + }, + { + "Shortcode": "V1.14.4", + "Ordinal": 4, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V1.14.5", + "Ordinal": 5, + "Description": "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. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 265 + ], + "NIST": [] + }, + { + "Shortcode": "V1.14.6", + "Ordinal": 6, + "Description": "Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 477 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V2", + "Ordinal": 2, + "ShortName": "Authentication", + "Name": "Authentication Verification Requirements", + "Items": [ + { + "Shortcode": "V2.1", + "Ordinal": 1, + "Name": "Password Security Requirements", + "Items": [ + { + "Shortcode": "V2.1.1", + "Ordinal": 1, + "Description": "Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.2", + "Ordinal": 2, + "Description": "Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.3", + "Ordinal": 3, + "Description": "Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.4", + "Ordinal": 4, + "Description": "Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.5", + "Ordinal": 5, + "Description": "Verify users can change their password.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 620 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.6", + "Ordinal": 6, + "Description": "Verify that password change functionality requires the user's current and new password.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 620 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.7", + "Ordinal": 7, + "Description": "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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.8", + "Ordinal": 8, + "Description": "Verify that a password strength meter is provided to help users set a stronger password.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.9", + "Ordinal": 9, + "Description": "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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.10", + "Ordinal": 10, + "Description": "Verify that there are no periodic credential rotation or password history requirements.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 263 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.11", + "Ordinal": 11, + "Description": "Verify that \"paste\" functionality, browser password helpers, and external password managers are permitted.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.1.12", + "Ordinal": 12, + "Description": "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 built-in functionality.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 521 + ], + "NIST": [ + "5.1.1.2" + ] + } + ] + }, + { + "Shortcode": "V2.2", + "Ordinal": 2, + "Name": "General Authenticator Requirements", + "Items": [ + { + "Shortcode": "V2.2.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 307 + ], + "NIST": [ + "5.2.2", + "5.1.1.2", + "5.1.4.2", + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.2.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 304 + ], + "NIST": [ + "5.2.10" + ] + }, + { + "Shortcode": "V2.2.3", + "Ordinal": 3, + "Description": "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.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 620 + ], + "NIST": [] + }, + { + "Shortcode": "V2.2.4", + "Ordinal": 4, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "5.2.5" + ] + }, + { + "Shortcode": "V2.2.5", + "Ordinal": 5, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 319 + ], + "NIST": [ + "5.2.6" + ] + }, + { + "Shortcode": "V2.2.6", + "Ordinal": 6, + "Description": "Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "5.2.8" + ] + }, + { + "Shortcode": "V2.2.7", + "Ordinal": 7, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "5.2.9" + ] + } + ] + }, + { + "Shortcode": "V2.3", + "Ordinal": 3, + "Name": "Authenticator Lifecycle Requirements", + "Items": [ + { + "Shortcode": "V2.3.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 330 + ], + "NIST": [ + "5.1.1.2", + "A.3" + ] + }, + { + "Shortcode": "V2.3.2", + "Ordinal": 2, + "Description": "Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "6.1.3" + ] + }, + { + "Shortcode": "V2.3.3", + "Ordinal": 3, + "Description": "Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "6.1.4" + ] + } + ] + }, + { + "Shortcode": "V2.4", + "Ordinal": 4, + "Name": "Credential Storage Requirements", + "Items": [ + { + "Shortcode": "V2.4.1", + "Ordinal": 1, + "Description": "Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 916 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.4.2", + "Ordinal": 2, + "Description": "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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 916 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.4.3", + "Ordinal": 3, + "Description": "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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 916 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.4.4", + "Ordinal": 4, + "Description": "Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 916 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.4.5", + "Ordinal": 5, + "Description": "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).", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 916 + ], + "NIST": [ + "5.1.1.2" + ] + } + ] + }, + { + "Shortcode": "V2.5", + "Ordinal": 5, + "Name": "Credential Recovery Requirements", + "Items": [ + { + "Shortcode": "V2.5.1", + "Ordinal": 1, + "Description": "Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 640 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.5.2", + "Ordinal": 2, + "Description": "Verify password hints or knowledge-based authentication (so-called \"secret questions\") are not present.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 640 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.5.3", + "Ordinal": 3, + "Description": "Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 640 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.5.4", + "Ordinal": 4, + "Description": "Verify shared or default accounts are not present (e.g. \"root\", \"admin\", or \"sa\").", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [ + "5.1.1.2", + "A.3" + ] + }, + { + "Shortcode": "V2.5.5", + "Ordinal": 5, + "Description": "Verify that if an authentication factor is changed or replaced, that the user is notified of this event.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 304 + ], + "NIST": [ + "6.1.2.3" + ] + }, + { + "Shortcode": "V2.5.6", + "Ordinal": 6, + "Description": "Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 640 + ], + "NIST": [ + "5.1.1.2" + ] + }, + { + "Shortcode": "V2.5.7", + "Ordinal": 7, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "6.1.2.3" + ] + } + ] + }, + { + "Shortcode": "V2.6", + "Ordinal": 6, + "Name": "Look-up Secret Verifier Requirements", + "Items": [ + { + "Shortcode": "V2.6.1", + "Ordinal": 1, + "Description": "Verify that lookup secrets can be used only once.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "5.1.2.2" + ] + }, + { + "Shortcode": "V2.6.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 330 + ], + "NIST": [ + "5.1.2.2" + ] + }, + { + "Shortcode": "V2.6.3", + "Ordinal": 3, + "Description": "Verify that lookup secrets are resistant to offline attacks, such as predictable values.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 310 + ], + "NIST": [ + "5.1.2.2" + ] + } + ] + }, + { + "Shortcode": "V2.7", + "Ordinal": 7, + "Name": "Out of Band Verifier Requirements", + "Items": [ + { + "Shortcode": "V2.7.1", + "Ordinal": 1, + "Description": "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.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.3.2" + ] + }, + { + "Shortcode": "V2.7.2", + "Ordinal": 2, + "Description": "Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.3.2" + ] + }, + { + "Shortcode": "V2.7.3", + "Ordinal": 3, + "Description": "Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.3.2" + ] + }, + { + "Shortcode": "V2.7.4", + "Ordinal": 4, + "Description": "Verify that the out of band authenticator and verifier communicates over a secure independent channel.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 523 + ], + "NIST": [ + "5.1.3.2" + ] + }, + { + "Shortcode": "V2.7.5", + "Ordinal": 5, + "Description": "Verify that the out of band verifier retains only a hashed version of the authentication code.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 256 + ], + "NIST": [ + "5.1.3.2" + ] + }, + { + "Shortcode": "V2.7.6", + "Ordinal": 6, + "Description": "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).", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 310 + ], + "NIST": [ + "5.1.3.2" + ] + } + ] + }, + { + "Shortcode": "V2.8", + "Ordinal": 8, + "Name": "Single or Multi-factor One Time Verifier Requirements", + "Items": [ + { + "Shortcode": "V2.8.1", + "Ordinal": 1, + "Description": "Verify that time-based OTPs have a defined lifetime before expiring.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "5.1.4.2", + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.8.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [ + "5.1.4.2", + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.8.3", + "Ordinal": 3, + "Description": "Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [ + "5.1.4.2", + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.8.4", + "Ordinal": 4, + "Description": "Verify that time-based OTP can be used only once within the validity period.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.4.2", + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.8.5", + "Ordinal": 5, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.5.2" + ] + }, + { + "Shortcode": "V2.8.6", + "Ordinal": 6, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "5.2.1" + ] + }, + { + "Shortcode": "V2.8.7", + "Ordinal": 7, + "Description": "Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "Optional" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 308 + ], + "NIST": [ + "5.2.3" + ] + } + ] + }, + { + "Shortcode": "V2.9", + "Ordinal": 9, + "Name": "Cryptographic Software and Devices Verifier Requirements", + "Items": [ + { + "Shortcode": "V2.9.1", + "Ordinal": 1, + "Description": "Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [ + "5.1.7.2" + ] + }, + { + "Shortcode": "V2.9.2", + "Ordinal": 2, + "Description": "Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 330 + ], + "NIST": [ + "5.1.7.2" + ] + }, + { + "Shortcode": "V2.9.3", + "Ordinal": 3, + "Description": "Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 327 + ], + "NIST": [ + "5.1.7.2" + ] + } + ] + }, + { + "Shortcode": "V2.10", + "Ordinal": 10, + "Name": "Service Authentication Requirements", + "Items": [ + { + "Shortcode": "V2.10.1", + "Ordinal": 1, + "Description": "Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "OS assisted" + }, + "L3": { + "Required": true, + "Requirement": "HSM" + }, + "CWE": [ + 287 + ], + "NIST": [ + "5.1.1.1" + ] + }, + { + "Shortcode": "V2.10.2", + "Ordinal": 2, + "Description": "Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "OS assisted" + }, + "L3": { + "Required": true, + "Requirement": "HSM" + }, + "CWE": [ + 255 + ], + "NIST": [ + "5.1.1.1" + ] + }, + { + "Shortcode": "V2.10.3", + "Ordinal": 3, + "Description": "Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "OS assisted" + }, + "L3": { + "Required": true, + "Requirement": "HSM" + }, + "CWE": [ + 522 + ], + "NIST": [ + "5.1.1.1" + ] + }, + { + "Shortcode": "V2.10.4", + "Ordinal": 4, + "Description": "Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "OS assisted" + }, + "L3": { + "Required": true, + "Requirement": "HSM" + }, + "CWE": [ + 798 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V3", + "Ordinal": 3, + "ShortName": "Session", + "Name": "Session Management Verification Requirements", + "Items": [ + { + "Shortcode": "V3.1", + "Ordinal": 1, + "Name": "Fundamental Session Management Requirements", + "Items": [ + { + "Shortcode": "V3.1.1", + "Ordinal": 1, + "Description": "Verify the application never reveals session tokens in URL parameters. ", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 598 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V3.2", + "Ordinal": 2, + "Name": "Session Binding Requirements", + "Items": [ + { + "Shortcode": "V3.2.1", + "Ordinal": 1, + "Description": "Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 384 + ], + "NIST": [ + "7.1" + ] + }, + { + "Shortcode": "V3.2.2", + "Ordinal": 2, + "Description": "Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 331 + ], + "NIST": [ + "7.1" + ] + }, + { + "Shortcode": "V3.2.3", + "Ordinal": 3, + "Description": "Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 539 + ], + "NIST": [ + "7.1" + ] + }, + { + "Shortcode": "V3.2.4", + "Ordinal": 4, + "Description": "Verify that session token are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 331 + ], + "NIST": [ + "7.1" + ] + } + ] + }, + { + "Shortcode": "V3.3", + "Ordinal": 3, + "Name": "Session Logout and Timeout Requirements", + "Items": [ + { + "Shortcode": "V3.3.1", + "Ordinal": 1, + "Description": "Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "7.1" + ] + }, + { + "Shortcode": "V3.3.2", + "Ordinal": 2, + "Description": "If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "30 days" + }, + "L2": { + "Required": true, + "Requirement": "12 hours or 30 minutes of inactivity, 2FA optional" + }, + "L3": { + "Required": true, + "Requirement": "12 hours or 15 minutes of inactivity, with 2FA" + }, + "CWE": [ + 613 + ], + "NIST": [ + "7.2" + ] + }, + { + "Shortcode": "V3.3.3", + "Ordinal": 3, + "Description": "Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [] + }, + { + "Shortcode": "V3.3.4", + "Ordinal": 4, + "Description": "Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "7.1" + ] + } + ] + }, + { + "Shortcode": "V3.4", + "Ordinal": 4, + "Name": "Cookie-based Session Management", + "Items": [ + { + "Shortcode": "V3.4.1", + "Ordinal": 1, + "Description": "Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 614 + ], + "NIST": [ + "7.1.1" + ] + }, + { + "Shortcode": "V3.4.2", + "Ordinal": 2, + "Description": "Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1004 + ], + "NIST": [ + "7.1.1" + ] + }, + { + "Shortcode": "V3.4.3", + "Ordinal": 3, + "Description": "Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [ + "7.1.1" + ] + }, + { + "Shortcode": "V3.4.4", + "Ordinal": 4, + "Description": "Verify that cookie-based session tokens use \"__Host-\" prefix (see references) to provide session cookie confidentiality.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [ + "7.1.1" + ] + }, + { + "Shortcode": "V3.4.5", + "Ordinal": 5, + "Description": "Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [ + "7.1.1" + ] + } + ] + }, + { + "Shortcode": "V3.5", + "Ordinal": 5, + "Name": "Token-based Session Management", + "Items": [ + { + "Shortcode": "V3.5.1", + "Ordinal": 1, + "Description": "Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. ", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 290 + ], + "NIST": [ + "7.1.2" + ] + }, + { + "Shortcode": "V3.5.2", + "Ordinal": 2, + "Description": "Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 798 + ], + "NIST": [] + }, + { + "Shortcode": "V3.5.3", + "Ordinal": 3, + "Description": "Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 345 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V3.6", + "Ordinal": 6, + "Name": "Re-authentication from a Federation or Assertion", + "Items": [ + { + "Shortcode": "V3.6.1", + "Ordinal": 1, + "Description": "Verify that relying parties specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the subscriber if they haven't used a session within that period.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "7.2.1" + ] + }, + { + "Shortcode": "V3.6.2", + "Ordinal": 2, + "Description": "Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 613 + ], + "NIST": [ + "7.2.1" + ] + } + ] + }, + { + "Shortcode": "V3.7", + "Ordinal": 7, + "Name": "Defenses Against Session Management Exploits", + "Items": [ + { + "Shortcode": "V3.7.1", + "Ordinal": 1, + "Description": "Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 306 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V4", + "Ordinal": 4, + "ShortName": "Access", + "Name": "Access Control Verification Requirements", + "Items": [ + { + "Shortcode": "V4.1", + "Ordinal": 1, + "Name": "General Access Control Design", + "Items": [ + { + "Shortcode": "V4.1.1", + "Ordinal": 1, + "Description": "Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 602 + ], + "NIST": [] + }, + { + "Shortcode": "V4.1.2", + "Ordinal": 2, + "Description": "Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 639 + ], + "NIST": [] + }, + { + "Shortcode": "V4.1.3", + "Ordinal": 3, + "Description": "Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + }, + { + "Shortcode": "V4.1.4", + "Ordinal": 4, + "Description": "Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 276 + ], + "NIST": [] + }, + { + "Shortcode": "V4.1.5", + "Ordinal": 5, + "Description": "Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V4.2", + "Ordinal": 2, + "Name": "Operation Level Access Control", + "Items": [ + { + "Shortcode": "V4.2.1", + "Ordinal": 1, + "Description": "Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 639 + ], + "NIST": [] + }, + { + "Shortcode": "V4.2.2", + "Ordinal": 2, + "Description": "Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 352 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V4.3", + "Ordinal": 3, + "Name": "Other Access Control Considerations", + "Items": [ + { + "Shortcode": "V4.3.1", + "Ordinal": 1, + "Description": "Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 419 + ], + "NIST": [] + }, + { + "Shortcode": "V4.3.2", + "Ordinal": 2, + "Description": "Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 548 + ], + "NIST": [] + }, + { + "Shortcode": "V4.3.3", + "Ordinal": 3, + "Description": "Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 732 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V5", + "Ordinal": 5, + "ShortName": "Validation", + "Name": "Validation, Sanitization and Encoding Verification Requirements", + "Items": [ + { + "Shortcode": "V5.1", + "Ordinal": 1, + "Name": "Input Validation Requirements", + "Items": [ + { + "Shortcode": "V5.1.1", + "Ordinal": 1, + "Description": "Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 235 + ], + "NIST": [] + }, + { + "Shortcode": "V5.1.2", + "Ordinal": 2, + "Description": "Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 915 + ], + "NIST": [] + }, + { + "Shortcode": "V5.1.3", + "Ordinal": 3, + "Description": "Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 20 + ], + "NIST": [] + }, + { + "Shortcode": "V5.1.4", + "Ordinal": 4, + "Description": "Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 20 + ], + "NIST": [] + }, + { + "Shortcode": "V5.1.5", + "Ordinal": 5, + "Description": "Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 601 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V5.2", + "Ordinal": 2, + "Name": "Sanitization and Sandboxing Requirements", + "Items": [ + { + "Shortcode": "V5.2.1", + "Ordinal": 1, + "Description": "Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.2", + "Ordinal": 2, + "Description": "Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 138 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.3", + "Ordinal": 3, + "Description": "Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 147 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.4", + "Ordinal": 4, + "Description": "Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 95 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.5", + "Ordinal": 5, + "Description": "Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 94 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.6", + "Ordinal": 6, + "Description": "Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 918 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.7", + "Ordinal": 7, + "Description": "Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 159 + ], + "NIST": [] + }, + { + "Shortcode": "V5.2.8", + "Ordinal": 8, + "Description": "Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 94 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V5.3", + "Ordinal": 3, + "Name": "Output Encoding and Injection Prevention Requirements", + "Items": [ + { + "Shortcode": "V5.3.1", + "Ordinal": 1, + "Description": "Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as \u306d\u3053 or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.2", + "Ordinal": 2, + "Description": "Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 176 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.3", + "Ordinal": 3, + "Description": "Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 79 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.4", + "Ordinal": 4, + "Description": "Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 89 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.5", + "Ordinal": 5, + "Description": "Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 89 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.6", + "Ordinal": 6, + "Description": "Verify that the application protects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, Content Security Policy (CSP) bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 830 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.7", + "Ordinal": 7, + "Description": "Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 90 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.8", + "Ordinal": 8, + "Description": "Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 78 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.9", + "Ordinal": 9, + "Description": "Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 829 + ], + "NIST": [] + }, + { + "Shortcode": "V5.3.10", + "Ordinal": 10, + "Description": "Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 643 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V5.4", + "Ordinal": 4, + "Name": "Memory, String, and Unmanaged Code Requirements", + "Items": [ + { + "Shortcode": "V5.4.1", + "Ordinal": 1, + "Description": "Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 120 + ], + "NIST": [] + }, + { + "Shortcode": "V5.4.2", + "Ordinal": 2, + "Description": "Verify that format strings do not take potentially hostile input, and are constant.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 134 + ], + "NIST": [] + }, + { + "Shortcode": "V5.4.3", + "Ordinal": 3, + "Description": "Verify that sign, range, and input validation techniques are used to prevent integer overflows.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 190 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V5.5", + "Ordinal": 5, + "Name": "Deserialization Prevention Requirements", + "Items": [ + { + "Shortcode": "V5.5.1", + "Ordinal": 1, + "Description": "Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 502 + ], + "NIST": [] + }, + { + "Shortcode": "V5.5.2", + "Ordinal": 2, + "Description": "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 XML eXternal Entity (XXE) attacks. ", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 611 + ], + "NIST": [] + }, + { + "Shortcode": "V5.5.3", + "Ordinal": 3, + "Description": "Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). ", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 502 + ], + "NIST": [] + }, + { + "Shortcode": "V5.5.4", + "Ordinal": 4, + "Description": "Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 95 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V6", + "Ordinal": 6, + "ShortName": "Cryptography", + "Name": "Stored Cryptography Verification Requirements", + "Items": [ + { + "Shortcode": "V6.1", + "Ordinal": 1, + "Name": "Data Classification", + "Items": [ + { + "Shortcode": "V6.1.1", + "Ordinal": 1, + "Description": "Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 311 + ], + "NIST": [] + }, + { + "Shortcode": "V6.1.2", + "Ordinal": 2, + "Description": "Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 311 + ], + "NIST": [] + }, + { + "Shortcode": "V6.1.3", + "Ordinal": 3, + "Description": "Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 311 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V6.2", + "Ordinal": 2, + "Name": "Algorithms", + "Items": [ + { + "Shortcode": "V6.2.1", + "Ordinal": 1, + "Description": "Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 310 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.2", + "Ordinal": 2, + "Description": "Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 327 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.3", + "Ordinal": 3, + "Description": "Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.4", + "Ordinal": 4, + "Description": "Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.5", + "Ordinal": 5, + "Description": "Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.6", + "Ordinal": 6, + "Description": "Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.7", + "Ordinal": 7, + "Description": "Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V6.2.8", + "Ordinal": 8, + "Description": "Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 385 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V6.3", + "Ordinal": 3, + "Name": "Random Values", + "Items": [ + { + "Shortcode": "V6.3.1", + "Ordinal": 1, + "Description": "Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 338 + ], + "NIST": [] + }, + { + "Shortcode": "V6.3.2", + "Ordinal": 2, + "Description": "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.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 338 + ], + "NIST": [] + }, + { + "Shortcode": "V6.3.3", + "Ordinal": 3, + "Description": "Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 338 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V6.4", + "Ordinal": 4, + "Name": "Secret Management", + "Items": [ + { + "Shortcode": "V6.4.1", + "Ordinal": 1, + "Description": "Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 798 + ], + "NIST": [] + }, + { + "Shortcode": "V6.4.2", + "Ordinal": 2, + "Description": "Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 320 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V7", + "Ordinal": 7, + "ShortName": "Error", + "Name": "Error Handling and Logging Verification Requirements", + "Items": [ + { + "Shortcode": "V7.1", + "Ordinal": 1, + "Name": "Log Content Requirements", + "Items": [ + { + "Shortcode": "V7.1.1", + "Ordinal": 1, + "Description": "Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 532 + ], + "NIST": [] + }, + { + "Shortcode": "V7.1.2", + "Ordinal": 2, + "Description": "Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 532 + ], + "NIST": [] + }, + { + "Shortcode": "V7.1.3", + "Ordinal": 3, + "Description": "Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 778 + ], + "NIST": [] + }, + { + "Shortcode": "V7.1.4", + "Ordinal": 4, + "Description": "Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 778 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V7.2", + "Ordinal": 2, + "Name": "Log Processing Requirements", + "Items": [ + { + "Shortcode": "V7.2.1", + "Ordinal": 1, + "Description": "Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. ", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 778 + ], + "NIST": [] + }, + { + "Shortcode": "V7.2.2", + "Ordinal": 2, + "Description": "Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V7.3", + "Ordinal": 3, + "Name": "Log Protection Requirements", + "Items": [ + { + "Shortcode": "V7.3.1", + "Ordinal": 1, + "Description": "Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 117 + ], + "NIST": [] + }, + { + "Shortcode": "V7.3.2", + "Ordinal": 2, + "Description": "Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 117 + ], + "NIST": [] + }, + { + "Shortcode": "V7.3.3", + "Ordinal": 3, + "Description": "Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 200 + ], + "NIST": [] + }, + { + "Shortcode": "V7.3.4", + "Ordinal": 4, + "Description": "Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + } + ] + }, + { + "Shortcode": "V7.4", + "Ordinal": 4, + "Name": "Error Handling", + "Items": [ + { + "Shortcode": "V7.4.1", + "Ordinal": 1, + "Description": "Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 210 + ], + "NIST": [] + }, + { + "Shortcode": "V7.4.2", + "Ordinal": 2, + "Description": "Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 544 + ], + "NIST": [] + }, + { + "Shortcode": "V7.4.3", + "Ordinal": 3, + "Description": "Verify that a \"last resort\" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 431 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V8", + "Ordinal": 8, + "ShortName": "Data", + "Name": "Data Protection Verification Requirements", + "Items": [ + { + "Shortcode": "V8.1", + "Ordinal": 1, + "Name": "General Data Protection", + "Items": [ + { + "Shortcode": "V8.1.1", + "Ordinal": 1, + "Description": "Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 524 + ], + "NIST": [] + }, + { + "Shortcode": "V8.1.2", + "Ordinal": 2, + "Description": "Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 524 + ], + "NIST": [] + }, + { + "Shortcode": "V8.1.3", + "Ordinal": 3, + "Description": "Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 233 + ], + "NIST": [] + }, + { + "Shortcode": "V8.1.4", + "Ordinal": 4, + "Description": "Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + }, + { + "Shortcode": "V8.1.5", + "Ordinal": 5, + "Description": "Verify that regular backups of important data are performed and that test restoration of data is performed.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 19 + ], + "NIST": [] + }, + { + "Shortcode": "V8.1.6", + "Ordinal": 6, + "Description": "Verify that backups are stored securely to prevent data from being stolen or corrupted.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 19 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V8.2", + "Ordinal": 2, + "Name": "Client-side Data Protection", + "Items": [ + { + "Shortcode": "V8.2.1", + "Ordinal": 1, + "Description": "Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 525 + ], + "NIST": [] + }, + { + "Shortcode": "V8.2.2", + "Ordinal": 2, + "Description": "Verify that data stored in browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 922 + ], + "NIST": [] + }, + { + "Shortcode": "V8.2.3", + "Ordinal": 3, + "Description": "Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 922 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V8.3", + "Ordinal": 3, + "Name": "Sensitive Private Data", + "Items": [ + { + "Shortcode": "V8.3.1", + "Ordinal": 1, + "Description": "Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 319 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.2", + "Ordinal": 2, + "Description": "Verify that users have a method to remove or export their data on demand.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 212 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.3", + "Ordinal": 3, + "Description": "Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.4", + "Ordinal": 4, + "Description": "Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 200 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.5", + "Ordinal": 5, + "Description": "Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 532 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.6", + "Ordinal": 6, + "Description": "Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 226 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.7", + "Ordinal": 7, + "Description": "Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 327 + ], + "NIST": [] + }, + { + "Shortcode": "V8.3.8", + "Ordinal": 8, + "Description": "Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V9", + "Ordinal": 9, + "ShortName": "Communications", + "Name": "Communications Verification Requirements", + "Items": [ + { + "Shortcode": "V9.1", + "Ordinal": 1, + "Name": "Client Communications Security Requirements", + "Items": [ + { + "Shortcode": "V9.1.1", + "Ordinal": 1, + "Description": "Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 319 + ], + "NIST": [] + }, + { + "Shortcode": "V9.1.2", + "Ordinal": 2, + "Description": "Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + }, + { + "Shortcode": "V9.1.3", + "Ordinal": 3, + "Description": "Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 326 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V9.2", + "Ordinal": 2, + "Name": "Server Communications Security Requirements", + "Items": [ + { + "Shortcode": "V9.2.1", + "Ordinal": 1, + "Description": "Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 295 + ], + "NIST": [] + }, + { + "Shortcode": "V9.2.2", + "Ordinal": 2, + "Description": "Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 319 + ], + "NIST": [] + }, + { + "Shortcode": "V9.2.3", + "Ordinal": 3, + "Description": "Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 287 + ], + "NIST": [] + }, + { + "Shortcode": "V9.2.4", + "Ordinal": 4, + "Description": "Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 299 + ], + "NIST": [] + }, + { + "Shortcode": "V9.2.5", + "Ordinal": 5, + "Description": "Verify that backend TLS connection failures are logged.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 544 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V10", + "Ordinal": 10, + "ShortName": "Malicious", + "Name": "Malicious Code Verification Requirements", + "Items": [ + { + "Shortcode": "V10.1", + "Ordinal": 1, + "Name": "Code Integrity Controls", + "Items": [ + { + "Shortcode": "V10.1.1", + "Ordinal": 1, + "Description": "Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 749 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V10.2", + "Ordinal": 2, + "Name": "Malicious Code Search", + "Items": [ + { + "Shortcode": "V10.2.1", + "Ordinal": 1, + "Description": "Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 359 + ], + "NIST": [] + }, + { + "Shortcode": "V10.2.2", + "Ordinal": 2, + "Description": "Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 272 + ], + "NIST": [] + }, + { + "Shortcode": "V10.2.3", + "Ordinal": 3, + "Description": "Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 507 + ], + "NIST": [] + }, + { + "Shortcode": "V10.2.4", + "Ordinal": 4, + "Description": "Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 511 + ], + "NIST": [] + }, + { + "Shortcode": "V10.2.5", + "Ordinal": 5, + "Description": "Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 511 + ], + "NIST": [] + }, + { + "Shortcode": "V10.2.6", + "Ordinal": 6, + "Description": "Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 507 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V10.3", + "Ordinal": 3, + "Name": "Deployed Application Integrity Controls", + "Items": [ + { + "Shortcode": "V10.3.1", + "Ordinal": 1, + "Description": "Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [] + }, + { + "Shortcode": "V10.3.2", + "Ordinal": 2, + "Description": "Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 353 + ], + "NIST": [] + }, + { + "Shortcode": "V10.3.3", + "Ordinal": 3, + "Description": "Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 350 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V11", + "Ordinal": 11, + "ShortName": "BusLogic", + "Name": "Business Logic Verification Requirements", + "Items": [ + { + "Shortcode": "V11.1", + "Ordinal": 1, + "Name": "Business Logic Security Requirements", + "Items": [ + { + "Shortcode": "V11.1.1", + "Ordinal": 1, + "Description": "Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 841 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.2", + "Ordinal": 2, + "Description": "Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 799 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.3", + "Ordinal": 3, + "Description": "Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.4", + "Ordinal": 4, + "Description": "Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.5", + "Ordinal": 5, + "Description": "Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 841 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.6", + "Ordinal": 6, + "Description": "Verify the application does not suffer from \"Time Of Check to Time Of Use\" (TOCTOU) issues or other race conditions for sensitive operations.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 367 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.7", + "Ordinal": 7, + "Description": "Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 754 + ], + "NIST": [] + }, + { + "Shortcode": "V11.1.8", + "Ordinal": 8, + "Description": "Verify the application has configurable alerting when automated attacks or unusual activity is detected.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 390 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V12", + "Ordinal": 12, + "ShortName": "Files", + "Name": "File and Resources Verification Requirements", + "Items": [ + { + "Shortcode": "V12.1", + "Ordinal": 1, + "Name": "File Upload Requirements", + "Items": [ + { + "Shortcode": "V12.1.1", + "Ordinal": 1, + "Description": "Verify that the application will not accept large files that could fill up storage or cause a denial of service.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 400 + ], + "NIST": [] + }, + { + "Shortcode": "V12.1.2", + "Ordinal": 2, + "Description": "Verify that compressed files are checked for \"zip bombs\" - small input files that will decompress into huge files thus exhausting file storage limits.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 409 + ], + "NIST": [] + }, + { + "Shortcode": "V12.1.3", + "Ordinal": 3, + "Description": "Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V12.2", + "Ordinal": 2, + "Name": "File Integrity Requirements", + "Items": [ + { + "Shortcode": "V12.2.1", + "Ordinal": 1, + "Description": "Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 434 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V12.3", + "Ordinal": 3, + "Name": "File Execution Requirements", + "Items": [ + { + "Shortcode": "V12.3.1", + "Ordinal": 1, + "Description": "Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 22 + ], + "NIST": [] + }, + { + "Shortcode": "V12.3.2", + "Ordinal": 2, + "Description": "Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 73 + ], + "NIST": [] + }, + { + "Shortcode": "V12.3.3", + "Ordinal": 3, + "Description": "Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. ", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 98 + ], + "NIST": [] + }, + { + "Shortcode": "V12.3.4", + "Ordinal": 4, + "Description": "Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 641 + ], + "NIST": [] + }, + { + "Shortcode": "V12.3.5", + "Ordinal": 5, + "Description": "Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 78 + ], + "NIST": [] + }, + { + "Shortcode": "V12.3.6", + "Ordinal": 6, + "Description": "Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 829 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V12.4", + "Ordinal": 4, + "Name": "File Storage Requirements", + "Items": [ + { + "Shortcode": "V12.4.1", + "Ordinal": 1, + "Description": "Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 922 + ], + "NIST": [] + }, + { + "Shortcode": "V12.4.2", + "Ordinal": 2, + "Description": "Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 509 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V12.5", + "Ordinal": 5, + "Name": "File Download Requirements", + "Items": [ + { + "Shortcode": "V12.5.1", + "Ordinal": 1, + "Description": "Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 552 + ], + "NIST": [] + }, + { + "Shortcode": "V12.5.2", + "Ordinal": 2, + "Description": "Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 434 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V12.6", + "Ordinal": 6, + "Name": "SSRF Protection Requirements", + "Items": [ + { + "Shortcode": "V12.6.1", + "Ordinal": 1, + "Description": "Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 918 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V13", + "Ordinal": 13, + "ShortName": "API", + "Name": "API and Web Service Verification Requirements", + "Items": [ + { + "Shortcode": "V13.1", + "Ordinal": 1, + "Name": "Generic Web Service Security Verification Requirements", + "Items": [ + { + "Shortcode": "V13.1.1", + "Ordinal": 1, + "Description": "Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V13.1.2", + "Ordinal": 2, + "Description": "Verify that access to administration and management functions is limited to authorized administrators.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 419 + ], + "NIST": [] + }, + { + "Shortcode": "V13.1.3", + "Ordinal": 3, + "Description": "Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 598 + ], + "NIST": [] + }, + { + "Shortcode": "V13.1.4", + "Ordinal": 4, + "Description": "Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + }, + { + "Shortcode": "V13.1.5", + "Ordinal": 5, + "Description": "Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 434 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V13.2", + "Ordinal": 2, + "Name": "RESTful Web Service Verification Requirements", + "Items": [ + { + "Shortcode": "V13.2.1", + "Ordinal": 1, + "Description": "Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 650 + ], + "NIST": [] + }, + { + "Shortcode": "V13.2.2", + "Ordinal": 2, + "Description": "Verify that JSON schema validation is in place and verified before accepting input.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 20 + ], + "NIST": [] + }, + { + "Shortcode": "V13.2.3", + "Ordinal": 3, + "Description": "Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 352 + ], + "NIST": [] + }, + { + "Shortcode": "V13.2.4", + "Ordinal": 4, + "Description": "Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + }, + { + "Shortcode": "V13.2.5", + "Ordinal": 5, + "Description": "Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 436 + ], + "NIST": [] + }, + { + "Shortcode": "V13.2.6", + "Ordinal": 6, + "Description": "Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 345 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V13.3", + "Ordinal": 3, + "Name": "SOAP Web Service Verification Requirements", + "Items": [ + { + "Shortcode": "V13.3.1", + "Ordinal": 1, + "Description": "Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 20 + ], + "NIST": [] + }, + { + "Shortcode": "V13.3.2", + "Ordinal": 2, + "Description": "Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 345 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V13.4", + "Ordinal": 4, + "Name": "GraphQL and other Web Service Data Layer Security Requirements", + "Items": [ + { + "Shortcode": "V13.4.1", + "Ordinal": 1, + "Description": "Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 770 + ], + "NIST": [] + }, + { + "Shortcode": "V13.4.2", + "Ordinal": 2, + "Description": "Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 285 + ], + "NIST": [] + } + ] + } + ] + }, + { + "Shortcode": "V14", + "Ordinal": 14, + "ShortName": "Config", + "Name": "Configuration Verification Requirements", + "Items": [ + { + "Shortcode": "V14.1", + "Ordinal": 1, + "Name": "Build", + "Items": [ + { + "Shortcode": "V14.1.1", + "Ordinal": 1, + "Description": "Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V14.1.2", + "Ordinal": 2, + "Description": "Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 120 + ], + "NIST": [] + }, + { + "Shortcode": "V14.1.3", + "Ordinal": 3, + "Description": "Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 16 + ], + "NIST": [] + }, + { + "Shortcode": "V14.1.4", + "Ordinal": 4, + "Description": "Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V14.1.5", + "Ordinal": 5, + "Description": "Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": false, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + } + ] + }, + { + "Shortcode": "V14.2", + "Ordinal": 2, + "Name": "Dependency", + "Items": [ + { + "Shortcode": "V14.2.1", + "Ordinal": 1, + "Description": "Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1026 + ], + "NIST": [] + }, + { + "Shortcode": "V14.2.2", + "Ordinal": 2, + "Description": "Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1002 + ], + "NIST": [] + }, + { + "Shortcode": "V14.2.3", + "Ordinal": 3, + "Description": "Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 829 + ], + "NIST": [] + }, + { + "Shortcode": "V14.2.4", + "Ordinal": 4, + "Description": "Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 829 + ], + "NIST": [] + }, + { + "Shortcode": "V14.2.5", + "Ordinal": 5, + "Description": "Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [], + "NIST": [] + }, + { + "Shortcode": "V14.2.6", + "Ordinal": 6, + "Description": "Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 265 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V14.3", + "Ordinal": 3, + "Name": "Unintended Security Disclosure Requirements", + "Items": [ + { + "Shortcode": "V14.3.1", + "Ordinal": 1, + "Description": "Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 209 + ], + "NIST": [] + }, + { + "Shortcode": "V14.3.2", + "Ordinal": 2, + "Description": "Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 497 + ], + "NIST": [] + }, + { + "Shortcode": "V14.3.3", + "Ordinal": 3, + "Description": "Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 200 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V14.4", + "Ordinal": 4, + "Name": "HTTP Security Headers Requirements", + "Items": [ + { + "Shortcode": "V14.4.1", + "Ordinal": 1, + "Description": "Verify that every HTTP response contains a Content-Type header. text/*, */*+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1).", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 173 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.2", + "Ordinal": 2, + "Description": "Verify that all API responses contain a Content-Disposition: attachment; filename=\"api.json\" header (or other appropriate filename for the content type).", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.3", + "Ordinal": 3, + "Description": "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": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 1021 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.4", + "Ordinal": 4, + "Description": "Verify that all responses contain a X-Content-Type-Options: nosniff header.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.5", + "Ordinal": 5, + "Description": "Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 523 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.6", + "Ordinal": 6, + "Description": "Verify that a suitable \"Referrer-Policy\" header is included, such as \"no-referrer\" or \"same-origin\".", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 116 + ], + "NIST": [] + }, + { + "Shortcode": "V14.4.7", + "Ordinal": 7, + "Description": "Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 346 + ], + "NIST": [] + } + ] + }, + { + "Shortcode": "V14.5", + "Ordinal": 5, + "Name": "Validate HTTP Request Header Requirements", + "Items": [ + { + "Shortcode": "V14.5.1", + "Ordinal": 1, + "Description": "Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 749 + ], + "NIST": [] + }, + { + "Shortcode": "V14.5.2", + "Ordinal": 2, + "Description": "Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 346 + ], + "NIST": [] + }, + { + "Shortcode": "V14.5.3", + "Ordinal": 3, + "Description": "Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the \"null\" origin.", + "L1": { + "Required": true, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 346 + ], + "NIST": [] + }, + { + "Shortcode": "V14.5.4", + "Ordinal": 4, + "Description": "Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.", + "L1": { + "Required": false, + "Requirement": "" + }, + "L2": { + "Required": true, + "Requirement": "" + }, + "L3": { + "Required": true, + "Requirement": "" + }, + "CWE": [ + 306 + ], + "NIST": [] + } + ] + } + ] + } + ] +} diff --git a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.xml b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.xml new file mode 100644 index 0000000000..e3135dc0a8 --- /dev/null +++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.xml @@ -0,0 +1,6751 @@ + + + Application Security Verification Standard Project + ASVS + 4.0.2 + The Application Security Verification Standard is a list of application security requirements or tests that can be used by architects, developers, testers, security professionals, tool vendors, and consumers to define, build, test and verify secure applications. + + + V1 + 1 + Architecture + Architecture, Design and Threat Modeling Requirements + + + V1.1 + 1 + Secure Software Development Lifecycle Requirements + + + V1.1.1 + 1 + Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + + + + V1.1.2 + 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. + + False + + + + True + + + + True + + + + 1053 + + + + + V1.1.3 + 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" + + False + + + + True + + + + True + + + + 1110 + + + + + V1.1.4 + 4 + Verify documentation and justification of all the application's trust boundaries, components, and significant data flows. + + False + + + + True + + + + True + + + + 1059 + + + + + V1.1.5 + 5 + Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 1059 + + + + + V1.1.6 + 6 + Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 637 + + + + + V1.1.7 + 7 + Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. + + False + + + + True + + + + True + + + + 637 + + + + + + + V1.2 + 2 + Authentication Architectural Requirements + + + V1.2.1 + 1 + Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 250 + + + + + V1.2.2 + 2 + Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 306 + + + + + V1.2.3 + 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. + + False + + + + True + + + + True + + + + 306 + + + + + V1.2.4 + 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. + + False + + + + True + + + + True + + + + 306 + + + + + + + V1.3 + 3 + Session Management Architectural Requirements + + + + V1.4 + 4 + Access Control Architectural Requirements + + + V1.4.1 + 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. + + False + + + + True + + + + True + + + + 602 + + + + + V1.4.2 + 2 + Verify that the chosen access control solution is flexible enough to meet the application's needs. + + False + + + + True + + + + True + + + + 284 + + + + + V1.4.3 + 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. + + False + + + + True + + + + True + + + + 272 + + + + + V1.4.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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 284 + + + + + V1.4.5 + 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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 275 + + + + + + + V1.5 + 5 + Input and Output Architectural Requirements + + + V1.5.1 + 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. + + False + + + + True + + + + True + + + + 1029 + + + + + V1.5.2 + 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. + + False + + + + True + + + + True + + + + 502 + + + + + V1.5.3 + 3 + Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 602 + + + + + V1.5.4 + 4 + Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 116 + + + + + + + V1.6 + 6 + Cryptographic Architectural Requirements + + + V1.6.1 + 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. + + False + + + + True + + + + True + + + + 320 + + + + + V1.6.2 + 2 + Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives. + + False + + + + True + + + + True + + + + 320 + + + + + V1.6.3 + 3 + Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data. + + False + + + + True + + + + True + + + + 320 + + + + + V1.6.4 + 4 + Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data. + + False + + + + True + + + + True + + + + 320 + + + + + + + V1.7 + 7 + Errors, Logging and Auditing Architectural Requirements + + + V1.7.1 + 1 + Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 1009 + + + + + V1.7.2 + 2 + Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + + + + + + V1.8 + 8 + Data Protection and Privacy Architectural Requirements + + + V1.8.1 + 1 + Verify that all sensitive data is identified and classified into protection levels. + + False + + + + True + + + + True + + + + + + + V1.8.2 + 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. + + False + + + + True + + + + True + + + + + + + + + V1.9 + 9 + Communications Architectural Requirements + + + V1.9.1 + 1 + Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 319 + + + + + V1.9.2 + 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. + + False + + + + True + + + + True + + + + 295 + + + + + + + V1.10 + 10 + Malicious Software Architectural Requirements + + + V1.10.1 + 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. + + False + + + + True + + + + True + + + + 284 + + + + + + + V1.11 + 11 + Business Logic Architectural Requirements + + + V1.11.1 + 1 + Verify the definition and documentation of all application components in terms of the business or security functions they provide. + + False + + + + True + + + + True + + + + 1059 + + + + + V1.11.2 + 2 + Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state. + + False + + + + True + + + + True + + + + 362 + + + + + V1.11.3 + 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. + + False + + + + False + + + + True + + + + 367 + + + + + + + V1.12 + 12 + Secure File Upload Architectural Requirements + + + V1.12.1 + 1 + Verify that user-uploaded files are stored outside of the web root. + + False + + + + True + + + + True + + + + 552 + + + + + V1.12.2 + 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 (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file. + + False + + + + True + + + + True + + + + 646 + + + + + + + V1.13 + 13 + API Architectural Requirements + + + + V1.14 + 14 + Configuration Architectural Requirements + + + V1.14.1 + 1 + Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms. + + False + + + + True + + + + True + + + + 923 + + + + + V1.14.2 + 2 + Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices. + + False + + + + True + + + + True + + + + 494 + + + + + V1.14.3 + 3 + Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions. + + False + + + + True + + + + True + + + + 1104 + + + + + V1.14.4 + 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. + + False + + + + True + + + + True + + + + + + + V1.14.5 + 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. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 265 + + + + + V1.14.6 + 6 + Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. + + False + + + + True + + + + True + + + + 477 + + + + + + + + + V2 + 2 + Authentication + Authentication Verification Requirements + + + V2.1 + 1 + Password Security Requirements + + + V2.1.1 + 1 + Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.2 + 2 + Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.3 + 3 + Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.4 + 4 + Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords. + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.5 + 5 + Verify users can change their password. + + True + + + + True + + + + True + + + + 620 + + + 5.1.1.2 + + + + V2.1.6 + 6 + Verify that password change functionality requires the user's current and new password. + + True + + + + True + + + + True + + + + 620 + + + 5.1.1.2 + + + + V2.1.7 + 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.8 + 8 + Verify that a password strength meter is provided to help users set a stronger password. + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.9 + 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.10 + 10 + Verify that there are no periodic credential rotation or password history requirements. + + True + + + + True + + + + True + + + + 263 + + + 5.1.1.2 + + + + V2.1.11 + 11 + Verify that "paste" functionality, browser password helpers, and external password managers are permitted. + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + V2.1.12 + 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 built-in functionality. + + True + + + + True + + + + True + + + + 521 + + + 5.1.1.2 + + + + + + V2.2 + 2 + General Authenticator Requirements + + + V2.2.1 + 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. + + True + + + + True + + + + True + + + + 307 + + + 5.2.2 + 5.1.1.2 + 5.1.4.2 + 5.1.5.2 + + + + V2.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. + + True + + + + True + + + + True + + + + 304 + + + 5.2.10 + + + + V2.2.3 + 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. + + True + + + + True + + + + True + + + + 620 + + + + + V2.2.4 + 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. + + False + + + + False + + + + True + + + + 308 + + + 5.2.5 + + + + V2.2.5 + 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. + + False + + + + False + + + + True + + + + 319 + + + 5.2.6 + + + + V2.2.6 + 6 + Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes. + + False + + + + False + + + + True + + + + 308 + + + 5.2.8 + + + + V2.2.7 + 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. + + False + + + + False + + + + True + + + + 308 + + + 5.2.9 + + + + + + V2.3 + 3 + Authenticator Lifecycle Requirements + + + V2.3.1 + 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. + + True + + + + True + + + + True + + + + 330 + + + 5.1.1.2 + A.3 + + + + V2.3.2 + 2 + Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens. + + False + + + + True + + + + True + + + + 308 + + + 6.1.3 + + + + V2.3.3 + 3 + Verify that renewal instructions are sent with sufficient time to renew time bound authenticators. + + False + + + + True + + + + True + + + + 287 + + + 6.1.4 + + + + + + V2.4 + 4 + Credential Storage Requirements + + + V2.4.1 + 1 + Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 916 + + + 5.1.1.2 + + + + V2.4.2 + 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 916 + + + 5.1.1.2 + + + + V2.4.3 + 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 916 + + + 5.1.1.2 + + + + V2.4.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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 916 + + + 5.1.1.2 + + + + V2.4.5 + 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). + + False + + + + True + + + + True + + + + 916 + + + 5.1.1.2 + + + + + + V2.5 + 5 + Credential Recovery Requirements + + + V2.5.1 + 1 + Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 640 + + + 5.1.1.2 + + + + V2.5.2 + 2 + Verify password hints or knowledge-based authentication (so-called "secret questions") are not present. + + True + + + + True + + + + True + + + + 640 + + + 5.1.1.2 + + + + V2.5.3 + 3 + Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 640 + + + 5.1.1.2 + + + + V2.5.4 + 4 + Verify shared or default accounts are not present (e.g. "root", "admin", or "sa"). + + True + + + + True + + + + True + + + + 16 + + + 5.1.1.2 + A.3 + + + + V2.5.5 + 5 + Verify that if an authentication factor is changed or replaced, that the user is notified of this event. + + True + + + + True + + + + True + + + + 304 + + + 6.1.2.3 + + + + V2.5.6 + 6 + Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 640 + + + 5.1.1.2 + + + + V2.5.7 + 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. + + False + + + + True + + + + True + + + + 308 + + + 6.1.2.3 + + + + + + V2.6 + 6 + Look-up Secret Verifier Requirements + + + V2.6.1 + 1 + Verify that lookup secrets can be used only once. + + False + + + + True + + + + True + + + + 308 + + + 5.1.2.2 + + + + V2.6.2 + 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. + + False + + + + True + + + + True + + + + 330 + + + 5.1.2.2 + + + + V2.6.3 + 3 + Verify that lookup secrets are resistant to offline attacks, such as predictable values. + + False + + + + True + + + + True + + + + 310 + + + 5.1.2.2 + + + + + + V2.7 + 7 + Out of Band Verifier Requirements + + + V2.7.1 + 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. + + True + + + + True + + + + True + + + + 287 + + + 5.1.3.2 + + + + V2.7.2 + 2 + Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes. + + True + + + + True + + + + True + + + + 287 + + + 5.1.3.2 + + + + V2.7.3 + 3 + Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request. + + True + + + + True + + + + True + + + + 287 + + + 5.1.3.2 + + + + V2.7.4 + 4 + Verify that the out of band authenticator and verifier communicates over a secure independent channel. + + True + + + + True + + + + True + + + + 523 + + + 5.1.3.2 + + + + V2.7.5 + 5 + Verify that the out of band verifier retains only a hashed version of the authentication code. + + False + + + + True + + + + True + + + + 256 + + + 5.1.3.2 + + + + V2.7.6 + 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). + + False + + + + True + + + + True + + + + 310 + + + 5.1.3.2 + + + + + + V2.8 + 8 + Single or Multi-factor One Time Verifier Requirements + + + V2.8.1 + 1 + Verify that time-based OTPs have a defined lifetime before expiring. + + True + + + + True + + + + True + + + + 613 + + + 5.1.4.2 + 5.1.5.2 + + + + V2.8.2 + 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. + + False + + + + True + + + + True + + + + 320 + + + 5.1.4.2 + 5.1.5.2 + + + + V2.8.3 + 3 + Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs. + + False + + + + True + + + + True + + + + 326 + + + 5.1.4.2 + 5.1.5.2 + + + + V2.8.4 + 4 + Verify that time-based OTP can be used only once within the validity period. + + False + + + + True + + + + True + + + + 287 + + + 5.1.4.2 + 5.1.5.2 + + + + V2.8.5 + 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. + + False + + + + True + + + + True + + + + 287 + + + 5.1.5.2 + + + + V2.8.6 + 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. + + False + + + + True + + + + True + + + + 613 + + + 5.2.1 + + + + V2.8.7 + 7 + Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know. + + False + + + + True + Optional + + + True + + + + 308 + + + 5.2.3 + + + + + + V2.9 + 9 + Cryptographic Software and Devices Verifier Requirements + + + V2.9.1 + 1 + Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage. + + False + + + + True + + + + True + + + + 320 + + + 5.1.7.2 + + + + V2.9.2 + 2 + Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. + + False + + + + True + + + + True + + + + 330 + + + 5.1.7.2 + + + + V2.9.3 + 3 + Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. + + False + + + + True + + + + True + + + + 327 + + + 5.1.7.2 + + + + + + V2.10 + 10 + Service Authentication Requirements + + + V2.10.1 + 1 + Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access. + + False + + + + True + OS assisted + + + True + HSM + + + 287 + + + 5.1.1.1 + + + + V2.10.2 + 2 + Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation). + + False + + + + True + OS assisted + + + True + HSM + + + 255 + + + 5.1.1.1 + + + + V2.10.3 + 3 + Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access. + + False + + + + True + OS assisted + + + True + HSM + + + 522 + + + 5.1.1.1 + + + + V2.10.4 + 4 + Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage. + + False + + + + True + OS assisted + + + True + HSM + + + 798 + + + + + + + + + V3 + 3 + Session + Session Management Verification Requirements + + + V3.1 + 1 + Fundamental Session Management Requirements + + + V3.1.1 + 1 + Verify the application never reveals session tokens in URL parameters. + + True + + + + True + + + + True + + + + 598 + + + + + + + V3.2 + 2 + Session Binding Requirements + + + V3.2.1 + 1 + Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 384 + + + 7.1 + + + + V3.2.2 + 2 + Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 331 + + + 7.1 + + + + V3.2.3 + 3 + Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage. + + True + + + + True + + + + True + + + + 539 + + + 7.1 + + + + V3.2.4 + 4 + Verify that session token are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 331 + + + 7.1 + + + + + + V3.3 + 3 + Session Logout and Timeout Requirements + + + V3.3.1 + 1 + Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 613 + + + 7.1 + + + + V3.3.2 + 2 + If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + 30 days + + + True + 12 hours or 30 minutes of inactivity, 2FA optional + + + True + 12 hours or 15 minutes of inactivity, with 2FA + + + 613 + + + 7.2 + + + + V3.3.3 + 3 + Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties. + + False + + + + True + + + + True + + + + 613 + + + + + V3.3.4 + 4 + Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices. + + False + + + + True + + + + True + + + + 613 + + + 7.1 + + + + + + V3.4 + 4 + Cookie-based Session Management + + + V3.4.1 + 1 + Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 614 + + + 7.1.1 + + + + V3.4.2 + 2 + Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 1004 + + + 7.1.1 + + + + V3.4.3 + 3 + Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 16 + + + 7.1.1 + + + + V3.4.4 + 4 + Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality. + + True + + + + True + + + + True + + + + 16 + + + 7.1.1 + + + + V3.4.5 + 5 + Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 16 + + + 7.1.1 + + + + + + V3.5 + 5 + Token-based Session Management + + + V3.5.1 + 1 + Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. + + False + + + + True + + + + True + + + + 290 + + + 7.1.2 + + + + V3.5.2 + 2 + Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations. + + False + + + + True + + + + True + + + + 798 + + + + + V3.5.3 + 3 + Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks. + + False + + + + True + + + + True + + + + 345 + + + + + + + V3.6 + 6 + Re-authentication from a Federation or Assertion + + + V3.6.1 + 1 + Verify that relying parties specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the subscriber if they haven't used a session within that period. + + False + + + + False + + + + True + + + + 613 + + + 7.2.1 + + + + V3.6.2 + 2 + Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user. + + False + + + + False + + + + True + + + + 613 + + + 7.2.1 + + + + + + V3.7 + 7 + Defenses Against Session Management Exploits + + + V3.7.1 + 1 + Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. + + True + + + + True + + + + True + + + + 306 + + + + + + + + + V4 + 4 + Access + Access Control Verification Requirements + + + V4.1 + 1 + General Access Control Design + + + V4.1.1 + 1 + Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed. + + True + + + + True + + + + True + + + + 602 + + + + + V4.1.2 + 2 + Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized. + + True + + + + True + + + + True + + + + 639 + + + + + V4.1.3 + 3 + Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 285 + + + + + V4.1.4 + 4 + Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 276 + + + + + V4.1.5 + 5 + Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 285 + + + + + + + V4.2 + 2 + Operation Level Access Control + + + V4.2.1 + 1 + Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records. + + True + + + + True + + + + True + + + + 639 + + + + + V4.2.2 + 2 + Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality. + + True + + + + True + + + + True + + + + 352 + + + + + + + V4.3 + 3 + Other Access Control Considerations + + + V4.3.1 + 1 + Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use. + + True + + + + True + + + + True + + + + 419 + + + + + V4.3.2 + 2 + Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. + + True + + + + True + + + + True + + + + 548 + + + + + V4.3.3 + 3 + Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud. + + False + + + + True + + + + True + + + + 732 + + + + + + + + + V5 + 5 + Validation + Validation, Sanitization and Encoding Verification Requirements + + + V5.1 + 1 + Input Validation Requirements + + + V5.1.1 + 1 + Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables). + + True + + + + True + + + + True + + + + 235 + + + + + V5.1.2 + 2 + Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 915 + + + + + V5.1.3 + 3 + Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 20 + + + + + V5.1.4 + 4 + Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 20 + + + + + V5.1.5 + 5 + Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. + + True + + + + True + + + + True + + + + 601 + + + + + + + V5.2 + 2 + Sanitization and Sandboxing Requirements + + + V5.2.1 + 1 + Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 116 + + + + + V5.2.2 + 2 + Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length. + + True + + + + True + + + + True + + + + 138 + + + + + V5.2.3 + 3 + Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. + + True + + + + True + + + + True + + + + 147 + + + + + V5.2.4 + 4 + Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. + + True + + + + True + + + + True + + + + 95 + + + + + V5.2.5 + 5 + Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. + + True + + + + True + + + + True + + + + 94 + + + + + V5.2.6 + 6 + Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. + + True + + + + True + + + + True + + + + 918 + + + + + V5.2.7 + 7 + Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. + + True + + + + True + + + + True + + + + 159 + + + + + V5.2.8 + 8 + Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. + + True + + + + True + + + + True + + + + 94 + + + + + + + V5.3 + 3 + Output Encoding and Injection Prevention Requirements + + + V5.3.1 + 1 + Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 116 + + + + + V5.3.2 + 2 + Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 176 + + + + + V5.3.3 + 3 + Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 79 + + + + + V5.3.4 + 4 + Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 89 + + + + + V5.3.5 + 5 + Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 89 + + + + + V5.3.6 + 6 + Verify that the application protects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, Content Security Policy (CSP) bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 830 + + + + + V5.3.7 + 7 + Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 90 + + + + + V5.3.8 + 8 + Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 78 + + + + + V5.3.9 + 9 + Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks. + + True + + + + True + + + + True + + + + 829 + + + + + V5.3.10 + 10 + Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 643 + + + + + + + V5.4 + 4 + Memory, String, and Unmanaged Code Requirements + + + V5.4.1 + 1 + Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. + + False + + + + True + + + + True + + + + 120 + + + + + V5.4.2 + 2 + Verify that format strings do not take potentially hostile input, and are constant. + + False + + + + True + + + + True + + + + 134 + + + + + V5.4.3 + 3 + Verify that sign, range, and input validation techniques are used to prevent integer overflows. + + False + + + + True + + + + True + + + + 190 + + + + + + + V5.5 + 5 + Deserialization Prevention Requirements + + + V5.5.1 + 1 + Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 502 + + + + + V5.5.2 + 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 XML eXternal Entity (XXE) attacks. + + True + + + + True + + + + True + + + + 611 + + + + + V5.5.3 + 3 + Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). + + True + + + + True + + + + True + + + + 502 + + + + + V5.5.4 + 4 + Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON. + + True + + + + True + + + + True + + + + 95 + + + + + + + + + V6 + 6 + Cryptography + Stored Cryptography Verification Requirements + + + V6.1 + 1 + Data Classification + + + V6.1.1 + 1 + Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. + + False + + + + True + + + + True + + + + 311 + + + + + V6.1.2 + 2 + Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records. + + False + + + + True + + + + True + + + + 311 + + + + + V6.1.3 + 3 + Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records. + + False + + + + True + + + + True + + + + 311 + + + + + + + V6.2 + 2 + Algorithms + + + V6.2.1 + 1 + Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks. + + True + + + + True + + + + True + + + + 310 + + + + + V6.2.2 + 2 + Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 327 + + + + + V6.2.3 + 3 + Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice. + + False + + + + True + + + + True + + + + 326 + + + + + V6.2.4 + 4 + Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 326 + + + + + V6.2.5 + 5 + Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility. + + False + + + + True + + + + True + + + + 326 + + + + + V6.2.6 + 6 + Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used. + + False + + + + True + + + + True + + + + 326 + + + + + V6.2.7 + 7 + Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party. + + False + + + + False + + + + True + + + + 326 + + + + + V6.2.8 + 8 + Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. + + False + + + + False + + + + True + + + + 385 + + + + + + + V6.3 + 3 + Random Values + + + V6.3.1 + 1 + Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker. + + False + + + + True + + + + True + + + + 338 + + + + + V6.3.2 + 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. + + False + + + + True + + + + True + + + + 338 + + + + + V6.3.3 + 3 + Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. + + False + + + + False + + + + True + + + + 338 + + + + + + + V6.4 + 4 + Secret Management + + + V6.4.1 + 1 + Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 798 + + + + + V6.4.2 + 2 + Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 320 + + + + + + + + + V7 + 7 + Error + Error Handling and Logging Verification Requirements + + + V7.1 + 1 + Log Content Requirements + + + V7.1.1 + 1 + Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 532 + + + + + V7.1.2 + 2 + Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 532 + + + + + V7.1.3 + 3 + Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 778 + + + + + V7.1.4 + 4 + Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 778 + + + + + + + V7.2 + 2 + Log Processing Requirements + + + V7.2.1 + 1 + Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. + + False + + + + True + + + + True + + + + 778 + + + + + V7.2.2 + 2 + Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations. + + False + + + + True + + + + True + + + + 285 + + + + + + + V7.3 + 3 + Log Protection Requirements + + + V7.3.1 + 1 + Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 117 + + + + + V7.3.2 + 2 + Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 117 + + + + + V7.3.3 + 3 + Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 200 + + + + + V7.3.4 + 4 + Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + + + + + + V7.4 + 4 + Error Handling + + + V7.4.1 + 1 + Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 210 + + + + + V7.4.2 + 2 + Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 544 + + + + + V7.4.3 + 3 + Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 431 + + + + + + + + + V8 + 8 + Data + Data Protection Verification Requirements + + + V8.1 + 1 + General Data Protection + + + V8.1.1 + 1 + Verify the application protects sensitive data from being cached in server components such as load balancers and application caches. + + False + + + + True + + + + True + + + + 524 + + + + + V8.1.2 + 2 + Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data. + + False + + + + True + + + + True + + + + 524 + + + + + V8.1.3 + 3 + Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values. + + False + + + + True + + + + True + + + + 233 + + + + + V8.1.4 + 4 + Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application. + + False + + + + True + + + + True + + + + 770 + + + + + V8.1.5 + 5 + Verify that regular backups of important data are performed and that test restoration of data is performed. + + False + + + + False + + + + True + + + + 19 + + + + + V8.1.6 + 6 + Verify that backups are stored securely to prevent data from being stolen or corrupted. + + False + + + + False + + + + True + + + + 19 + + + + + + + V8.2 + 2 + Client-side Data Protection + + + V8.2.1 + 1 + Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers. + + True + + + + True + + + + True + + + + 525 + + + + + V8.2.2 + 2 + Verify that data stored in browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII. + + True + + + + True + + + + True + + + + 922 + + + + + V8.2.3 + 3 + Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. + + True + + + + True + + + + True + + + + 922 + + + + + + + V8.3 + 3 + Sensitive Private Data + + + V8.3.1 + 1 + Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. + + True + + + + True + + + + True + + + + 319 + + + + + V8.3.2 + 2 + Verify that users have a method to remove or export their data on demand. + + True + + + + True + + + + True + + + + 212 + + + + + V8.3.3 + 3 + Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way. + + True + + + + True + + + + True + + + + 285 + + + + + V8.3.4 + 4 + Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 200 + + + + + V8.3.5 + 5 + Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. + + False + + + + True + + + + True + + + + 532 + + + + + V8.3.6 + 6 + Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data. + + False + + + + True + + + + True + + + + 226 + + + + + V8.3.7 + 7 + Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 327 + + + + + V8.3.8 + 8 + Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. + + False + + + + True + + + + True + + + + 285 + + + + + + + + + V9 + 9 + Communications + Communications Verification Requirements + + + V9.1 + 1 + Client Communications Security Requirements + + + V9.1.1 + 1 + Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 319 + + + + + V9.1.2 + 2 + Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred. + + True + + + + True + + + + True + + + + 326 + + + + + V9.1.3 + 3 + Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite. + + True + + + + True + + + + True + + + + 326 + + + + + + + V9.2 + 2 + Server Communications Security Requirements + + + V9.2.1 + 1 + Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected. + + False + + + + True + + + + True + + + + 295 + + + + + V9.2.2 + 2 + Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols. + + False + + + + True + + + + True + + + + 319 + + + + + V9.2.3 + 3 + Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated. + + False + + + + True + + + + True + + + + 287 + + + + + V9.2.4 + 4 + Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. + + False + + + + True + + + + True + + + + 299 + + + + + V9.2.5 + 5 + Verify that backend TLS connection failures are logged. + + False + + + + False + + + + True + + + + 544 + + + + + + + + + V10 + 10 + Malicious + Malicious Code Verification Requirements + + + V10.1 + 1 + Code Integrity Controls + + + V10.1.1 + 1 + Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections. + + False + + + + False + + + + True + + + + 749 + + + + + + + V10.2 + 2 + Malicious Code Search + + + V10.2.1 + 1 + Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data. + + False + + + + True + + + + True + + + + 359 + + + + + V10.2.2 + 2 + Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location. + + False + + + + True + + + + True + + + + 272 + + + + + V10.2.3 + 3 + Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. + + False + + + + False + + + + True + + + + 507 + + + + + V10.2.4 + 4 + Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions. + + False + + + + False + + + + True + + + + 511 + + + + + V10.2.5 + 5 + Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. + + False + + + + False + + + + True + + + + 511 + + + + + V10.2.6 + 6 + Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality. + + False + + + + False + + + + True + + + + 507 + + + + + + + V10.3 + 3 + Deployed Application Integrity Controls + + + V10.3.1 + 1 + Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update. + + True + + + + True + + + + True + + + + 16 + + + + + V10.3.2 + 2 + Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. + + True + + + + True + + + + True + + + + 353 + + + + + V10.3.3 + 3 + Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change. + + True + + + + True + + + + True + + + + 350 + + + + + + + + + V11 + 11 + BusLogic + Business Logic Verification Requirements + + + V11.1 + 1 + Business Logic Security Requirements + + + V11.1.1 + 1 + Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps. + + True + + + + True + + + + True + + + + 841 + + + + + V11.1.2 + 2 + Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly. + + True + + + + True + + + + True + + + + 799 + + + + + V11.1.3 + 3 + Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis. + + True + + + + True + + + + True + + + + 770 + + + + + V11.1.4 + 4 + Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks. + + True + + + + True + + + + True + + + + 770 + + + + + V11.1.5 + 5 + Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies. + + True + + + + True + + + + True + + + + 841 + + + + + V11.1.6 + 6 + Verify the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations. + + False + + + + True + + + + True + + + + 367 + + + + + V11.1.7 + 7 + Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 754 + + + + + V11.1.8 + 8 + Verify the application has configurable alerting when automated attacks or unusual activity is detected. + + False + + + + True + + + + True + + + + 390 + + + + + + + + + V12 + 12 + Files + File and Resources Verification Requirements + + + V12.1 + 1 + File Upload Requirements + + + V12.1.1 + 1 + Verify that the application will not accept large files that could fill up storage or cause a denial of service. + + True + + + + True + + + + True + + + + 400 + + + + + V12.1.2 + 2 + Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus exhausting file storage limits. + + False + + + + True + + + + True + + + + 409 + + + + + V12.1.3 + 3 + Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. + + False + + + + True + + + + True + + + + 770 + + + + + + + V12.2 + 2 + File Integrity Requirements + + + V12.2.1 + 1 + Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content. + + False + + + + True + + + + True + + + + 434 + + + + + + + V12.3 + 3 + File Execution Requirements + + + V12.3.1 + 1 + Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal. + + True + + + + True + + + + True + + + + 22 + + + + + V12.3.2 + 2 + Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI). + + True + + + + True + + + + True + + + + 73 + + + + + V12.3.3 + 3 + Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. + + True + + + + True + + + + True + + + + 98 + + + + + V12.3.4 + 4 + Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename. + + True + + + + True + + + + True + + + + 641 + + + + + V12.3.5 + 5 + Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection. + + True + + + + True + + + + True + + + + 78 + + + + + V12.3.6 + 6 + Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs. + + False + + + + True + + + + True + + + + 829 + + + + + + + V12.4 + 4 + File Storage Requirements + + + V12.4.1 + 1 + Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation. + + True + + + + True + + + + True + + + + 922 + + + + + V12.4.2 + 2 + Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content. + + True + + + + True + + + + True + + + + 509 + + + + + + + V12.5 + 5 + File Download Requirements + + + V12.5.1 + 1 + Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required. + + True + + + + True + + + + True + + + + 552 + + + + + V12.5.2 + 2 + Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content. + + True + + + + True + + + + True + + + + 434 + + + + + + + V12.6 + 6 + SSRF Protection Requirements + + + V12.6.1 + 1 + Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from. + + True + + + + True + + + + True + + + + 918 + + + + + + + + + V13 + 13 + API + API and Web Service Verification Requirements + + + V13.1 + 1 + Generic Web Service Security Verification Requirements + + + V13.1.1 + 1 + Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks. + + True + + + + True + + + + True + + + + 116 + + + + + V13.1.2 + 2 + Verify that access to administration and management functions is limited to authorized administrators. + + True + + + + True + + + + True + + + + 419 + + + + + V13.1.3 + 3 + Verify API URLs do not expose sensitive information, such as the API key, session tokens etc. + + True + + + + True + + + + True + + + + 598 + + + + + V13.1.4 + 4 + Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. + + False + + + + True + + + + True + + + + 285 + + + + + V13.1.5 + 5 + Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type). + + False + + + + True + + + + True + + + + 434 + + + + + + + V13.2 + 2 + RESTful Web Service Verification Requirements + + + V13.2.1 + 1 + Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. + + True + + + + True + + + + True + + + + 650 + + + + + V13.2.2 + 2 + Verify that JSON schema validation is in place and verified before accepting input. + + True + + + + True + + + + True + + + + 20 + + + + + V13.2.3 + 3 + Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks. + + True + + + + True + + + + True + + + + 352 + + + + + V13.2.4 + 4 + Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated. + + False + + + + True + + + + True + + + + 770 + + + + + V13.2.5 + 5 + Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. + + False + + + + True + + + + True + + + + 436 + + + + + V13.2.6 + 6 + Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. + + False + + + + True + + + + True + + + + 345 + + + + + + + V13.3 + 3 + SOAP Web Service Verification Requirements + + + V13.3.1 + 1 + Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place. + + True + + + + True + + + + True + + + + 20 + + + + + V13.3.2 + 2 + Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service. + + False + + + + True + + + + True + + + + 345 + + + + + + + V13.4 + 4 + GraphQL and other Web Service Data Layer Security Requirements + + + V13.4.1 + 1 + Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. + + False + + + + True + + + + True + + + + 770 + + + + + V13.4.2 + 2 + Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer. + + False + + + + True + + + + True + + + + 285 + + + + + + + + + V14 + 14 + Config + Configuration Verification Requirements + + + V14.1 + 1 + Build + + + V14.1.1 + 1 + Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts. + + False + + + + True + + + + True + + + + + + + V14.1.2 + 2 + Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found. + + False + + + + True + + + + True + + + + 120 + + + + + V14.1.3 + 3 + Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use. + + False + + + + True + + + + True + + + + 16 + + + + + V14.1.4 + 4 + Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion. + + False + + + + True + + + + True + + + + + + + V14.1.5 + 5 + Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering. + + False + + + + False + + + + True + + + + + + + + + V14.2 + 2 + Dependency + + + V14.2.1 + 1 + Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + True + + + + True + + + + True + + + + 1026 + + + + + V14.2.2 + 2 + Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users. + + True + + + + True + + + + True + + + + 1002 + + + + + V14.2.3 + 3 + Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. + + True + + + + True + + + + True + + + + 829 + + + + + V14.2.4 + 4 + Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 829 + + + + + V14.2.5 + 5 + Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + + + + V14.2.6 + 6 + Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) + + False + + + + True + + + + True + + + + 265 + + + + + + + V14.3 + 3 + Unintended Security Disclosure Requirements + + + V14.3.1 + 1 + Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures. + + True + + + + True + + + + True + + + + 209 + + + + + V14.3.2 + 2 + Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures. + + True + + + + True + + + + True + + + + 497 + + + + + V14.3.3 + 3 + Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components. + + True + + + + True + + + + True + + + + 200 + + + + + + + V14.4 + 4 + HTTP Security Headers Requirements + + + V14.4.1 + 1 + Verify that every HTTP response contains a Content-Type header. text/*, */*+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1). + + True + + + + True + + + + True + + + + 173 + + + + + V14.4.2 + 2 + Verify that all API responses contain a Content-Disposition: attachment; filename="api.json" header (or other appropriate filename for the content type). + + True + + + + True + + + + True + + + + 116 + + + + + V14.4.3 + 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. + + True + + + + True + + + + True + + + + 1021 + + + + + V14.4.4 + 4 + Verify that all responses contain a X-Content-Type-Options: nosniff header. + + True + + + + True + + + + True + + + + 116 + + + + + V14.4.5 + 5 + Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains. + + True + + + + True + + + + True + + + + 523 + + + + + V14.4.6 + 6 + Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin". + + True + + + + True + + + + True + + + + 116 + + + + + V14.4.7 + 7 + Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers. + + True + + + + True + + + + True + + + + 346 + + + + + + + V14.5 + 5 + Validate HTTP Request Header Requirements + + + V14.5.1 + 1 + Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context. + + True + + + + True + + + + True + + + + 749 + + + + + V14.5.2 + 2 + Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker. + + True + + + + True + + + + True + + + + 346 + + + + + V14.5.3 + 3 + Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the "null" origin. + + True + + + + True + + + + True + + + + 346 + + + + + V14.5.4 + 4 + Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application. + + False + + + + True + + + + True + + + + 306 + + + + + + + + + diff --git a/4.0/docs_en/en b/4.0/docs_en/en new file mode 100644 index 0000000000..e69de29bb2 diff --git a/4.0/docs_fr/fr b/4.0/docs_fr/fr new file mode 100644 index 0000000000..e69de29bb2 diff --git a/4.0/en/0x00-Header.md b/4.0/en/0x00-Header.md index 489fc8d6ec..0209a4197d 100644 --- a/4.0/en/0x00-Header.md +++ b/4.0/en/0x00-Header.md @@ -2,8 +2,8 @@ ![OWASP LOGO](../images/owasp_logo_1c_notext.png) -# Application Security Verification Standard 4.0 +# Application Security Verification Standard 4.0.2 ## Final -March 2019 +October 2020 diff --git a/4.0/en/0x01-Frontispiece.md b/4.0/en/0x01-Frontispiece.md index dc7ed259b3..8542c124d3 100644 --- a/4.0/en/0x01-Frontispiece.md +++ b/4.0/en/0x01-Frontispiece.md @@ -6,52 +6,41 @@ The Application Security Verification Standard is a list of application security ## Copyright and License +Version 4.0.2, October 2020 + ![license](../images/license.png) -Copyright © 2008-2019 The OWASP Foundation. This document is released under the [Creative Commons Attribution ShareAlike 3.0 license](https://creativecommons.org/licenses/by-sa/3.0/). For any reuse or distribution, you must make clear to others the license terms of this work. -Version 4.0.1, March 2019 +Copyright © 2008-2020 The OWASP Foundation. This document is released under the [Creative Commons Attribution ShareAlike 3.0 license](https://creativecommons.org/licenses/by-sa/3.0/). For any reuse or distribution, you must make clear to others the license terms of this work. ## Project Leads -- Andrew van der Stock -- Daniel Cuthbert -- Jim Manico -- Josh C Grossman -- Mark Burnett - -## Contributors and Reviewers - -- Osama Elnaggar -- Erlend Oftedal -- Serg Belkommen -- David Johansson -- Tonimir Kisasondi -- Ron Perris -- Jason Axley -- Abhay Bhargav -- Benedikt Bauer -- Elar Lang -- ScriptingXSS -- Philippe De Ryck -- Grog's Axle -- Marco Schnüriger -- Jacob Salassi -- Glenn ten Cate -- Anthony Weems -- bschach -- javixeneize -- Dan Cornell -- hello7s -- Lewis Ardern -- Jim Newman -- Stuart Gunter -- Geoff Baskwill -- Talargoni -- Ståle Pettersen -- Kelby Ludwig -- Jason Morrow -- Rogan Dawes +| | | | +|---------------------- |----------------- |------------ | +| Andrew van der Stock | Daniel Cuthbert | Jim Manico | +| Josh C Grossman | Mark Burnett | | -The Application Security Verification Standard is built upon the shoulders of those involved from ASVS 1.0 in 2008 to 3.0 in 2016. Much of the structure and verification items that are still in the ASVS today were originally written by Mike Boberski, Jeff Williams and Dave Wichers, but there are many more contributors. Thank you to all those previously involved. For a comprehensive list of all those who have contributed to earlier versions, please consult each prior version. +## Major Contributors + +| | | | +|---------------- |---------------- |------------------- | +| Abhay Bhargav | Benedikt Bauer | Elar Lang | +| Osama Elnaggar | Ron Perris | Tonimir Kisasondi | + +## Other Contributors and Reviewers -If a credit is missing from the 4.0 credit list above, please contact vanderaj@owasp.org or log a ticket at GitHub to be recognized in future 4.x updates. \ No newline at end of file +| | | | | | +|---------------- |------------------ |--------------------- |-------------------- |--------------------- | +| Aaron Guzman | Anthony Weems | Barbara Schachner | Christopher Loessl | Clément Notin | +| Dan Cornell | Daniël Geerts | David Clarke | David Johansson | David Quisenberry | +| Erlend Oftedal | Fatih Ersinadim | Filip van Laenen | Geoff Baskwill | Glenn ten Cate | +| Grant Ongers | hello7s | Jacob Salassi | James Sulinski | Jason Axley | +| Jason Morrow | Javier Dominguez | Jet Anderson | Jim Newman | Jonathan Schnittger | +| Joseph Kerby | Kelby Ludwig | Lars Haulin | Lewis Ardern | lyz-code | +| Marc Aubry | Marco Schnüriger | Philippe De Ryck | Ralph Andalis | Ravi Balla | +| Rick Mitchell | Riotaro Okada | Robin Wood | Rogan Dawes | Ryan Goltry | +| Sajjad Pourali | Serg Belkommen | Siim Puustusmaa | Ståle Pettersen | Stuart Gunter | +| Tal Argoni | Tomasz Wrobel | Vincent De Schutter | | | + +If a credit is missing from the 4.0.2 credit list above, please log a ticket at GitHub to be recognized in future 4.x updates. + +The Application Security Verification Standard is built upon the shoulders of those involved from ASVS 1.0 in 2008 to 3.0 in 2016. Much of the structure and verification items that are still in the ASVS today were originally written by Mike Boberski, Jeff Williams and Dave Wichers, but there are many more contributors. Thank you to all those previously involved. For a comprehensive list of all those who have contributed to earlier versions, please consult each prior version. diff --git a/4.0/en/0x02-Preface.md b/4.0/en/0x02-Preface.md index 3a5c8faa5b..47dd497b99 100644 --- a/4.0/en/0x02-Preface.md +++ b/4.0/en/0x02-Preface.md @@ -2,6 +2,8 @@ Welcome to the Application Security Verification Standard (ASVS) version 4.0. The 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. +Version 4.0.2 is the second minor patch to v4.0 intended to fix spelling errors and make requirements clearer without making breaking changes such as materially changing requirements or adding/removing requirements. + ASVS v4.0 is the culmination of community effort and industry feedback over the last decade. We have attempted to make it easier to adopt the ASVS for a variety of different use cases throughout any secure software development lifecycle. We expect that there will most likely never be 100% agreement on the contents of any web application standard, including the ASVS. Risk analysis is always subjective to some extent, which creates a challenge when attempting to generalize in a one-size-fits-all standard. However, we hope that the latest updates made in this version are a step in the right direction, and enhance the concepts introduced in this critical industry standard. @@ -16,7 +18,7 @@ ASVS 4.0 has been wholly renumbered from start to finish. The new numbering sche New in 4.0 is a comprehensive mapping to the Common Weakness Enumeration (CWE), one of the most commonly desired feature requests we've had over the last decade. CWE mapping allows tool manufacturers and those using vulnerability management software to match up results from other tools and previous ASVS versions to 4.0 and later. To make room for the CWE entry, we've had to retire the "Since" column, which as we completely renumbered, makes less sense than in previous versions of the ASVS. Not every item in the ASVS has an associated CWE, and as CWE has a great deal of duplication, we've attempted to use the most commonly used rather than necessarily the closest match. Verification controls are not always mappable to equivalent weaknesses. We welcome ongoing discussion with the CWE community and information security field more generally on closing this gap. -We have worked to comprehensively meet and exceed the requirements for addressing the OWASP Top 10 2017 and the OWASP Proactive Controls 2018. As the OWASP Top 10 2018 is the bare minimum to avoid negligence, we have deliberately made all but specific logging Top 10 requirements Level 1 controls, making it easier for OWASP Top 10 adopters to step up to an actual security standard. +We have worked to comprehensively meet and exceed the requirements for addressing the OWASP Top 10 2017 and the OWASP Proactive Controls 2018. As the OWASP Top 10 2017 is the bare minimum to avoid negligence, we have deliberately made all but specific logging Top 10 requirements Level 1 controls, making it easier for OWASP Top 10 adopters to step up to an actual security standard. We set out to ensure that the ASVS 4.0 Level 1 is a comprehensive superset of PCI DSS 3.2.1 Sections 6.5, for application design, coding, testing, secure code reviews, and penetration tests. This necessitated covering buffer overflow and unsafe memory operations in V5, and unsafe memory-related compilation flags in V14, in addition to existing industry-leading application and web service verification requirements. @@ -26,4 +28,4 @@ Due to the size of the ASVS 4.0, as well as our desire to become the baseline AS Lastly, we have de-duped and retired less impactful controls. Over time, the ASVS started being a comprehensive set of controls, but not all controls are equal at producing secure software. This effort to eliminate low impact items could go further. In a future edition of the ASVS, the Common Weakness Scoring System (CWSS) will help prioritize further those controls which are truly important and those that should be retired. -As of version 4.0, the ASVS will focus solely on being the leading web apps and service standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture. \ No newline at end of file +As of version 4.0, the ASVS will focus solely on being the leading web apps and service standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture. diff --git a/4.0/en/0x03-Using-ASVS.md b/4.0/en/0x03-Using-ASVS.md index b5bd2298b9..55f8f7f17f 100644 --- a/4.0/en/0x03-Using-ASVS.md +++ b/4.0/en/0x03-Using-ASVS.md @@ -19,11 +19,11 @@ Each ASVS level contains a list of security requirements. Each of these requirem Figure 1 - OWASP Application Security Verification Standard 4.0 Levels -Level 1 is the only level that is completely penetration testable using humans. All others require access to documentation, source code, configuration, and the people involved in the development process. However, even if L1 allows "black box" (no documentation and no source) testing to occur, it is not effective assurance and must stop. Malicious attackers have a great deal of time, most penetration tests are over within a couple of weeks. Defenders need to build in security controls, protect, find and resolve all weaknesses, and detect and respond to malicious actors in a reasonable time. Malicious actors have essentially infinite time and only require a single porous defense, a single weakness, or missing detection to succeed. Black box testing, often performed at the end of development, quickly, or not at all, is completely unable to cope with that asymmetry. +Level 1 is the only level that is completely penetration testable using humans. All others require access to documentation, source code, configuration, and the people involved in the development process. However, even if L1 allows "black box" (no documentation and no source) testing to occur, it is not an effective assurance activity and should be actively discouraged. Malicious attackers have a great deal of time, most penetration tests are over within a couple of weeks. Defenders need to build in security controls, protect, find and resolve all weaknesses, and detect and respond to malicious actors in a reasonable time. Malicious actors have essentially infinite time and only require a single porous defense, a single weakness, or missing detection to succeed. Black box testing, often performed at the end of development, quickly, or not at all, is completely unable to cope with that asymmetry. Over the last 30+ years, black box testing has proven over and over again to miss critical security issues that led directly to ever more massive breaches. We strongly encourage the use of a wide range of security assurance and verification, including replacing penetration tests with source code led (hybrid) penetration tests at Level 1, with full access to developers and documentation throughout the development process. Financial regulators do not tolerate external financial audits with no access to the books, sample transactions, or the people performing the controls. Industry and governments must demand the same standard of transparency in the software engineering field. -We strongly encourage the use of security tools, but within the development process itself, such as DAST and SAST tools being used continuously by the build pipeline to find easy to find security issues that should never be present. +We strongly encourage the use of security tools within the development process itself. DAST and SAST tools can be used continuously by the build pipeline to find easy to find security issues that should never be present. Automated tools and online scans are unable to complete more than half of the ASVS without human assistance. If comprehensive test automation for each build is required, then a combination of custom unit and integration tests, along with build initiated online scans are used. Business logic flaws and access control testing is only possible using human assistance. These should be turned into unit and integration tests. @@ -53,10 +53,27 @@ ASVS Level 3 is the highest level of verification within the ASVS. This level is Organizations may require ASVS Level 3 for applications that perform critical functions, where failure could significantly impact the organization's operations, and even its survivability. Example guidance on the application of ASVS Level 3 is provided below. An application achieves ASVS Level 3 (or Advanced) if it adequately defends against advanced application security vulnerabilities and also demonstrates principles of good security design. -An application at ASVS Level 3 requires more in depth analysis or architecture, coding, and testing than all the other levels. A secure application is modularized in a meaningful way (to facilitate resiliency, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), non-repudiation, authorization, and auditing (logging). +An application at ASVS Level 3 requires more in depth analysis of architecture, coding, and testing than all the other levels. A secure application is modularized in a meaningful way (to facilitate resiliency, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), non-repudiation, authorization, and auditing (logging). ## Applying ASVS in Practice Different threats have different motivations. Some industries have unique information and technology assets and domain specific regulatory compliance requirements. -Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. \ No newline at end of file +Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. + +## How to Reference ASVS Requirements + +Each requirement has an identifier in the format `.
.` where each element is a number, for example: `1.11.3`. +- The `` value corresponds to the chapter from which the requirement comes, for example: all `1.#.#` requirements are from the `Architecture` chapter. +- The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architectural Requirements` section of the `Architecture` chapter. +- The `` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.2 of this standard is: + +> 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. + +The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v4.0.2-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.2. (This could be summarized as `v-`.) + +Note: The `v` preceding the version portion is to be lower case. + +If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. + +ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. diff --git a/4.0/en/0x10-V1-Architecture.md b/4.0/en/0x10-V1-Architecture.md index 542fe68df7..378df182dd 100644 --- a/4.0/en/0x10-V1-Architecture.md +++ b/4.0/en/0x10-V1-Architecture.md @@ -4,7 +4,7 @@ Security architecture has almost become a lost art in many organizations. The days of the enterprise architect have passed in the age of DevSecOps. The application security field must catch up and adopt agile security principles while re-introducing leading security architecture principles to software practitioners. Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single "correct" answer. All too often, security is seen as inflexible and demanding that developers fix code in a particular way, when the developers may know a much better way to solve the problem. There is no single, simple solution for architecture, and to pretend otherwise is a disservice to the software engineering field. -A specific implementation of a web application is likely to be revised continuously throughout its lifetime, but the overall architecture will likely rarely change but evolve slowly. Security architecture is identical - we need authentication today, we will require authentication tomorrow, and we will need it five years from now. If we make sound decisions today, we can save a lot of effort, time, and money if we select and re-use architecturally compliant solutions. For example, a decade ago, multifactor authentication was rarely implemented. +A specific implementation of a web application is likely to be revised continuously throughout its lifetime, but the overall architecture will likely rarely change but evolve slowly. Security architecture is identical - we need authentication today, we will require authentication tomorrow, and we will need it five years from now. If we make sound decisions today, we can save a lot of effort, time, and money if we select and re-use architecturally compliant solutions. For example, a decade ago, multi-factor authentication was rarely implemented. If developers had invested in a single, secure identity provider model, such as SAML federated identity, the identity provider could be updated to incorporate new requirements such as NIST 800-63 compliance, while not changing the interfaces of the original application. If many applications shared the same security architecture and thus that same component, they all benefit from this upgrade at once. However, SAML will not always remain as the best or most suitable authentication solution - it might need to be swapped out for other solutions as requirements change. Changes like this are either complicated, so costly as to necessitate a complete re-write, or outright impossible without security architecture. @@ -14,12 +14,12 @@ In this chapter, the ASVS covers off the primary aspects of any sound security a | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **1.1.1** | Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | | +| **1.1.1** | Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | | **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. | | ✓ | ✓ | 1053 | | **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" | | ✓ | ✓ | 1110 | | **1.1.4** | Verify documentation and justification of all the application's trust boundaries, components, and significant data flows. | | ✓ | ✓ | 1059 | -| **1.1.5** | Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 1059 | -| **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. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 637 | +| **1.1.5** | Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 1059 | +| **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. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 637 | | **1.1.7** | Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. | | ✓ | ✓ | 637 | ## V1.2 Authentication Architectural Requirements @@ -28,8 +28,8 @@ When designing authentication, it doesn't matter if you have strong hardware ena | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **1.2.1** | Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 250 | -| **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. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 306 | +| **1.2.1** | Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 250 | +| **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. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 306 | | **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. | | ✓ | ✓ | 306 | | **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. | | ✓ | ✓ | 306 | @@ -44,19 +44,21 @@ This is a placeholder for future 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. | | ✓ | ✓ | 602 | | **1.4.2** | Verify that the chosen access control solution is flexible enough to meet the application's needs. | | ✓ | ✓ | 284 | | **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. | | ✓ | ✓ | 272 | -| **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. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 284 | -| **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. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 275 | +| **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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 284 | +| **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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 275 | ## V1.5 Input and Output Architectural Requirements -In 4.0, we have moved away from the term "server-side" as a loaded trust boundary term. The trust boundary is still concerning - making decisions on untrusted browsers or client devices is bypassable. However, in mainstream architectural deployments today, the trust enforcement point has dramatically changed. Therefore, where the term "trusted service layer" is used in the ASVS, we mean any trusted enforcement point, regardless of location, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. +In 4.0, we have moved away from the term "server-side" as a loaded trust boundary term. The trust boundary is still concerning - making decisions on untrusted browsers or client devices is bypassable. However, in mainstream architectural deployments today, the trust enforcement point has dramatically changed. Therefore, where the term "trusted service layer" is used in the ASVS, we mean any trusted enforcement point, regardless of location, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. + +The "untrusted client" term here refers to client-side technologies that render the presentation layer, commonly refered to as 'front-end' technologies. The term "serialization" here not only refers to sending data over the wire like an array of values or taking and reading a JSON structure, but also passing complex objects which can contain logic. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **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. | | ✓ | ✓ | 1029 | | **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. | | ✓ | ✓ | 502 | -| **1.5.3** | Verify that input validation is enforced on a trusted service layer. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 602 | -| **1.5.4** | Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 116 | +| **1.5.3** | Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 602 | +| **1.5.4** | Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 116 | ## V1.6 Cryptographic Architectural Requirements @@ -69,14 +71,14 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi | **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. | | ✓ | ✓ | 320 | | **1.6.2** | Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives. | | ✓ | ✓ | 320 | | **1.6.3** | Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data. | | ✓ | ✓ | 320 | -| **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. | | ✓ | ✓ | 320 | +| **1.6.4** | Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data. | | ✓ | ✓ | 320 | ## V1.7 Errors, Logging and Auditing Architectural Requirements | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **1.7.1** | Verify that a common logging format and approach is used across the system. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 1009 | -| **1.7.2** | Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | | +| **1.7.1** | Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 1009 | +| **1.7.2** | Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | ## V1.8 Data Protection and Privacy Architectural Requirements @@ -89,7 +91,7 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **1.9.1** | Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 319 | +| **1.9.1** | Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 319 | | **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. | | ✓ | ✓ | 295 | ## V1.10 Malicious Software Architectural Requirements @@ -111,7 +113,7 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.12.1** | Verify that user-uploaded files are stored outside of the web root. | | ✓ | ✓ | 552 | -| **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. | | ✓ | ✓ | 646 | +| **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 (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file. | | ✓ | ✓ | 646 | ## V1.13 API Architectural Requirements @@ -122,19 +124,19 @@ This is a placeholder for future architectural requirements. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.14.1** | Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms. | | ✓ | ✓ | 923 | -| **1.14.2** | Verify that if deploying binaries to untrusted devices makes use of binary signatures, trusted connections, and verified endpoints. | | ✓ | ✓ | 494 | +| **1.14.2** | Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices. | | ✓ | ✓ | 494 | | **1.14.3** | Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions. | | ✓ | ✓ | 1104 | | **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. | | ✓ | ✓ | | -| **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. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 265 | +| **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. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 | | **1.14.6** | Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | | ✓ | ✓ | 477 | ## References For more information, see also: -* [OWASP Threat Modeling Cheat Sheet](https://www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet) -* [OWASP Attack Surface Analysis Cheat Sheet](https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet) -* [OWASP Threat modeling](https://www.owasp.org/index.php/Application_Threat_Modeling) -* [OWASP Secure SDLC Cheat Sheet](https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet) +* [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) +* [OWASP Attack Surface Analysis Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) +* [OWASP Threat modeling](https://owasp.org/www-community/Application_Threat_Modeling) +* [OWASP Software Assurance Maturity Model Project](https://owasp.org/www-project-samm/) * [Microsoft SDL](https://www.microsoft.com/en-us/sdl/) -* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final) +* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) diff --git a/4.0/en/0x11-V2-Authentication.md b/4.0/en/0x11-V2-Authentication.md index b477ce502c..d2378f4bc1 100644 --- a/4.0/en/0x11-V2-Authentication.md +++ b/4.0/en/0x11-V2-Authentication.md @@ -4,13 +4,13 @@ Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords. -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. For example, NIST 800-63 considers usernames and knowledge based authentication (KBA) as public information, SMS and email notifications as ["restricted" authenticator types](https://pages.nist.gov/800-63-FAQ/#q-b1) , and passwords as pre-breached. 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. +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. For example, NIST 800-63 considers usernames and Knowledge Based Authentication (KBA) as public information, SMS and email notifications as ["restricted" authenticator types](https://pages.nist.gov/800-63-FAQ/#q-b1) , and passwords as pre-breached. 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. ## NIST 800-63 - Modern, evidence-based authentication standard -NIST 800-63b is a modern, evidence-based standard, and represents the best advice available, regardless of applicability. The standard is helpful for all organizations all over the world but is particularly relevant to US agencies and those dealing with US agencies. +[NIST 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.html) is a modern, evidence-based standard, and represents the best advice available, regardless of applicability. The standard is helpful for all organizations all over the world but is particularly relevant to US agencies and those dealing with US agencies. NIST 800-63 terminology can be a little confusing at first, especially if you're only used to username + password authentication. Advancements in modern authentication are necessary, so we have to introduce terminology that will become commonplace in the future, but we do understand the difficulty in understanding until the industry settles on these new terms. We have provided a glossary at the end of this chapter to assist. We have rephrased many requirements to satisfy the intent of the requirement, rather than the letter of the requirement. For example, the ASVS uses the term "password" when NIST uses "memorized secret" throughout this standard. @@ -18,7 +18,7 @@ ASVS V2 Authentication, V3 Session Management, and to a lesser extent, V4 Access ### Selecting an appropriate NIST AAL Level -The Application Security Verification Standard has tried to map ASVS L1 to NIST AAL1 requirements, L2 to AAL2, and L3 to AAL3. However, the approach of ASVS Level 1 as "essential" controls may not necessarily be the correct AAL level to verify an application or API. For example, if the application is a Level 3 application or has regulatory requirements to be AAL3, Level 3 should be chosen in Sections V2 and V3 Session Management. The choice of NIST compliant authentication assertion level (AAL) should be performed as per NIST 800-63b guidelines as set out in *Selecting AAL* in [NIST 800-63b Section 6.2](https://pages.nist.gov/800-63-3/sp800-63-3.html#AAL_CYOA). +The Application Security Verification Standard has tried to map ASVS L1 to NIST AAL1 requirements, L2 to AAL2, and L3 to AAL3. However, the approach of ASVS Level 1 as "essential" controls may not necessarily be the correct AAL level to verify an application or API. For example, if the application is a Level 3 application or has regulatory requirements to be AAL3, Level 3 should be chosen in Sections V2 and V3 Session Management. The choice of NIST compliant Authentication Assertion Level (AAL) should be performed as per NIST 800-63b guidelines as set out in *Selecting AAL* in [NIST 800-63b Section 6.2](https://pages.nist.gov/800-63-3/sp800-63-3.html#AAL_CYOA). ## Legend @@ -32,28 +32,28 @@ Applications can always exceed the current level's requirements, especially if m ## V2.1 Password Security Requirements -Passwords, called "Memorized Secrets" by NIST 800-63, include passwords, PINs, unlock patterns, pick the correct kitten or another image element, and passphrases. They are generally considered "something you know", and often used as single factor authenticators. There are significant challenges to the continued use of single-factor authentication, including billions of valid usernames and passwords disclosed on the Internet, default or weak passwords, rainbow tables and ordered dictionaries of the most common passwords. +Passwords, called "Memorized Secrets" by NIST 800-63, include passwords, PINs, unlock patterns, pick the correct kitten or another image element, and passphrases. They are generally considered "something you know", and often used as single-factor authenticators. There are significant challenges to the continued use of single-factor authentication, including billions of valid usernames and passwords disclosed on the Internet, default or weak passwords, rainbow tables and ordered dictionaries of the most common passwords. -Applications should strongly encourage users to enrol in multi-factor authentication, and should allow users to re-use tokens they already possess, such as FIDO or U2F tokens, or link to a credential service provider that provides multi-factor authentication. +Applications should strongly encourage users to enroll in multi-factor authentication, and should allow users to re-use tokens they already possess, such as FIDO or U2F tokens, or link to a credential service provider that provides multi-factor authentication. -Credential service providers (CSPs) provide federated identity for users. Users will often have more than one identity with multiple CSPs, such as an enterprise identity using Azure AD, Okta, Ping Identity or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name a just few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the CSP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throw away identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. +Credential Service Providers (CSPs) provide federated identity for users. Users will often have more than one identity with multiple CSPs, such as an enterprise identity using Azure AD, Okta, Ping Identity or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name a just few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the CSP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throw away identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **2.1.1** | Verify that user set passwords are at least 12 characters in length. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -| **2.1.2** | Verify that passwords 64 characters or longer are permitted. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -| **2.1.3** | Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -| **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. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **2.1.1** | Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **2.1.2** | Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **2.1.3** | Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **2.1.4** | Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | | **2.1.5** | Verify users can change their password. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 | | **2.1.6** | Verify that password change functionality requires the user's current and new password. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | | **2.1.8** | Verify that a password strength meter is provided to help users set a stronger password. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | | **2.1.10** | Verify that there are no periodic credential rotation or password history requirements. | ✓ | ✓ | ✓ | 263 | 5.1.1.2 | | **2.1.11** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -| **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. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | +| **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 built-in functionality. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 | -Note: The goal of allowing the user to view their password or see the last character temporarily is to improve the usability of credential entry, particularly around the use of longer passwords, passphrases, and password managers. Another reason for including the requirement is to deter or prevent test reports unnecessarily requiring organizations to override native platform password field behavior to remove this modern user-friendly security experience. +Note: The goal of allowing the user to view their password or see the last character temporarily is to improve the usability of credential entry, particularly around the use of longer passwords, passphrases, and password managers. Another reason for including the requirement is to deter or prevent test reports unnecessarily requiring organizations to override built-in platform password field behavior to remove this modern user-friendly security experience. ## V2.2 General Authenticator Requirements @@ -61,14 +61,14 @@ Authenticator agility is essential to future-proof applications. Refactor applic NIST considers email and SMS as ["restricted" authenticator types](https://pages.nist.gov/800-63-FAQ/#q-b1), and they are likely to be removed from NIST 800-63 and thus the ASVS at some point the future. Applications should plan a roadmap that does not require the use of email or SMS. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **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. | ✓ | ✓ | ✓ | 307 | 5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2 | | **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. | ✓ | ✓ | ✓ | 304 | 5.2.10 | | **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. | ✓ | ✓ | ✓ | 620 | | | **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. | | | ✓ | 308 | 5.2.5 | -| **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. | | | ✓ | 319 | 5.2.6 | -| **2.2.6** | Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes. | | | ✓ | 308 | 5.2.8 | +| **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. | | | ✓ | 319 | 5.2.6 | +| **2.2.6** | Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes. | | | ✓ | 308 | 5.2.8 | | **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. | | | ✓ | 308 | 5.2.9 | ## V2.3 Authenticator Lifecycle Requirements @@ -77,7 +77,7 @@ Authenticators are passwords, soft tokens, hardware tokens, and biometric device Note: Passwords are not to have a maximum lifetime or be subject to password rotation. Passwords should be checked for being breached, not regularly replaced. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **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. | ✓ | ✓ | ✓ | 330 | 5.1.1.2 / A.3 | | **2.3.2** | Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens. | | ✓ | ✓ | 308 | 6.1.3 | @@ -91,33 +91,33 @@ The list of approved one-way key derivation functions is detailed in NIST 800-63 This section cannot be penetration tested, so controls are not marked as L1. However, this section is of vital importance to the security of credentials if they are stolen, so if forking the ASVS for an architecture or coding guideline or source code review checklist, please place these controls back to L1 in your private version. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **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 one-way 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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | +| **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 one-way 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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | +| **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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | +| **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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | +| **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. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 | | **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). | | ✓ | ✓ | 916 | 5.1.1.2 | Where US standards are mentioned, a regional or local standard can be used in place of or in addition to the US standard as required. ## V2.5 Credential Recovery Requirements -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **2.5.1** | Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | +| **2.5.1** | Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | | **2.5.2** | Verify password hints or knowledge-based authentication (so-called "secret questions") are not present. | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | -| **2.5.3** | Verify password credential recovery does not reveal the current password in any way. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | +| **2.5.3** | Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | | **2.5.4** | Verify shared or default accounts are not present (e.g. "root", "admin", or "sa"). | ✓ | ✓ | ✓ | 16 | 5.1.1.2 / A.3 | | **2.5.5** | Verify that if an authentication factor is changed or replaced, that the user is notified of this event. | ✓ | ✓ | ✓ | 304 | 6.1.2.3 | -| **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. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | +| **2.5.6** | Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | | **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. | | ✓ | ✓ | 308 | 6.1.2.3 | ## V2.6 Look-up Secret Verifier Requirements Look up secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. These are distributed securely to users. These lookup codes are used once, and once all used, the lookup secret list is discarded. This type of authenticator is considered "something you have". -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **2.6.1** | Verify that lookup secrets can be used only once. | | ✓ | ✓ | 308 | 5.1.2.2 | | **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. | | ✓ | ✓ | 330 | 5.1.2.2 | @@ -133,7 +133,7 @@ The ASVS assumes that only a few developers will be developing new out of band a Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently "restricted" by NIST and should be deprecated in favor of push notifications or similar. If you need to use telephone or SMS out of band authentication, please see § 5.1.3.3. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **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. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | | **2.7.2** | Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | @@ -142,29 +142,29 @@ Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PST | **2.7.5** | Verify that the out of band verifier retains only a hashed version of the authentication code. | | ✓ | ✓ | 256 | 5.1.3.2 | | **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). | | ✓ | ✓ | 310 | 5.1.3.2 | -## V2.8 Single or Multi Factor One Time Verifier Requirements +## V2.8 Single or Multi-factor One Time Verifier Requirements -Single factor one time passwords (OTPs) are physical or soft tokens that display a continually changing pseudo-random one time challenge. These devices make phishing (impersonation) difficult, but not impossible. This type of authenticator is considered "something you have". Multi-factor tokens are similar to single factor OTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing or some additional value (such as transaction signing calculators) to be entered to create the final OTP. +Single-factor One-time Passwords (OTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. These devices make phishing (impersonation) difficult, but not impossible. This type of authenticator is considered "something you have". Multi-factor tokens are similar to single-factor OTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing or some additional value (such as transaction signing calculators) to be entered to create the final OTP. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **2.8.1** | Verify that time-based OTPs have a defined lifetime before expiring. | ✓ | ✓ | ✓ | 613 | 5.1.4.2 / 5.1.5.2 | | **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. | | ✓ | ✓ | 320 | 5.1.4.2 / 5.1.5.2| -| **2.8.3** | Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. | | ✓ | ✓ | 326 | 5.1.4.2 / 5.1.5.2 | +| **2.8.3** | Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs. | | ✓ | ✓ | 326 | 5.1.4.2 / 5.1.5.2 | | **2.8.4** | Verify that time-based OTP can be used only once within the validity period. | | ✓ | ✓ | 287 | 5.1.4.2 / 5.1.5.2 | -| **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. | | ✓ | ✓ | 287 | 5.1.5.2 | -| **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. | | ✓ | ✓ | 613 | 5.2.1 | +| **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. | | ✓ | ✓ | 287 | 5.1.5.2 | +| **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. | | ✓ | ✓ | 613 | 5.2.1 | | **2.8.7** | Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know. | | o | ✓ | 308 | 5.2.3 | ## V2.9 Cryptographic Software and Devices Verifier Requirements Cryptographic security keys are smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. Verifiers send a challenge nonce to the cryptographic devices or software, and the device or software calculates a response based upon a securely stored cryptographic key. -The requirements for single factor cryptographic devices and software, and multi-factor cryptographic devices and software are the same, as verification of the cryptographic authenticator proves possession of the authentication factor. +The requirements for single-factor cryptographic devices and software, and multi-factor cryptographic devices and software are the same, as verification of the cryptographic authenticator proves possession of the authentication factor. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **2.9.1** | Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage. | | ✓ | ✓ | 320 | 5.1.7.2 | +| **2.9.1** | Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage. | | ✓ | ✓ | 320 | 5.1.7.2 | | **2.9.2** | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | | ✓ | ✓ | 330 | 5.1.7.2 | | **2.9.3** | Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. | | ✓ | ✓ | 327 | 5.1.7.2 | @@ -172,12 +172,12 @@ The requirements for single factor cryptographic devices and software, and multi This section is not penetration testable, so does not have any L1 requirements. However, if used in an architecture, coding or secure code review, please assume that software (just as Java Key Store) is the minimum requirement at L1. Clear text storage of secrets is not acceptable under any circumstances. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **2.10.1** | Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts. | | OS assisted | HSM | 287 | 5.1.1.1 | -| **2.10.2** | Verify that if passwords are required, the credentials are not a default account. | | OS assisted | HSM | 255 | 5.1.1.1 | +| **2.10.1** | Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access. | | OS assisted | HSM | 287 | 5.1.1.1 | +| **2.10.2** | Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation). | | OS assisted | HSM | 255 | 5.1.1.1 | | **2.10.3** | Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access. | | OS assisted | HSM | 522 | 5.1.1.1 | -| **2.10.4** | Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware trusted platform module (TPM), or a hardware security module (L3) is recommended for password storage. | | OS assisted | HSM | 798 | | +| **2.10.4** | Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage. | | OS assisted | HSM | 798 | | ## Additional US Agency Requirements @@ -193,8 +193,8 @@ We strongly urge US government agencies to review and implement NIST 800-63 in i | Authenticator | Code that authenticates a password, token, MFA, federated assertion, and so on. | | Verifier | "An entity that verifies the claimant's identity by verifying the claimant's possession and control of one or two authenticators using an authentication protocol. To do this, the verifier may also need to validate credentials that link the authenticator(s) to the subscriber's identifier and check their status" | | OTP | One-time password | -| SFA | Single factor authenticators, such as something you know (memorized secrets, passwords, passphrases, PINs), something you are (biometrics, fingerprint, face scans), or something you have (OTP tokens, a cryptographic device such as a smart card), | -| MFA | Multi factor authenticator, which includes two or more single factors | +| SFA | Single-factor authenticators, such as something you know (memorized secrets, passwords, passphrases, PINs), something you are (biometrics, fingerprint, face scans), or something you have (OTP tokens, a cryptographic device such as a smart card), | +| MFA | Multi-factor authentication, which includes two or more single factors | ## References @@ -205,7 +205,7 @@ For more information, see also: * [NIST 800-63 B - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) * [NIST 800-63 C - Federation and Assertions](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63c.pdf) * [NIST 800-63 FAQ](https://pages.nist.gov/800-63-FAQ/) -* [OWASP Testing Guide 4.0: Testing for Authentication](https://www.owasp.org/index.php/Testing_for_authentication) -* [OWASP Cheat Sheet - Password storage](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) -* [OWASP Cheat Sheet - Forgot password](https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet) -* [OWASP Cheat Sheet - Choosing and using security questions](https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet) +* [OWASP Testing Guide 4.0: Testing for Authentication](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/04-Authentication_Testing/README.html) +* [OWASP Cheat Sheet - Password storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet - Forgot password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) +* [OWASP Cheat Sheet - Choosing and using security questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) diff --git a/4.0/en/0x12-V3-Session-management.md b/4.0/en/0x12-V3-Session-management.md index 70debbf4f0..7ae4ac3568 100644 --- a/4.0/en/0x12-V3-Session-management.md +++ b/4.0/en/0x12-V3-Session-management.md @@ -9,24 +9,24 @@ Ensure that a verified application satisfies the following high-level session ma * 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. -As previously noted, 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. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory [NIST 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.htmlx) requirements. +As previously noted, 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. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory [NIST 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.html) requirements. ## Security Verification Requirements ## V3.1 Fundamental Session Management Requirements -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.1.1** | Verify the application never reveals session tokens in URL parameters or error messages. | ✓ | ✓ | ✓ | 598 | | +| **3.1.1** | Verify the application never reveals session tokens in URL parameters. | ✓ | ✓ | ✓ | 598 | | ## V3.2 Session Binding Requirements -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.2.1** | Verify the application generates a new session token on user authentication. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 384 | 7.1 | -| **3.2.2** | Verify that session tokens possess at least 64 bits of entropy. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 331 | 7.1 | +| **3.2.1** | Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 384 | 7.1 | +| **3.2.2** | Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 331 | 7.1 | | **3.2.3** | Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage. | ✓ | ✓ | ✓ | 539 | 7.1 | -| **3.2.4** | Verify that session token are generated using approved cryptographic algorithms. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 331 | 7.1 | +| **3.2.4** | Verify that session token are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 331 | 7.1 | TLS or another secure transport channel is mandatory for session management. This is covered off in the Communications Security chapter. @@ -36,41 +36,41 @@ Session timeouts have been aligned with NIST 800-63, which permits much longer s L1 in this context is IAL1/AAL1, L2 is IAL2/AAL3, L3 is IAL3/AAL3. For IAL2/AAL2 and IAL3/AAL3, the shorter idle timeout is, the lower bound of idle times for being logged out or re-authenticated to resume the session. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.3.1** | Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 613 | 7.1 | -| **3.3.2** | If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | 30 days | 12 hours or 30 minutes of inactivity, 2FA optional | 12 hours or 15 minutes of inactivity, with 2FA | 613 | 7.2 | -| **3.3.3** | Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties. | | ✓ | ✓ | 613 | | -| **3.3.4** | Verify that users are able to view and log out of any or all currently active sessions and devices. | | ✓ | ✓ | 613 | 7.1 | +| **3.3.1** | Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 613 | 7.1 | +| **3.3.2** | If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | 30 days | 12 hours or 30 minutes of inactivity, 2FA optional | 12 hours or 15 minutes of inactivity, with 2FA | 613 | 7.2 | +| **3.3.3** | Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties. | | ✓ | ✓ | 613 | | +| **3.3.4** | Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices. | | ✓ | ✓ | 613 | 7.1 | ## V3.4 Cookie-based Session Management -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.4.1** | Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 614 | 7.1.1 | -| **3.4.2** | Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 1004 | 7.1.1 | -| **3.4.3** | Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 | +| **3.4.1** | Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 614 | 7.1.1 | +| **3.4.2** | Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 1004 | 7.1.1 | +| **3.4.3** | Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 | | **3.4.4** | Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality. | ✓ | ✓ | ✓ | 16 | 7.1.1 | -| **3.4.5** | Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 | +| **3.4.5** | Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 | ## V3.5 Token-based Session Management Token-based session management includes JWT, OAuth, SAML, and API keys. Of these, API keys are known to be weak and should not be used in new code. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.5.1** | Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to terminate trust relationships with linked applications. | | ✓ | ✓ | 290 | 7.1.2 | +| **3.5.1** | Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. | | ✓ | ✓ | 290 | 7.1.2 | | **3.5.2** | Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations. | | ✓ | ✓ | 798 | | | **3.5.3** | Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks. | | ✓ | ✓ | 345 | | ## V3.6 Re-authentication from a Federation or Assertion -This section relates to those writing relying party (RP) or credential service provider (CSP) code. If relying on code implementing these features, ensure that these issues are handled correctly. +This section relates to those writing Relying Party (RP) or Credential Service Provider (CSP) code. If relying on code implementing these features, ensure that these issues are handled correctly. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.6.1** | Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a session within that period. | | | ✓ | 613 | 7.2.1 | -| **3.6.2** | Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user. | | | ✓ | 613| 7.2.1 | +| **3.6.1** | Verify that relying parties specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the subscriber if they haven't used a session within that period. | | | ✓ | 613 | 7.2.1 | +| **3.6.2** | Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user. | | | ✓ | 613| 7.2.1 | ## V3.7 Defenses Against Session Management Exploits @@ -82,14 +82,14 @@ In early 2018, several financial institutions were compromised using what the at Attackers start a half-open attack by attempting to lock, reset, or recover a credential. A popular session management design pattern re-uses user profile session objects/models between unauthenticated, half-authenticated (password resets, forgot username), and fully authenticated code. This design pattern populates a valid session object or token containing the victim's profile, including password hashes and roles. If access control checks in controllers or routers does not correctly verify that the user is fully logged in, the attacker will be able to act as the user. Attacks could include changing the user's password to a known value, update the email address to perform a valid password reset, disable multi-factor authentication or enroll a new MFA device, reveal or change API keys, and so on. -| # | Description | L1 | L2 | L3 | CWE | NIST § | +| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | -| **3.7.1** | Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. | ✓ | ✓ | ✓ | 778 | | +| **3.7.1** | Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. | ✓ | ✓ | ✓ | 306 | | ## References For more information, see also: -* [OWASP Testing Guide 4.0: Session Management Testing](https://www.owasp.org/index.php/Testing_for_Session_Management) -* [OWASP Session Management Cheat Sheet](https://www.owasp.org/index.php/Session_Management_Cheat_Sheet) +* [OWASP Testing Guide 4.0: Session Management Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/06-Session_Management_Testing/README.html) +* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) * [Set-Cookie __Host- prefix details](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives) diff --git a/4.0/en/0x12-V4-Access-Control.md b/4.0/en/0x12-V4-Access-Control.md index f434f8d67e..5d9e39f641 100644 --- a/4.0/en/0x12-V4-Access-Control.md +++ b/4.0/en/0x12-V4-Access-Control.md @@ -16,15 +16,15 @@ Authorization is the concept of allowing access to resources only to those permi | :---: | :--- | :---: | :---:| :---: | :---: | | **4.1.1** | Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed. | ✓ | ✓ | ✓ | 602 | | **4.1.2** | Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized. | ✓ | ✓ | ✓ | 639 | -| **4.1.3** | Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 285 | -| **4.1.4** | Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 276 | -| **4.1.5** | Verify that access controls fail securely including when an exception occurs. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 285 | +| **4.1.3** | Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 285 | +| **4.1.4** | Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 276 | +| **4.1.5** | Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 285 | ## V4.2 Operation Level Access Control | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **4.2.1** | Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records. | ✓ | ✓ | ✓ | 639 | +| **4.2.1** | Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records. | ✓ | ✓ | ✓ | 639 | | **4.2.2** | Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality. | ✓ | ✓ | ✓ | 352 | ## V4.3 Other Access Control Considerations @@ -39,7 +39,7 @@ Authorization is the concept of allowing access to resources only to those permi For more information, see also: -* [OWASP Testing Guide 4.0: Authorization](https://www.owasp.org/index.php/Testing_for_Authorization) -* [OWASP Cheat Sheet: Access Control](https://www.owasp.org/index.php/Access_Control_Cheat_Sheet) -* [OWASP CSRF Cheat Sheet](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet) -* [OWASP REST Cheat Sheet](https://www.owasp.org/index.php/REST_Security_Cheat_Sheet) +* [OWASP Testing Guide 4.0: Authorization](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/05-Authorization_Testing/README.html) +* [OWASP Cheat Sheet: Access Control](https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html) +* [OWASP CSRF Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) +* [OWASP REST Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) diff --git a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 513116f465..6a84ff6b27 100644 --- a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -14,45 +14,45 @@ With modern web application architecture, output encoding is more important than ## V5.1 Input Validation Requirements -Properly implemented input validation controls, using positive whitelisting and strong data typing, can eliminate more than 90% of all injection attacks. Length and range checks can reduce this further. Building in secure input validation is required during application architecture, design sprints, coding, and unit and integration testing. Although many of these items cannot be found in penetration tests, the results of not implementing them are usually found in V5.3 - Output encoding and Injection Prevention Requirements. Developers and secure code reviewers are recommended to treat this section as if L1 is required for all items to prevent injections. +Properly implemented input validation controls, using positive allow lists and strong data typing, can eliminate more than 90% of all injection attacks. Length and range checks can reduce this further. Building in secure input validation is required during application architecture, design sprints, coding, and unit and integration testing. Although many of these items cannot be found in penetration tests, the results of not implementing them are usually found in V5.3 - Output encoding and Injection Prevention Requirements. Developers and secure code reviewers are recommended to treat this section as if L1 is required for all items to prevent injections. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **5.1.1** | Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables). | ✓ | ✓ | ✓ | 235 | -| **5.1.2** | Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 915 | -| **5.1.3** | Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting). ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 20 | -| **5.1.4** | Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 20 | -| **5.1.5** | Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content. | ✓ | ✓ | ✓ | 601 | +| **5.1.2** | Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 915 | +| **5.1.3** | Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 | +| **5.1.4** | Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 | +| **5.1.5** | Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. | ✓ | ✓ | ✓ | 601 | ## V5.2 Sanitization and Sandboxing Requirements | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **5.2.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 116 | +| **5.2.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 | | **5.2.2** | Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length. | ✓ | ✓ | ✓ | 138 | | **5.2.3** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | ✓ | ✓ | ✓ | 147 | | **5.2.4** | Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | ✓ | ✓ | ✓ | 95 | | **5.2.5** | Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. | ✓ | ✓ | ✓ | 94 | -| **5.2.6** | Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports. | ✓ | ✓ | ✓ | 918 | -| **5.2.7** | Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. | ✓ | ✓ | ✓ | 159 | +| **5.2.6** | Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. | ✓ | ✓ | ✓ | 918 | +| **5.2.7** | Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. | ✓ | ✓ | ✓ | 159 | | **5.2.8** | Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. | ✓ | ✓ | ✓ | 94 | -## V5.3 Output encoding and Injection Prevention Requirements +## V5.3 Output Encoding and Injection Prevention Requirements Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but used to render the output safe in the appropriate output context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **5.3.1** | Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 116 | -| **5.3.2** | Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 176 | -| **5.3.3** | Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 79 | -| **5.3.4** | Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 89 | -| **5.3.5** | Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 89 | -| **5.3.6** | Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 830 | -| **5.3.7** | Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 943 | -| **5.3.8** | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 78 | +| **5.3.1** | Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 | +| **5.3.2** | Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 176 | +| **5.3.3** | Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 79 | +| **5.3.4** | Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 89 | +| **5.3.5** | Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 89 | +| **5.3.6** | Verify that the application protects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, Content Security Policy (CSP) bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 830 | +| **5.3.7** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 90 | +| **5.3.8** | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 78 | | **5.3.9** | Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks. | ✓ | ✓ | ✓ | 829 | -| **5.3.10** | Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 643 | +| **5.3.10** | Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 643 | Note: Using parameterized queries or escaping SQL is not always sufficient; table and column names, ORDER BY and so on, cannot be escaped. The inclusion of escaped user-supplied data in these fields results in failed queries or SQL injection. @@ -72,8 +72,8 @@ The following requirements will only apply when the application uses a systems l | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **5.5.1** | Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 502 | -| **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. | ✓ | ✓ | ✓ | 611 | +| **5.5.1** | Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 502 | +| **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 XML eXternal Entity (XXE) attacks. | ✓ | ✓ | ✓ | 611 | | **5.5.3** | Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). | ✓ | ✓ | ✓ | 502 | | **5.5.4** | Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON. | ✓ | ✓ | ✓ | 95 | @@ -81,17 +81,17 @@ The following requirements will only apply when the application uses a systems l For more information, see also: -* [OWASP Testing Guide 4.0: Input Validation Testing](https://www.owasp.org/index.php/Testing_for_Input_Validation) -* [OWASP Cheat Sheet: Input Validation](https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet) -* [OWASP Testing Guide 4.0: Testing for HTTP Parameter Pollution](https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OTG-INPVAL-004%29) -* [OWASP LDAP Injection Cheat Sheet](https://www.owasp.org/index.php/LDAP_Injection_Prevention_Cheat_Sheet) -* [OWASP Testing Guide 4.0: Client Side Testing](https://www.owasp.org/index.php/Client_Side_Testing) -* [OWASP Cross Site Scripting Prevention Cheat Sheet](https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet) -* [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet) -* [OWASP Java Encoding Project](https://www.owasp.org/index.php/OWASP_Java_Encoder_Project) -* [OWASP Mass Assignment Prevention Cheat Sheet](https://www.owasp.org/index.php/Mass_Assignment_Cheat_Sheet) +* [OWASP Testing Guide 4.0: Input Validation Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README.html) +* [OWASP Cheat Sheet: Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) +* [OWASP Testing Guide 4.0: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.html) +* [OWASP LDAP Injection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Testing Guide 4.0: Client Side Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client_Side_Testing/) +* [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) +* [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) +* [OWASP Java Encoding Project](https://owasp.org/owasp-java-encoder/) +* [OWASP Mass Assignment Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) * [DOMPurify - Client-side HTML Sanitization Library](https://github.com/cure53/DOMPurify) -* [XML External Entity (XXE) Prevention Cheat Sheet](https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet)) +* [XML External Entity (XXE) Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) For more information on auto-escaping, please see: @@ -105,5 +105,5 @@ For more information on auto-escaping, please see: For more information on deserialization, please see: -* [OWASP Deserialization Cheat Sheet](https://www.owasp.org/index.php/Deserialization_Cheat_Sheet) -* [OWASP Deserialization of Untrusted Data Guide](https://www.owasp.org/index.php/Deserialization_of_untrusted_data) +* [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) +* [OWASP Deserialization of Untrusted Data Guide](https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data) diff --git a/4.0/en/0x14-V6-Cryptography.md b/4.0/en/0x14-V6-Cryptography.md index 865fb6fe8b..9bf97a8255 100644 --- a/4.0/en/0x14-V6-Cryptography.md +++ b/4.0/en/0x14-V6-Cryptography.md @@ -14,7 +14,7 @@ The most important asset is the data processed, stored or transmitted by an appl | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **6.1.1** | Verify that regulated private data is stored encrypted while at rest, such as personally identifiable information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. | | ✓ | ✓ | 311 | +| **6.1.1** | Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. | | ✓ | ✓ | 311 | | **6.1.2** | Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records. | | ✓ | ✓ | 311 | | **6.1.3** | Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records. | | ✓ | ✓ | 311 | @@ -27,9 +27,9 @@ Although this section is not easily penetration tested, developers should consid | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **6.2.1** | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks. | ✓ | ✓ | ✓ | 310 | -| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 327 | +| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 327 | | **6.2.3** | Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice. | | ✓ | ✓ | 326 | -| **6.2.4** | Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 326 | +| **6.2.4** | Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 326 | | **6.2.5** | Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility. | | ✓ | ✓ | 326 | | **6.2.6** | Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used. | | ✓ | ✓ | 326 | | **6.2.7** | Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party. | | | ✓ | 326 | @@ -37,12 +37,12 @@ Although this section is not easily penetration tested, developers should consid ## V6.3 Random Values -True pseudo-random number generation (PRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. +True Pseudo-random Number Generation (PRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **6.3.1** | Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker. | | ✓ | ✓ | 338 | -| **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. | | ✓ | ✓ | 338 | +| **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. | | ✓ | ✓ | 338 | | **6.3.3** | Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. | | | ✓ | 338 | ## V6.4 Secret Management @@ -51,13 +51,13 @@ Although this section is not easily penetration tested, developers should consid | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **6.4.1** | Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 798 | -| **6.4.2** | Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 320 | +| **6.4.1** | Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 798 | +| **6.4.2** | Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 320 | ## References For more information, see also: -* [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://www.owasp.org/index.php/Testing_for_weak_Cryptography) -* [OWASP Cheat Sheet: Cryptographic Storage](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet) +* [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README.html) +* [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) * [FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) diff --git a/4.0/en/0x15-V7-Error-Logging.md b/4.0/en/0x15-V7-Error-Logging.md index a44a78f214..a014e32031 100644 --- a/4.0/en/0x15-V7-Error-Logging.md +++ b/4.0/en/0x15-V7-Error-Logging.md @@ -25,10 +25,10 @@ V7.1 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetrat | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **7.1.1** | Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 532 | -| **7.1.2** | Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 532 | -| **7.1.3** | Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 778 | -| **7.1.4** | Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 778 | +| **7.1.1** | Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 532 | +| **7.1.2** | Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 532 | +| **7.1.3** | Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 | +| **7.1.4** | Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 | ## V7.2 Log Processing Requirements @@ -41,7 +41,7 @@ V7.2 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetrat | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **7.2.1** | Verify that all authentication decisions are logged, without storing sensitive session identifiers or passwords. This should include requests with relevant metadata needed for security investigations. | | ✓ | ✓ | 778 | +| **7.2.1** | Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. | | ✓ | ✓ | 778 | | **7.2.2** | Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations. | | ✓ | ✓ | 285 | ## V7.3 Log Protection Requirements @@ -50,10 +50,10 @@ Logs that can be trivially modified or deleted are useless for investigations an | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **7.3.1** | Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 117 | -| **7.3.2** | Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 117 | -| **7.3.3** | Verify that security logs are protected from unauthorized access and modification. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 200 | -| **7.3.4** | Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | | +| **7.3.1** | Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 117 | +| **7.3.2** | Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 117 | +| **7.3.3** | Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 200 | +| **7.3.4** | Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | Note: Log encoding (7.3.1) is difficult to test and review using automated dynamic tools and penetration tests, but architects, developers, and source code reviewers should consider it an L1 requirement. @@ -63,9 +63,9 @@ The purpose of error handling is to allow the application to provide security re | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **7.4.1** | Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 210 | -| **7.4.2** | Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 544 | -| **7.4.3** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 460 | +| **7.4.1** | Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 210 | +| **7.4.2** | Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 544 | +| **7.4.3** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 431 | Note: Certain languages, such as Swift and Go - and through common design practice - many functional languages, do not support exceptions or last resort event handlers. In this case, architects and developers should use a pattern, language, or framework friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. @@ -73,4 +73,5 @@ Note: Certain languages, such as Swift and Go - and through common design practi For more information, see also: -* [OWASP Testing Guide 4.0 content: Testing for Error Handling](https://www.owasp.org/index.php/Testing_for_Error_Handling) +* [OWASP Testing Guide 4.0 content: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README.html) +* [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages) diff --git a/4.0/en/0x16-V8-Data-Protection.md b/4.0/en/0x16-V8-Data-Protection.md index d9d86caaed..4393dd1607 100644 --- a/4.0/en/0x16-V8-Data-Protection.md +++ b/4.0/en/0x16-V8-Data-Protection.md @@ -28,7 +28,7 @@ Ensure that a verified application satisfies the following high level data prote | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **8.2.1** | Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers. | ✓ | ✓ | ✓ | 525 | -| **8.2.2** | Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII. | ✓ | ✓ | ✓ | 922 | +| **8.2.2** | Verify that data stored in browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII. | ✓ | ✓ | ✓ | 922 | | **8.2.3** | Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. | ✓ | ✓ | ✓ | 922 | ## V8.3 Sensitive Private Data @@ -44,10 +44,10 @@ Note: Privacy regulations and laws, such as the Australian Privacy Principles AP | **8.3.1** | Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. | ✓ | ✓ | ✓ | 319 | | **8.3.2** | Verify that users have a method to remove or export their data on demand. | ✓ | ✓ | ✓ | 212 | | **8.3.3** | Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way. | ✓ | ✓ | ✓ | 285 | -| **8.3.4** | Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 200 | +| **8.3.4** | Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 200 | | **8.3.5** | Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. | | ✓ | ✓ | 532 | | **8.3.6** | Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data. | | ✓ | ✓ | 226 | -| **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. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 327 | +| **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. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 327 | | **8.3.8** | Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | | ✓ | ✓ | 285 | When considering data protection, a primary consideration should be around bulk extraction or modification or excessive usage. For example, many social media systems only allow users to add 100 new friends per day, but which system these requests came from is not important. A banking platform might wish to block more than 5 transactions per hour transferring more than 1000 euro of funds to external institutions. Each system's requirements are likely to be very different, so deciding on "abnormal" must consider the threat model and business risk. Important criteria are the ability to detect, deter, or preferably block such abnormal bulk actions. @@ -57,8 +57,8 @@ When considering data protection, a primary consideration should be around bulk For more information, see also: * [Consider using Security Headers website to check security and anti-caching headers](https://securityheaders.io) -* [OWASP Secure Headers project](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) -* [OWASP Privacy Risks Project](https://www.owasp.org/index.php/OWASP_Top_10_Privacy_Risks_Project) -* [OWASP User Privacy Protection Cheat Sheet](https://www.owasp.org/index.php/User_Privacy_Protection_Cheat_Sheet) +* [OWASP Secure Headers project](https://owasp.org/www-project-secure-headers/) +* [OWASP Privacy Risks Project](https://owasp.org/www-project-top-10-privacy-risks/) +* [OWASP User Privacy Protection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) * [European Union General Data Protection Regulation (GDPR) overview](https://edps.europa.eu/data-protection_en) * [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en) diff --git a/4.0/en/0x17-V9-Communications.md b/4.0/en/0x17-V9-Communications.md index 52fb555fbc..40001e9378 100644 --- a/4.0/en/0x17-V9-Communications.md +++ b/4.0/en/0x17-V9-Communications.md @@ -11,13 +11,13 @@ Ensure that a verified application satisfies the following high level requiremen Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective. -## V9.1 Communications Security Requirements +## V9.1 Client Communications Security Requirements All client communications should only take place over encrypted communication paths. In particular, the use of TLS 1.2 or later is essentially all but required by modern browsers and search engines. Configuration should be regularly reviewed using online tools to ensure that the latest leading practices are in place. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **9.1.1** | Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 319 | +| **9.1.1** | Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 319 | | **9.1.2** | Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred. | ✓ | ✓ | ✓ | 326 | | **9.1.3** | Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite. | ✓ | ✓ | ✓ | 326 | @@ -37,5 +37,6 @@ Server communications are more than just HTTP. Secure connections to and from ot For more information, see also: -* [OWASP – TLS Cheat Sheet](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet) -* Notes on “Approved modes of TLS”. In the past, the ASVS referred to the US standard FIPS 140-2, but as a global standard, applying US standards can be difficult, contradictory, or confusing to apply. A better method of achieving compliance with 9.1.3 would be to review guides such as [Mozilla's Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS) or [generate known good configurations](https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known TLS evaluation tools, such as sslyze, various vulnerability scanners or trusted TLS online assessment services to obtain a desired level of security. In general, we see non-compliance for this section being the use of outdated or insecure ciphers and algorithms, the lack of perfect forward secrecy, outdated or insecure SSL protocols, weak preferred ciphers, and so on. +* [OWASP – TLS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [OWASP - Pinning Guide](https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning) +* Notes on “Approved modes of TLS”. In the past, the ASVS referred to the US standard FIPS 140-2, but as a global standard, applying US standards can be difficult, contradictory, or confusing to apply. A better method of achieving compliance with 9.1.3 would be to review guides such as [Mozilla's Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS) or [generate known good configurations](https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known TLS evaluation tools, such as sslyze, various vulnerability scanners or trusted TLS online assessment services to obtain a desired level of security. In general, we see non-compliance for this section being the use of outdated or insecure ciphers and algorithms, the lack of perfect forward secrecy, outdated or insecure SSL protocols, weak preferred ciphers, and so on. diff --git a/4.0/en/0x18-V10-Malicious.md b/4.0/en/0x18-V10-Malicious.md index 7b10861a30..b3a4d5264d 100644 --- a/4.0/en/0x18-V10-Malicious.md +++ b/4.0/en/0x18-V10-Malicious.md @@ -32,23 +32,23 @@ Complying with this section is not possible without complete access to source co | **10.2.1** | Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data. | | ✓ | ✓ | 359 | | **10.2.2** | Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location. | | ✓ | ✓ | 272 | | **10.2.3** | Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. | | | ✓ | 507 | -| **10.2.4** | Verify that the application source code and third party libraries does not contain time bombs by searching for date and time related functions. | | | ✓ | 511 | -| **10.2.5** | Verify that the application source code and third party libraries does not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | | | ✓ | 511 | +| **10.2.4** | Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions. | | | ✓ | 511 | +| **10.2.5** | Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | | | ✓ | 511 | | **10.2.6** | Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality. | | | ✓ | 507 | ## V10.3 Deployed Application Integrity Controls -Once an application is deployed, malicious code can still be inserted. Applications need to protect themselves against common attacks, such as executing unsigned code from untrusted sources and sub-domain takeovers. +Once an application is deployed, malicious code can still be inserted. Applications need to protect themselves against common attacks, such as executing unsigned code from untrusted sources and subdomain takeovers. Complying with this section is likely to be operational and continuous. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **10.3.1** | Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update. | ✓ | ✓ | ✓ | 16 | -| **10.3.2** | Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. | ✓ | ✓ | ✓ | 353 | -| **10.3.3** | Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change. | ✓ | ✓ | ✓ | 350 | +| **10.3.2** | Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. | ✓ | ✓ | ✓ | 353 | +| **10.3.3** | Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change. | ✓ | ✓ | ✓ | 350 | ## References -* [Hostile Sub-Domain Takeover, Detectify Labs](https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/) +* [Hostile Subdomain Takeover, Detectify Labs](https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/) * [Hijacking of abandoned subdomains part 2, Detectify Labs](https://labs.detectify.com/2014/12/08/hijacking-of-abandoned-subdomains-part-2/) diff --git a/4.0/en/0x19-V11-BusLogic.md b/4.0/en/0x19-V11-BusLogic.md index a1dd5104e3..3af3af02ad 100644 --- a/4.0/en/0x19-V11-BusLogic.md +++ b/4.0/en/0x19-V11-BusLogic.md @@ -10,25 +10,24 @@ Ensure that a verified application satisfies the following high level requiremen ## V11.1 Business Logic Security Requirements -Business logic security is so individual to every application that no one checklist will ever apply. Business logic security must be designed in to protect against likely external threats - it cannot be added using web application firewalls or secure communications. We recommend the use of threat modelling during design sprints, for example using the OWASP Cornucopia or similar tools. +Business logic security is so individual to every application that no one checklist will ever apply. Business logic security must be designed in to protect against likely external threats - it cannot be added using web application firewalls or secure communications. We recommend the use of threat modeling during design sprints, for example using the OWASP Cornucopia or similar tools. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **11.1.1** | Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.| ✓ | ✓ | ✓ | 841 | -| **11.1.2** | Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.| ✓ | ✓ | ✓ | 779 | +| **11.1.2** | Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.| ✓ | ✓ | ✓ | 799 | | **11.1.3** | Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis. | ✓ | ✓ | ✓ | 770 | | **11.1.4** | Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks. | ✓ | ✓ | ✓ | 770 | -| **11.1.5** | Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies. | ✓ | ✓ | ✓ | 841 | -| **11.1.6** | Verify the application does not suffer from "time of check to time of use" (TOCTOU) issues or other race conditions for sensitive operations. | | ✓ | ✓ | 367 | -| **11.1.7** | Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 754 | +| **11.1.5** | Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies. | ✓ | ✓ | ✓ | 841 | +| **11.1.6** | Verify the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations. | | ✓ | ✓ | 367 | +| **11.1.7** | Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 754 | | **11.1.8** | Verify the application has configurable alerting when automated attacks or unusual activity is detected. | | ✓ | ✓ | 390 | ## References For more information, see also: -* [OWASP Testing Guide 4.0: Business Logic Testing](https://www.owasp.org/index.php/Testing_for_business_logic) -* [OWASP Cheat Sheet](https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet) -* Anti-automation can be achieved in many ways, including the use of [OWASP AppSensor](https://www.owasp.org/index.php/OWASP_AppSensor_Project) and [OWASP Automated Threats to Web Applications](https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications) -* [OWASP AppSensor](https://www.owasp.org/index.php/OWASP_AppSensor_Project) can also help with Attack Detection and Response. -* [OWASP Cornucopia](https://www.owasp.org/index.php/OWASP_Cornucopia) \ No newline at end of file +* [OWASP Web Security Testing Guide 4.1: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README.html) +* Anti-automation can be achieved in many ways, including the use of [OWASP AppSensor](https://github.com/jtmelton/appsensor) and [OWASP Automated Threats to Web Applications](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [OWASP AppSensor](https://github.com/jtmelton/appsensor) can also help with Attack Detection and Response. +* [OWASP Cornucopia](https://owasp.org/www-project-cornucopia/) diff --git a/4.0/en/0x20-V12-Files-Resources.md b/4.0/en/0x20-V12-Files-Resources.md index 6f6e4eef8d..380af3adcd 100644 --- a/4.0/en/0x20-V12-Files-Resources.md +++ b/4.0/en/0x20-V12-Files-Resources.md @@ -13,7 +13,7 @@ Although zip bombs are eminently testable using penetration testing techniques, | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **12.1.1** | Verify that the application will not accept large files that could fill up storage or cause a denial of service attack. | ✓ | ✓ | ✓ | 400 | +| **12.1.1** | Verify that the application will not accept large files that could fill up storage or cause a denial of service. | ✓ | ✓ | ✓ | 400 | | **12.1.2** | Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus exhausting file storage limits. | | ✓ | ✓ | 409 | | **12.1.3** | Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. | | ✓ | ✓ | 770 | @@ -23,14 +23,14 @@ Although zip bombs are eminently testable using penetration testing techniques, | :---: | :--- | :---: | :---:| :---: | :---: | | **12.2.1** | Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content. | | ✓ | ✓ | 434 | -## V12.3 File execution Requirements +## V12.3 File Execution Requirements | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **12.3.1** | Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal. | ✓ | ✓ | ✓ | 22 | +| **12.3.1** | Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal. | ✓ | ✓ | ✓ | 22 | | **12.3.2** | Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI). | ✓ | ✓ | ✓ | 73 | -| **12.3.3** | Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI), which may also lead to SSRF. | ✓ | ✓ | ✓ | 98 | -| **12.3.4** | Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename. | ✓ | ✓ | ✓ | 641 | +| **12.3.3** | Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | ✓ | ✓ | ✓ | 98 | +| **12.3.4** | Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename. | ✓ | ✓ | ✓ | 641 | | **12.3.5** | Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection. | ✓ | ✓ | ✓ | 78 | | **12.3.6** | Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs. | | ✓ | ✓ | 829 | @@ -52,12 +52,12 @@ Although zip bombs are eminently testable using penetration testing techniques, | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **12.6.1** | Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from. | ✓ | ✓ | ✓ | 918 | +| **12.6.1** | Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from. | ✓ | ✓ | ✓ | 918 | ## References For more information, see also: -* [File Extension Handling for Sensitive Information](https://www.owasp.org/index.php/Unrestricted_File_Upload) +* [File Extension Handling for Sensitive Information](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload) * [Reflective file download by Oren Hafif](https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/) -* [OWASP Third Party JavaScript Management Cheat Sheet](https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat_Sheet) +* [OWASP Third Party JavaScript Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) diff --git a/4.0/en/0x21-V13-API.md b/4.0/en/0x21-V13-API.md index 96a45992a9..92c7e44731 100644 --- a/4.0/en/0x21-V13-API.md +++ b/4.0/en/0x21-V13-API.md @@ -22,7 +22,7 @@ Please read this chapter in combination with all other chapters at this same lev ## V13.2 RESTful Web Service Verification Requirements -JSON schema validation is in a draft stage of standardization (see references). When considering using JSON schema validation, which is best practice for SOAP web services, consider using these additional data validation strategies in combination with JSON schema validation: +JSON schema validation is in a draft stage of standardization (see references). When considering using JSON schema validation, which is best practice for RESTful web services, consider using these additional data validation strategies in combination with JSON schema validation: * Parsing validation of the JSON object, such as if there are missing or extra elements. * Validation of the JSON object values using standard input validation methods, such as data type, data format, length, etc. @@ -34,9 +34,9 @@ Once the JSON schema validation standard is formalized, ASVS will update its adv | :---: | :--- | :---: | :---:| :---: | :---: | | **13.2.1** | Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. | ✓ | ✓ | ✓ | 650 | | **13.2.2** | Verify that JSON schema validation is in place and verified before accepting input. | ✓ | ✓ | ✓ | 20 | -| **13.2.3** | Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern (see [references](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)), CSRF nonces, or ORIGIN request header checks. | ✓ | ✓ | ✓ | 352 | -| **13.2.4** | Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated. | | ✓ | ✓ | 779 | -| **13.2.5** | Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/JSON. | | ✓ | ✓ | 436 | +| **13.2.3** | Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks. | ✓ | ✓ | ✓ | 352 | +| **13.2.4** | Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated. | | ✓ | ✓ | 770 | +| **13.2.5** | Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. | | ✓ | ✓ | 436 | | **13.2.6** | Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. | | ✓ | ✓ | 345 | ## V13.3 SOAP Web Service Verification Requirements @@ -52,19 +52,20 @@ Note: Due to issues with XXE attacks against DTDs, DTD validation should not be | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | -| **13.4.1** | Verify that query whitelisting or a combination of depth limiting and amount limiting should be used to prevent GraphQL or data layer expression denial of service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. | | ✓ | ✓ | 770 | +| **13.4.1** | Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. | | ✓ | ✓ | 770 | | **13.4.2** | Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer. | | ✓ | ✓ | 285 | ## References For more information, see also: -* [OWASP Serverless Top 10](https://www.owasp.org/images/5/5c/OWASP-Top-10-Serverless-Interpretation-en.pdf) -* [OWASP Serverless Project](https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project) -* [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management) -* [OWASP Cross-Site Request Forgery cheat sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#triple-submit-cookie) -* [OWASP XML External Entity Prevention Cheat Sheet - General Guidance](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md#general-guidance)* [JSON Web Tokens (and Signing)](https://jwt.io/) -* [REST Security Cheat Sheet](https://www.owasp.org/index.php/REST_Security_Cheat_Sheet) +* [OWASP Serverless Top 10](https://github.com/OWASP/Serverless-Top-10-Project/raw/master/OWASP-Top-10-Serverless-Interpretation-en.pdf) +* [OWASP Serverless Project](https://owasp.org/www-project-serverless-top-10/) +* [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.html) +* [OWASP Cross-Site Request Forgery cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) +* [OWASP XML External Entity Prevention Cheat Sheet - General Guidance](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#general-guidance) +* [JSON Web Tokens (and Signing)](https://jwt.io/) +* [REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) * [JSON Schema](https://json-schema.org/specification.html) -* [XML DTD Entity Attacks](https://www.vsecurity.com//download/publications/XMLDTDEntityAttacks.pdf) -* [Orange Tsai - A new era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) \ No newline at end of file +* [XML DTD Entity Attacks](https://www.vsecurity.com/download/publications/XMLDTDEntityAttacks.pdf) +* [Orange Tsai - A new era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) diff --git a/4.0/en/0x22-V14-Config.md b/4.0/en/0x22-V14-Config.md index 5048335ffe..7f8d66ea9e 100644 --- a/4.0/en/0x22-V14-Config.md +++ b/4.0/en/0x22-V14-Config.md @@ -36,16 +36,16 @@ Note: At Level 1, 14.2.1 compliance relates to observations or detections of cli | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- | -| **14.2.1** | Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 1026 | +| **14.2.1** | Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 1026 | | **14.2.2** | Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users. | ✓ | ✓ | ✓ | 1002 | -| **14.2.3** | Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. | ✓ | ✓ | ✓ | 714 | -| **14.2.4** | Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 829 | -| **14.2.5** | Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | | -| **14.2.6** | Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | | ✓ | ✓ | 265 | +| **14.2.3** | Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. | ✓ | ✓ | ✓ | 829 | +| **14.2.4** | Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 829 | +| **14.2.5** | Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | +| **14.2.6** | Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 | ## V14.3 Unintended Security Disclosure Requirements -Configurations for production should be hardened to protect against common attacks, such as debug consoles, raise the bar for cross-site scripting (XSS) and remote file inclusion (RFI) attacks, and to eliminate trivial information discovery "vulnerabilities" that are the unwelcome hallmark of many penetration testing reports. Many of these issues are rarely rated as a significant risk, but they are chained together with other vulnerabilities. If these issues are not present by default, it raises the bar before most attacks can succeed. +Configurations for production should be hardened to protect against common attacks, such as debug consoles, raise the bar for Cross-site Scripting (XSS) and Remote File Inclusion (RFI) attacks, and to eliminate trivial information discovery "vulnerabilities" that are the unwelcome hallmark of many penetration testing reports. Many of these issues are rarely rated as a significant risk, but they are chained together with other vulnerabilities. If these issues are not present by default, it raises the bar before most attacks can succeed. | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- | @@ -57,30 +57,30 @@ Configurations for production should be hardened to protect against common attac | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- | -| **14.4.1** | Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1). | ✓ | ✓ | ✓ | 173 | -| **14.4.2** | Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type). | ✓ | ✓ | ✓ | 116 | -| **14.4.3** | Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities. | ✓ | ✓ | ✓ | 1021 | -| **14.4.4** | Verify that all responses contain X-Content-Type-Options: nosniff. | ✓ | ✓ | ✓ | 116 | -| **14.4.5** | Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains. | ✓ | ✓ | ✓ | 523 | +| **14.4.1** | Verify that every HTTP response contains a Content-Type header. text/*, */*+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1). | ✓ | ✓ | ✓ | 173 | +| **14.4.2** | Verify that all API responses contain a Content-Disposition: attachment; filename="api.json" header (or other appropriate filename for the content type). | ✓ | ✓ | ✓ | 116 | +| **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. | ✓ | ✓ | ✓ | 1021 | +| **14.4.4** | Verify that all responses contain a X-Content-Type-Options: nosniff header. | ✓ | ✓ | ✓ | 116 | +| **14.4.5** | Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains. | ✓ | ✓ | ✓ | 523 | | **14.4.6** | Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin". | ✓ | ✓ | ✓ | 116 | -| **14.4.7** | Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be embedded in a third-party site. | ✓ | ✓ | ✓ | 346 | +| **14.4.7** | Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers. | ✓ | ✓ | ✓ | 346 | ## V14.5 Validate HTTP Request Header Requirements | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- | -| **14.5.1** | Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS. | ✓ | ✓ | ✓ | 749 | +| **14.5.1** | Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context. | ✓ | ✓ | ✓ | 749 | | **14.5.2** | Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker. | ✓ | ✓ | ✓ | 346 | -| **14.5.3** | Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the "null" origin. | ✓ | ✓ | ✓ | 346 | +| **14.5.3** | Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the "null" origin. | ✓ | ✓ | ✓ | 346 | | **14.5.4** | Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application. | | ✓ | ✓ | 306 | ## References For more information, see also: -* [OWASP Testing Guide 4.0: Testing for HTTP Verb Tampering]( https://www.owasp.org/index.php/Testing_for_HTTP_Verb_Tampering_%28OTG-INPVAL-003%29) +* [OWASP Web Security Testing Guide 4.1: Testing for HTTP Verb Tampering]( https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.html) * Adding Content-Disposition to API responses helps prevent many attacks based on misunderstanding on the MIME type between client and server, and the "filename" option specifically helps prevent [Reflected File Download attacks.](https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf) -* [Content Security Policy Cheat Sheet](https://www.owasp.org/index.php?title=Content_Security_Policy_Cheat_Sheet) +* [Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) * [Exploiting CORS misconfiguration for BitCoins and Bounties](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) -* [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management) -* [Sandboxing third party components](https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat_Sheet#Sandboxing_Content) +* [OWASP Web Security Testing Guide 4.1: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.html) +* [Sandboxing third party components](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content) diff --git a/4.0/en/0x90-Appendix-A_Glossary.md b/4.0/en/0x90-Appendix-A_Glossary.md index 0148a542ff..890e57a1f6 100644 --- a/4.0/en/0x90-Appendix-A_Glossary.md +++ b/4.0/en/0x90-Appendix-A_Glossary.md @@ -1,7 +1,7 @@ # Appendix A: Glossary -- **2FA** – Two-factor authentication(2FA) adds a second level of authentication to an account log-in. -- **Address Space Layout Randomization (ASLR)** – A technique to make exploiting memory corruption bugs more difficult. +- **Address Space Layout Randomization** (ASLR) – A technique to make exploiting memory corruption bugs more difficult. +- **Allow list** – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. - **Application Security** – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. - **Application Security Verification** – The technical assessment of an application against the OWASP ASVS. - **Application Security Verification Report** – A report that documents the overall results and supporting analysis produced by the verifier for a particular application. @@ -11,30 +11,45 @@ - **Component** – a self-contained unit of code, with associated disk and network interfaces that communicates with other components. - **Cross-Site Scripting** (XSS) – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. - **Cryptographic module** – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. -- **CWE** - Common Weakness Enumeration (CWE) is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. -- **DAST** – Dynamic application security testing (DAST) technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. +- **Common Weakness Enumeration** (CWE) - A community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. - **Design Verification** – The technical assessment of the security architecture of an application. +- **Dynamic Application Security Testing** (DAST) - Technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. - **Dynamic Verification** – The use of automated tools that use vulnerability signatures to find problems during the execution of an application. +- **Fast IDentity Online** (FIDO) - A set of authentication standards which allow a variety of different authentication methods to be used including biometrics, Trusted Platform Modules (TPMs), USB security tokens, etc. - **Globally Unique Identifier** (GUID) – a unique reference number used as an identifier in software. - **Hyper Text Transfer Protocol** (HTTPS) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. - **Hardcoded keys** – Cryptographic keys which are stored on the filesystem, be it in code, comments or files. +- **Hardware Security Module** (HSM) - Hardware component which is able to store cryptographic keys and other secrets in a protected manner. +- **Hibernate Query Language** (HQL) - A query language that is similar in appearance to SQL used by the Hibernate ORM library. - **Input Validation** – The canonicalization and validation of untrusted user input. - **Malicious Code** – Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! - **Malware** – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. - **Open Web Application Security Project** (OWASP) – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: https://www.owasp.org/ +- **One-time Password** (OTP) - A password which is uniquely generated to be used on a single occasion. +- **Object-relational Mapping** (ORM) - A system used to allow a relational/table-based database to be referenced and queried within an application program using an application-compatible object model. +- **Password-Based Key Derivation Function 2** (PBKDF2) - A special one-way algorithm used to create a strong cryptographic key from an input text (such as a password) and an additional random salt value and can therefore be used make it harder to crack a password offline if the resulting value is stored instead of the original password. - **Personally Identifiable Information** (PII) - is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. -- **PIE** – Position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. -- **PKI** – Public Key Infrastructure (PKI) is an arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). -- **SAST** – Static application security testing (SAST) is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. -- **SDLC** – Software development lifecycle. +- **Position-independent executable** (PIE) - A body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. +- **Public Key Infrastructure** (PKI) - An arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). +- **Public Switched Telephone Network** (PSTN) - The traditional telephone network including both fixed-line telephones and mobile telephones. +- **Relying Party** (RP) - Generally an application which is relying on a user having authenticated against a separate authentication provider. The application is relying on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are. +- **Static application security testing** (SAST) - A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. +- **Software development lifecycle** (SDLC) - The step by step process by which software is developed going from the initial requirements to deployment and maintainance. - **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. - **Security Configuration** – The runtime configuration of an application that affects how security controls are used. - **Security Control** – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record). -- **SQL Injection (SQLi)** – A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. -- **SSO Authentication** – Single Sign On (SSO) occurs when a user logs into one application and is then automatically logged in to other applications without having to re-authenticate. For example, when you login to Google, when accessing other Google services such as Youtube, Google Docs, and Gmail you will be automatically logged in. +- **Server-side Request Forgery** (SSRF) - An attack which abuses functionality on the server to read or update internal resources by supplying or modifying a URL which the code running on the server will read or submit data to. +- **Single Sign-on Authentication** (SSO) - This occurs when a user logs into one application and is then automatically logged in to other applications without having to re-authenticate. For example, when you login to Google, when accessing other Google services such as YouTube, Google Docs, and Gmail you will be automatically logged in. +- **SQL Injection** (SQLi) – A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. +- **SVG** - Scalable Vector Graphics +- **Time-based OTP** - A method of generating an OTP where the current time acts as part of the algorithm to generate the password. - **Threat Modeling** - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. -- **Transport Layer Security** – Cryptographic protocols that provide communication security over a network connection +- **Transport Layer Security** (TLS) – Cryptographic protocols that provide communication security over a network connection +- **Trusted Platform Module** (TPM) - A type of HSM which is usually attached to a larger hardware component such as a motherboard and acts as the "root of trust" for that system. +- **Two-factor authentication** (2FA) - This adds a second level of authentication to an account log-in. +- **Universal 2nd Factor** (U2F) - One of the standards created by FIDO specifically for allowing a USB or NFC security key to be used as a 2nd authentication factor. - **URI/URL/URL fragments** – A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource. - **Verifier** – The person or team that is reviewing an application against the OWASP ASVS requirements. -- **Whitelist** – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. +- **What You See Is What You Get** (WYSIWYG) - A type of rich content editor which shows how the content will actually look when rendered rather than showing the coding used to govern the rendering. - **X.509 Certificate** – An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. +- **XML eXternal Entity** (XXE) - A type of XML entity that can access local or remote content via a declared system identifier. This may load to various injection attacks. \ No newline at end of file diff --git a/4.0/en/0x91-Appendix-B_References.md b/4.0/en/0x91-Appendix-B_References.md index f6598987e1..604b475aec 100644 --- a/4.0/en/0x91-Appendix-B_References.md +++ b/4.0/en/0x91-Appendix-B_References.md @@ -4,25 +4,31 @@ The following OWASP projects are most likely to be useful to users/adopters of t ## OWASP Core Projects -1. OWASP Top 10 Project: [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) -2. OWASP Testing Guide: [https://www.owasp.org/index.php/OWASP_Testing_Project](https://www.owasp.org/index.php/OWASP_Testing_Project) -3. OWASP Proactive Controls: [https://www.owasp.org/index.php/OWASP_Proactive_Controls](https://www.owasp.org/index.php/OWASP_Proactive_Controls) -4. OWASP Security Knowledge Framework: [https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework](https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework) -5. OWASP Software Assurance Maturity Model (SAMM): [https://www.owasp.org/index.php/OWASP_SAMM_Project](https://www.owasp.org/index.php/OWASP_SAMM_Project) +1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/) +2. OWASP Web Security Testing Guide: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/) +3. OWASP Proactive Controls: [https://owasp.org/www-project-proactive-controls/](https://owasp.org/www-project-proactive-controls/) +4. OWASP Security Knowledge Framework: [https://owasp.org/www-project-security-knowledge-framework/](https://owasp.org/www-project-security-knowledge-framework/) +5. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/) + +## OWASP Cheat Sheet Series project + +[This project](https://owasp.org/www-project-cheat-sheets/) has a number of cheat sheets which will be relevant for different topics in the ASVS. + +There is a mapping to the ASVS which can be found here: [https://cheatsheetseries.owasp.org/cheatsheets/IndexASVS.html](https://cheatsheetseries.owasp.org/cheatsheets/IndexASVS.html) ## Mobile Security Related Projects -1. OWASP Mobile Security Project: [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project](https://www.owasp.org/index.php/OWASP_Mobile_Security_Project) -2. OWASP Mobile Top 10 Risks: [https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks](https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks) -3. OWASP Mobile Security Testing Guide: [https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide](https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide) +1. OWASP Mobile Security Project: [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) +2. OWASP Mobile Top 10 Risks: [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) +3. OWASP Mobile Security Testing Guide and Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) ## OWASP Internet of Things related projects -1. OWASP Internet of Things Project: [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project) +1. OWASP Internet of Things Project: [https://owasp.org/www-project-internet-of-things/](https://owasp.org/www-project-internet-of-things/) ## OWASP Serverless projects -1. OWASP Serverless Project: [https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project](https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project) +1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/) ## Others diff --git a/4.0/en/0x93-Appendix-C_IoT.md b/4.0/en/0x93-Appendix-C_IoT.md index 4e1461e8b1..f837afb484 100644 --- a/4.0/en/0x93-Appendix-C_IoT.md +++ b/4.0/en/0x93-Appendix-C_IoT.md @@ -1,6 +1,6 @@ # Appendix C: Internet of Things Verification Requirements -This section was originally in the main branch, but with the work that the OWASP IoT team has done, it doesn't make sense to maintain two different threads on the subject. For the 4.0 release, we are moving this to the Appendix, and urge all who require this, to rather use the main [OWASP IoT project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project) +This section was originally in the main branch, but with the work that the OWASP IoT team has done, it doesn't make sense to maintain two different threads on the subject. For the 4.0 release, we are moving this to the Appendix, and urge all who require this, to rather use the main [OWASP IoT project](https://owasp.org/www-project-internet-of-things/) ## Control Objective @@ -53,7 +53,7 @@ Embedded/IoT devices should: For more information, see also: -* [OWASP Internet of Things Top 10](https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf) -* [OWASP Embedded Application Security Project](https://www.owasp.org/index.php/OWASP_Embedded_Application_Security) -* [OWASP Internet of Things Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project) +* [OWASP Internet of Things Top 10](https://owasp.org/www-pdf-archive/OWASP-IoT-Top-10-2018-final.pdf) +* [OWASP Embedded Application Security Project](https://owasp.org/www-project-embedded-application-security/) +* [OWASP Internet of Things Project](https://owasp.org/www-project-internet-of-things/) * [Trudy TCP Proxy Tool](https://github.com/praetorian-inc/trudy) diff --git a/4.0/export.py b/4.0/export.py index b87244ab6f..c88d8a5c7d 100644 --- a/4.0/export.py +++ b/4.0/export.py @@ -33,10 +33,11 @@ parser = argparse.ArgumentParser(description='Export the ASVS requirements.') parser.add_argument('--format', choices=['json', 'xml', 'csv'], default='json') +parser.add_argument('--language', default='en') args = parser.parse_args() -m = ASVS() +m = ASVS(args.language) if args.format == "csv": print(m.to_csv()) diff --git a/4.0/generate-all.sh b/4.0/generate-all.sh new file mode 100644 index 0000000000..5a6f43a7dc --- /dev/null +++ b/4.0/generate-all.sh @@ -0,0 +1,11 @@ +#!/bin/bash + +lang="en" +vers="4.0.2" +verslong="./docs_$lang/OWASP Application Security Verification Standard $vers-$lang" + +python3 export.py --format json --language $lang > "$verslong.json" +python3 export.py --format xml --language $lang > "$verslong.xml" +python3 export.py --format csv --language $lang > "$verslong.csv" + +./generate_document.sh $lang $vers diff --git a/4.0/generate-csv.py b/4.0/generate-csv.py deleted file mode 100755 index 463581de11..0000000000 --- a/4.0/generate-csv.py +++ /dev/null @@ -1,46 +0,0 @@ -#!/usr/bin/env python - -""" Quick and Dirty Roberto Martelloni's script to generate a CSV """ - -import re -import os - - -def area_from_filename(filename): - filename_parts = filename.split("-") - area_id = filename_parts[1] - name = filename_parts[2].split(".") - name = name[0].replace("_", " ") - - return [area_id, name] - - -def parse_md(filename): - in_table = False - - for line in open(filename): - if re.match(r"\s*\|", line): - if re.match(r"\s*\|\s*#\s*\|", line): - in_table = True - continue - if re.match(r"\|\s*:?--+:?\s*\|", line): - continue - - if in_table: - start = area_from_filename(filename) - line = line.replace("*", "") - line = line.replace('"', '""') - line = re.split(r"\s*\|\s*", line) - print('"' + '","'.join(start + line[1:-1]) + '"') - else: - in_table = False - - -def main(): - for file in os.listdir("./en"): - if file.find("-V") != -1: - parse_md("./en/" + file) - - -if __name__ == '__main__': - main() diff --git a/4.0/generate_document.sh b/4.0/generate_document.sh index 55095b4ceb..5863f7c17b 100755 --- a/4.0/generate_document.sh +++ b/4.0/generate_document.sh @@ -13,65 +13,65 @@ if ! command_exists pandoc; then fi generate_docx() { - pandoc -s -f gfm --reference-doc=../templates/reference.docx --columns 10000 -t docx -o "../OWASP Application Security Verification Standard 4.0-$1.docx" *.md + pandoc -s -f gfm --reference-doc=../templates/reference.docx --columns 10000 --toc -t docx -o "../docs_$1/OWASP Application Security Verification Standard $2-$1.docx" *.md + echo " done." + echo -e "" + echo -e "DOCX GENERATION MANUAL STEPS" + echo -e "----------------------------" + echo -e "After the docx file has been generated, do the following:" + echo -e " - Select 'No' in the first prompt that appears" + echo -e " - Move the 'Table of Contents' section to be just before the 'Frontispiece' section." + echo -e " - Select the document heading (one of the first lines in the documrnt) which should say: 'OWASP Application" + echo -e " Security Verification Standard $2', go to 'Paragraph' > 'Line and Page Breaks' and" + echo -e " deselect 'Page break before'" + echo -e " - Go to 'File' > 'Info' and set the 'Title' field to be 'OWASP Application Security Verification Standard $2'" + echo -e " - Run the following VBA macro to fix Table settings:" + echo -e " " + echo -e " Dim tbl As Table" + echo -e " For Each tbl In ActiveDocument.Tables" + echo -e " tbl.Rows(1).HeadingFormat = True" + echo -e " tbl.Rows.AllowBreakAcrossPages = False" + echo -e " Next tbl" + echo -e " " + echo -e " - Manually review the document and move any orphaned table headings or section headings to the" + echo -e " following page" + echo -e " - Run 'Update table...' on the Table of Contents" + echo -e " - Remove the lines above 'Frontispiece' from the Table of Contents" } # generate_html() { # pandoc -s -f markdown_github -t html5 -o "../OWASP Application Security Verification Standard 4.0-$1.html" *.md # } -generate() { - echo -n "Generating OWASP ASVS 4.0 ($1)..." - if [ -d "$1" ]; - then - cd "$1" - generate_docx $1 - # generate_html $1 - cd .. - echo " done." - else - echo " No OWASP ASVS found in directory $1" - fi -} - -# Arabic -#generate "ar" - -# Brazil -#generate "br" - -# Chinese -#generate "cn" - -# Czech -#generate "cz" - -# English -generate "en" - -# French -#generate "fr" +lang="en" +vers="4.0" -# German -# generate "de" - -# Hebrew -#generate "heb" - -# Italian -#generate "it" - -# Japanese -#generate "jp" +if [ -z "$1" ] +then + lang="en" +else + lang=$1 +fi -# Korean -#generate "kr" +if [ -z "$2" ] +then + vers="4.0" +else + vers=$2 +fi -# Spanish -# generate "es" +echo -n "Generating OWASP ASVS $vers ($lang)..." +if [ -d "$lang" ]; +then + cd "$lang" + generate_docx $lang $vers + # generate_html $lang + cd .. + +else + echo " No OWASP ASVS found in directory $lang" +fi -# Ukraine -#generate "ukr" echo -echo "Generated OWASP Application Security Verification Standard 4.0" +echo "Generated OWASP Application Security Verification Standard $vers" diff --git a/4.0/presentations/AppSec DC 2019 ASVS 4.0 Final.pptx b/4.0/presentations/AppSec DC 2019 ASVS 4.0 Final.pptx new file mode 100644 index 0000000000..9fa09e41b5 Binary files /dev/null and b/4.0/presentations/AppSec DC 2019 ASVS 4.0 Final.pptx differ diff --git a/4.0/presentations/MyDevSecOps Jan 2020 Webinar - ASVS.pptx b/4.0/presentations/MyDevSecOps Jan 2020 Webinar - ASVS.pptx new file mode 100644 index 0000000000..a078d444f8 Binary files /dev/null and b/4.0/presentations/MyDevSecOps Jan 2020 Webinar - ASVS.pptx differ diff --git a/4.0/presentations/OWASP Helsinki Sep 2019 ASVS 4.0.pptx b/4.0/presentations/OWASP Helsinki Sep 2019 ASVS 4.0.pptx new file mode 100644 index 0000000000..fd58d8b9ce Binary files /dev/null and b/4.0/presentations/OWASP Helsinki Sep 2019 ASVS 4.0.pptx differ diff --git a/4.0/presentations/OWASP Israel Nov 2019 ASVS.pptx b/4.0/presentations/OWASP Israel Nov 2019 ASVS.pptx new file mode 100644 index 0000000000..0a58705c90 Binary files /dev/null and b/4.0/presentations/OWASP Israel Nov 2019 ASVS.pptx differ diff --git a/4.0/presentations/README.md b/4.0/presentations/README.md new file mode 100644 index 0000000000..7c1b3a28da --- /dev/null +++ b/4.0/presentations/README.md @@ -0,0 +1,6 @@ +Index of presentations in this folder: +- **NullCon 2019 ASVS 4.0 Release.pptx** - Original 4.0 release presentation prepared by Andrew van der Stock for Nullcon 2019 +- **AppSec DC 2019 ASVS 4.0 Final.pptx** - Slides for training prepared and delivered by Andrew van der Stock for Global AppSec DC 2019. +- **OWASP Helsinki Sep 2019 ASVS 4.0.pptx** - Based on Andrew's 4.0 release presentation but modified and extended by Josh Grossman for ~60min presentation at OWASP Helsinki chapter meeting. +- **OWASP Israel Nov 2019 ASVS 4.0.pptx** - Based on Andrew's 4.0 release presentation but structually modified by Josh Grossman for ~30min presentation at OWASP Israel chapter meeting. +- **MyDevSecOps Jan 2020 Webinar - ASVS.pptx** - Slightly expanded version of the "OWASP Israel Nov 2019" version which runs for ~45mins. diff --git a/4.0/templates/reference.docx b/4.0/templates/reference.docx index e8ccb3fe76..6cee38f599 100644 Binary files a/4.0/templates/reference.docx and b/4.0/templates/reference.docx differ diff --git a/LICENSE.md b/LICENSE.md new file mode 100644 index 0000000000..3b91640c18 --- /dev/null +++ b/LICENSE.md @@ -0,0 +1,3 @@ +The entire project content is under the **[Creative Commons v3.0](https://creativecommons.org/licenses/by-sa/3.0/)** license. + +[![LICENSE](https://i.creativecommons.org/l/by-sa/3.0/88x31.png)](http://creativecommons.org/licenses/by-sa/3.0/) \ No newline at end of file diff --git a/README.md b/README.md index 09c6e4773a..d67d02f526 100644 --- a/README.md +++ b/README.md @@ -1,23 +1,62 @@ -OWASP Application Security Verification Standard -==== +# THIS BRANCH IS AN UNRELEASED DRAFT +# +# OWASP Application Security Verification Standard +![LicenseBadge](https://img.shields.io/badge/license-C_C-blue.svg) +
[![LICENSE](https://i.creativecommons.org/l/by-sa/3.0/88x31.png)](http://creativecommons.org/licenses/by-sa/3.0/) +## Introduction -The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to provide an open application security standard for web apps and web services of all types. +The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to provide an open application security standard for web apps and web services of all types. -The standard provides a basis for designing, building, and testing technical application security controls, including architectural concerns, secure development lifecycle, threat modelling, agile security including continuous integration / deploynent, serverless, and configuration concerns. +The standard provides a basis for designing, building, and testing technical application security controls, including architectural concerns, secure development lifecycle, threat modelling, agile security including continuous integration / deployment, serverless, and configuration concerns. -The latest published version is version 4.0.1, which can be found: -* [OWASP Application Security Verification Standard 4.0.1 English (PDF)](https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-en.pdf) -* [OWASP Application Security Verification Standard 4.0.1 English (Word)](https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-en.docx) -* [OWASP Application Security Verification Standard 4.0.1 English (CSV)](https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-en.csv) +**Please [log issues](https://github.com/OWASP/ASVS/issues) if you find any bugs or if you have ideas. We may subsequently ask you to [open a pull request](https://github.com/OWASP/ASVS/pulls) based on the discussion in the issue. We are also actively looking for translations of the 4.n branch.** + +## Standard Objectives The requirements were developed with the following objectives in mind: -* Help organizations adopt or adapt a high quality secure coding standard +* Help organizations adopt or adapt a high quality secure coding standard * Help architects and developers build secure software by designing and building security in, and verifying that they are in place and effective by the use of unit and integration tests that implement ASVS tests * Help deploy secure software via the use of repeatable, secured builds * Help security reviewers use a comprehensive, consistent, high quality standard for hybrid code reviews, secure code reviews, peer code reviews, retrospectives, and work with developers to build security unit and integration tests. It is even possible to use this standard for penetration testing at Level 1 * Assist tool vendors by ensuring there is an easily generatable machine readable version, with CWE mappings * Assist organizations to benchmark application security tools by the percentage of coverage of the ASVS for dynamic, interactive, and static analysis tools -* Minimize overlapping and competing requirements from other standards, by either aligning strongly with them (NIST 800-63), or being strict supersets (OWASP Top 10 2017, PCI DSS 3.2.1), which will help reduce compliance costs, effort, and time wasted in accepting unnecessary differences as risks. +* Minimize overlapping and competing requirements from other standards, by either aligning strongly with them (NIST 800-63), or being strict supersets (OWASP Top 10 2017, PCI DSS 3.2.1), which will help reduce compliance costs, effort, and time wasted in accepting unnecessary differences as risks. + +ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. + +## Latest Stable Version - 4.0.2 + +The latest stable version is version 4.0.2 (dated October 2020), which can be found: +* [OWASP Application Security Verification Standard 4.0.2 English (PDF)](https://github.com/OWASP/ASVS/raw/v4.0.2/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-en.pdf) +* [OWASP Application Security Verification Standard 4.0.2 English (Word)](https://github.com/OWASP/ASVS/raw/v4.0.2/4.0/docs_en/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-en.docx) +* [OWASP Application Security Verification Standard 4.0.2 English (CSV)](https://github.com/OWASP/ASVS/raw/v4.0.2/4.0/docs_en/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-en.csv) +* [OWASP Application Security Verification Standard 4.0.2 (GitHub Tag)](https://github.com/OWASP/ASVS/tree/v4.0.2) + +The master branch of this repository will always be the "bleeding edge version" which might have in-progress changes or other edits open. The next release target will be version **4.1**. + +### Translations + +* [OWASP Application Security Verification Standard 4.0.1 Persian (PDF)](4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-fa.pdf) (Thanks to [SajjadPourali](https://github.com/SajjadPourali)) +* [OWASP Application Security Verification Standard 4.0 German (PDF)](4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-DE.pdf) (Thanks to Jörg Brünner) +* [OWASP Application Security Verification Standard 4.0 Japanese (PDF)](4.0/OWASP-Application-Security-Verification-Standard-4.0-ja.pdf) (Thanks to Software ISAC Japan / [Riotaro OKADA](https://github.com/okdt)) +* [OWASP Application Security Verification Standard 4.0 Turkish (PDF)](4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-tr.pdf) (Thanks to [Fatih ERSINADIM](https://github.com/fatihersinadim)) + +## How To Reference ASVS Requirements + +Each requirement has an identifier in the format `.
.` where each element is a number, for example: `1.11.3`. +- The `` value corresponds to the chapter from which the requirement comes, for example: all `1.#.#` requirements are from the `Architecture` chapter. +- The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architectural Requirements` section of the `Architecture` chapter. +- The `` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.2 of this standard is: + +> 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. + +The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v4.0.2-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.2. (This could be summarized as `v-`.) + +Note: The `v` preceding the version portion is to be lower case. + +If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. + +## License -Please log issues if you find anything. We are actively looking for translations of the 4.0 branch. +The entire project content is under the **[Creative Commons v3.0](https://creativecommons.org/licenses/by-sa/3.0/)** license.