diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 72e1eb9634..60b575099e 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -3,6 +3,7 @@ IMPORTANT NOTES:
- Changes should always be made only in the raw .md files and not in the CSV, JSON, XLSX, PDF, DOCX files, etc.
- Please do not open a pull request without first opening an associated issue.
- Please carry out all discussion in the associated issue only.
+- Please refer to the following link for guidance on labeling contributions https://github.com/OWASP/ASVS/blob/master/CONTRIBUTING.md
-->
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
deleted file mode 100644
index e90b71a35b..0000000000
Binary files a/4.0/OWASP Application Security Verification Standard 4.0-DE.pdf and /dev/null differ
diff --git a/4.0/OWASP Application Security Verification Standard 4.0.2-de.pdf b/4.0/OWASP Application Security Verification Standard 4.0.2-de.pdf
new file mode 100644
index 0000000000..95b5deca0c
Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0.2-de.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
deleted file mode 100644
index 9b55635713..0000000000
Binary files a/4.0/OWASP Application Security Verification Standard 4.0.2-en.pdf and /dev/null differ
diff --git a/4.0/OWASP Application Security Verification Standard 4.0.3-en.pdf b/4.0/OWASP Application Security Verification Standard 4.0.3-en.pdf
new file mode 100644
index 0000000000..cf60f9361d
Binary files /dev/null and b/4.0/OWASP Application Security Verification Standard 4.0.3-en.pdf differ
diff --git a/4.0/asvs.py b/4.0/asvs.py
index 841d548e6f..63f95049f5 100644
--- a/4.0/asvs.py
+++ b/4.0/asvs.py
@@ -50,6 +50,8 @@ class ASVS:
"provides developers with a list of requirements for secure development."
asvs_flat = []
+ asvs_flat2 = {}
+ asvs_flat2['requirements'] = []
def __init__(self, language):
@@ -129,15 +131,16 @@ def __init__(self, language):
if m:
req_flat = {}
- req_flat['chapter_id'] = chapter['Shortcode']
- req_flat['chapter_name'] = chapter['Name']
+ req_flat2 = {}
+ req_flat2['Section'] = req_flat['chapter_id'] = chapter['Shortcode']
+ req_flat2['Name'] = 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_flat2['Item'] = 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)
+ req_flat2['Description'] = req_flat['req_description'] = req['Description'] = m.group(2)
level1 = {}
level2 = {}
@@ -148,8 +151,11 @@ def __init__(self, language):
req_flat['level3'] = m.group(5).strip(' ')
level1['Required'] = m.group(3).strip() != ''
+ req_flat2['L1'] = ('X' if level1['Required'] else '')
level2['Required'] = m.group(4).strip() != ''
+ req_flat2['L2'] = ('X' if level2['Required'] else '')
level3['Required'] = m.group(5).strip() != ''
+ req_flat2['L3'] = ('X' if level3['Required'] else '')
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('✓ '))
@@ -160,17 +166,22 @@ def __init__(self, language):
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_flat2['CWE'] = 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()
+ req_flat2['NIST'] = req_flat['nist'] = m.group(7).strip()
section['Items'].append(req)
self.asvs_flat.append(req_flat)
+ self.asvs_flat2['requirements'].append(req_flat2)
def to_json(self):
''' Returns a JSON-formatted string '''
return json.dumps(self.asvs, indent = 2, sort_keys = False).strip()
+ def to_json_flat(self):
+ ''' Returns a JSON-formatted string which is flattened and simpler '''
+ return json.dumps(self.asvs_flat2, indent = 2, sort_keys = False).strip()
+
def to_xmlOLD(self):
''' Returns XML '''
xml = ''
diff --git a/4.0/docs_de/OWASP Application Security Verification Standard 4.0.2-de.docx b/4.0/docs_de/OWASP Application Security Verification Standard 4.0.2-de.docx
new file mode 100644
index 0000000000..63cda504d0
Binary files /dev/null and b/4.0/docs_de/OWASP Application Security Verification Standard 4.0.2-de.docx differ
diff --git a/4.0/docs_de/de b/4.0/docs_de/de
new file mode 100644
index 0000000000..e69de29bb2
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
deleted file mode 100644
index f3f4b1598d..0000000000
--- a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.csv
+++ /dev/null
@@ -1,288 +0,0 @@
-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/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
deleted file mode 100644
index e3135dc0a8..0000000000
--- a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.xml
+++ /dev/null
@@ -1,6751 +0,0 @@
-
-
- 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/OWASP Application Security Verification Standard 4.0.3-en.csv b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.csv
new file mode 100644
index 0000000000..9f32368bce
--- /dev/null
+++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.csv
@@ -0,0 +1,288 @@
+chapter_id,chapter_name,section_id,section_name,req_id,req_description,level1,level2,level3,cwe,nist
+V1,,V1.1,Secure Software Development Lifecycle,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,,V1.1,Secure Software Development Lifecycle,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,,V1.1,Secure Software Development Lifecycle,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,,V1.1,Secure Software Development Lifecycle,V1.1.4,"Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.",,✓,✓,1059,
+V1,,V1.1,Secure Software Development Lifecycle,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,,V1.1,Secure Software Development Lifecycle,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,,V1.1,Secure Software Development Lifecycle,V1.1.7,"Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.",,✓,✓,637,
+V1,,V1.2,Authentication Architecture,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,,V1.2,Authentication Architecture,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,,V1.2,Authentication Architecture,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,,V1.2,Authentication Architecture,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,,V1.4,Access Control Architecture,V1.4.1,"Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.",,✓,✓,602,
+V1,,V1.4,Access Control Architecture,V1.4.2,"[DELETED, NOT ACTIONABLE]",,,,,
+V1,,V1.4,Access Control Architecture,V1.4.3,"[DELETED, DUPLICATE OF 4.1.3]",,,,,
+V1,,V1.4,Access Control Architecture,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,,V1.4,Access Control Architecture,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,,V1.5,Input and Output Architecture,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,,V1.5,Input and Output Architecture,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,,V1.5,Input and Output Architecture,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,,V1.5,Input and Output Architecture,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,,V1.6,Cryptographic Architecture,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,,V1.6,Cryptographic Architecture,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,,V1.6,Cryptographic Architecture,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,,V1.6,Cryptographic Architecture,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,,V1.7,"Errors, Logging and Auditing Architecture",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,,V1.7,"Errors, Logging and Auditing Architecture",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,,V1.8,Data Protection and Privacy Architecture,V1.8.1,Verify that all sensitive data is identified and classified into protection levels.,,✓,✓,,
+V1,,V1.8,Data Protection and Privacy Architecture,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,,V1.9,Communications Architecture,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,,V1.9,Communications Architecture,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,,V1.10,Malicious Software Architecture,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,,V1.11,Business Logic Architecture,V1.11.1,Verify the definition and documentation of all application components in terms of the business or security functions they provide.,,✓,✓,1059,
+V1,,V1.11,Business Logic Architecture,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,,V1.11,Business Logic Architecture,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,,V1.12,Secure File Upload Architecture,V1.12.1,"[DELETED, DUPLICATE OF 12.4.1]",,,,,
+V1,,V1.12,Secure File Upload Architecture,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,,V1.14,Configuration Architecture,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,,V1.14,Configuration Architecture,V1.14.2,"Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.",,✓,✓,494,
+V1,,V1.14,Configuration Architecture,V1.14.3,Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.,,✓,✓,1104,
+V1,,V1.14,Configuration Architecture,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,,V1.14,Configuration Architecture,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,,V1.14,Configuration Architecture,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,,V2.1,Password Security,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,,V2.1,Password Security,V2.1.2,"Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,521,5.1.1.2
+V2,,V2.1,Password Security,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,,V2.1,Password Security,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,,V2.1,Password Security,V2.1.5,Verify users can change their password.,✓,✓,✓,620,5.1.1.2
+V2,,V2.1,Password Security,V2.1.6,Verify that password change functionality requires the user's current and new password.,✓,✓,✓,620,5.1.1.2
+V2,,V2.1,Password Security,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,,V2.1,Password Security,V2.1.8,Verify that a password strength meter is provided to help users set a stronger password.,✓,✓,✓,521,5.1.1.2
+V2,,V2.1,Password Security,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,,V2.1,Password Security,V2.1.10,Verify that there are no periodic credential rotation or password history requirements.,✓,✓,✓,263,5.1.1.2
+V2,,V2.1,Password Security,V2.1.11,"Verify that ""paste"" functionality, browser password helpers, and external password managers are permitted.",✓,✓,✓,521,5.1.1.2
+V2,,V2.1,Password Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.2,General Authenticator Security,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,,V2.3,Authenticator Lifecycle,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,,V2.3,Authenticator Lifecycle,V2.3.2,"Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.",,✓,✓,308,6.1.3
+V2,,V2.3,Authenticator Lifecycle,V2.3.3,Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.,,✓,✓,287,6.1.4
+V2,,V2.4,Credential Storage,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,,V2.4,Credential Storage,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,,V2.4,Credential Storage,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,,V2.4,Credential Storage,V2.4.4,"Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2
+V2,,V2.4,Credential Storage,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,,V2.5,Credential Recovery,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,,V2.5,Credential Recovery,V2.5.2,"Verify password hints or knowledge-based authentication (so-called ""secret questions"") are not present.",✓,✓,✓,640,5.1.1.2
+V2,,V2.5,Credential Recovery,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,,V2.5,Credential Recovery,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,,V2.5,Credential Recovery,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,,V2.5,Credential Recovery,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,,V2.5,Credential Recovery,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,,V2.6,Look-up Secret Verifier,V2.6.1,Verify that lookup secrets can be used only once.,,✓,✓,308,5.1.2.2
+V2,,V2.6,Look-up Secret Verifier,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,,V2.6,Look-up Secret Verifier,V2.6.3,"Verify that lookup secrets are resistant to offline attacks, such as predictable values.",,✓,✓,310,5.1.2.2
+V2,,V2.7,Out of Band Verifier,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,,V2.7,Out of Band Verifier,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,,V2.7,Out of Band Verifier,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,,V2.7,Out of Band Verifier,V2.7.4,Verify that the out of band authenticator and verifier communicates over a secure independent channel.,✓,✓,✓,523,5.1.3.2
+V2,,V2.7,Out of Band Verifier,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,,V2.7,Out of Band Verifier,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,,V2.8,One Time Verifier,V2.8.1,Verify that time-based OTPs have a defined lifetime before expiring.,✓,✓,✓,613,5.1.4.2 / 5.1.5.2
+V2,,V2.8,One Time Verifier,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,,V2.8,One Time Verifier,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,,V2.8,One Time Verifier,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,,V2.8,One Time Verifier,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,,V2.8,One Time Verifier,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,,V2.8,One Time Verifier,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,,V2.9,Cryptographic Verifier,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,,V2.9,Cryptographic Verifier,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,,V2.9,Cryptographic Verifier,V2.9.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",,✓,✓,327,5.1.7.2
+V2,,V2.10,Service Authentication,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,,V2.10,Service Authentication,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,,V2.10,Service Authentication,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,,V2.10,Service Authentication,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,,V3.1,Fundamental Session Management Security,V3.1.1,Verify the application never reveals session tokens in URL parameters.,✓,✓,✓,598,
+V3,,V3.2,Session Binding,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,,V3.2,Session Binding,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,,V3.2,Session Binding,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,,V3.2,Session Binding,V3.2.4,Verify that session tokens are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,331,7.1
+V3,,V3.3,Session Termination,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,,V3.3,Session Termination,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,,V3.3,Session Termination,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,,V3.3,Session Termination,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,,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,,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,,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,,V3.4,Cookie-based Session Management,V3.4.4,"Verify that cookie-based session tokens use the ""__Host-"" prefix so cookies are only sent to the host that initially set the cookie.",✓,✓,✓,16,7.1.1
+V3,,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 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,,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,,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,,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,,V3.6,Federated Re-authentication,V3.6.1,Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period.,,,✓,613,7.2.1
+V3,,V3.6,Federated Re-authentication,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,,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,,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,,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,,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,,V4.1,General Access Control Design,V4.1.4,"[DELETED, DUPLICATE OF 4.1.3]",,,,,
+V4,,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,,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,,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,,V4.3,Other Access Control Considerations,V4.3.1,Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.,✓,✓,✓,419,
+V4,,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,,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,,V5.1,Input Validation,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,,V5.1,Input Validation,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,,V5.1,Input Validation,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,,V5.1,Input Validation,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, e-mail addresses, telephone numbers, 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,,V5.1,Input Validation,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,,V5.2,Sanitization and Sandboxing,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,,V5.2,Sanitization and Sandboxing,V5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,✓,✓,✓,138,
+V5,,V5.2,Sanitization and Sandboxing,V5.2.3,Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.,✓,✓,✓,147,
+V5,,V5.2,Sanitization and Sandboxing,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,,V5.2,Sanitization and Sandboxing,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,,V5.2,Sanitization and Sandboxing,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,,V5.2,Sanitization and Sandboxing,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,,V5.2,Sanitization and Sandboxing,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,V5.3.6,"Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,830,
+V5,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,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,,V5.3,Output Encoding and Injection Prevention,V5.3.9,Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.,✓,✓,✓,829,
+V5,,V5.3,Output Encoding and Injection Prevention,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,,V5.4,"Memory, String, and Unmanaged Code",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,,V5.4,"Memory, String, and Unmanaged Code",V5.4.2,"Verify that format strings do not take potentially hostile input, and are constant.",,✓,✓,134,
+V5,,V5.4,"Memory, String, and Unmanaged Code",V5.4.3,"Verify that sign, range, and input validation techniques are used to prevent integer overflows.",,✓,✓,190,
+V5,,V5.5,Deserialization Prevention,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,,V5.5,Deserialization Prevention,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,,V5.5,Deserialization Prevention,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,,V5.5,Deserialization Prevention,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,V7.1,Log Content,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,,V7.1,Log Content,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,,V7.1,Log Content,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,,V7.1,Log Content,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,,V7.2,Log Processing,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,,V7.2,Log Processing,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,,V7.3,Log Protection,V7.3.1,Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,117,
+V7,,V7.3,Log Protection,V7.3.2,"[DELETED, DUPLICATE OF 7.3.1]",,,,,
+V7,,V7.3,Log Protection,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,,V7.3,Log Protection,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,,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,,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,,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,,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,,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,,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,,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,,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,,V8.1,General Data Protection,V8.1.6,Verify that backups are stored securely to prevent data from being stolen or corrupted.,,,✓,19,
+V8,,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,,V8.2,Client-side Data Protection,V8.2.2,"Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.",✓,✓,✓,922,
+V8,,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,,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,,V8.3,Sensitive Private Data,V8.3.2,Verify that users have a method to remove or export their data on demand.,✓,✓,✓,212,
+V8,,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,,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,,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,,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,,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,,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,,V9.1,Client Communication Security,V9.1.1,"Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,319,
+V9,,V9.1,Client Communication Security,V9.1.2,"Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.",✓,✓,✓,326,
+V9,,V9.1,Client Communication Security,V9.1.3,"Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.",✓,✓,✓,326,
+V9,,V9.2,Server Communication Security,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,,V9.2,Server Communication Security,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,,V9.2,Server Communication Security,V9.2.3,Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.,,✓,✓,287,
+V9,,V9.2,Server Communication Security,V9.2.4,"Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.",,✓,✓,299,
+V9,,V9.2,Server Communication Security,V9.2.5,Verify that backend TLS connection failures are logged.,,,✓,544,
+V10,,V10.1,Code Integrity,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,,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,,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,,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,,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,,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,,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,,V10.3,Application Integrity,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,,V10.3,Application Integrity,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,,V10.3,Application Integrity,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,,V11.1,Business Logic Security,V11.1.1,Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.,✓,✓,✓,841,
+V11,,V11.1,Business Logic Security,V11.1.2,"Verify that 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,,V11.1,Business Logic Security,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,,V11.1,Business Logic Security,V11.1.4,"Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.",✓,✓,✓,770,
+V11,,V11.1,Business Logic Security,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,,V11.1,Business Logic Security,V11.1.6,"Verify that the application does not suffer from ""Time Of Check to Time Of Use"" (TOCTOU) issues or other race conditions for sensitive operations.",,✓,✓,367,
+V11,,V11.1,Business Logic Security,V11.1.7,"Verify that 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,,V11.1,Business Logic Security,V11.1.8,Verify that the application has configurable alerting when automated attacks or unusual activity is detected.,,✓,✓,390,
+V12,,V12.1,File Upload,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,,V12.1,File Upload,V12.1.2,"Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.",,✓,✓,409,
+V12,,V12.1,File Upload,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,,V12.2,File Integrity,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,,V12.3,File Execution,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,,V12.3,File Execution,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,,V12.3,File Execution,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,,V12.3,File Execution,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,,V12.3,File Execution,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,,V12.3,File Execution,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,,V12.4,File Storage,V12.4.1,"Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.",✓,✓,✓,552,
+V12,,V12.4,File Storage,V12.4.2,Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.,✓,✓,✓,509,
+V12,,V12.5,File Download,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,,V12.5,File Download,V12.5.2,Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.,✓,✓,✓,434,
+V12,,V12.6,SSRF Protection,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,,V13.1,Generic Web Service Security,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,,V13.1,Generic Web Service Security,V13.1.2,"[DELETED, DUPLICATE OF 4.3.1]",,,,,
+V13,,V13.1,Generic Web Service Security,V13.1.3,"Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.",✓,✓,✓,598,
+V13,,V13.1,Generic Web Service Security,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,,V13.1,Generic Web Service Security,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,,V13.2,RESTful Web Service,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,,V13.2,RESTful Web Service,V13.2.2,Verify that JSON schema validation is in place and verified before accepting input.,✓,✓,✓,20,
+V13,,V13.2,RESTful Web Service,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,,V13.2,RESTful Web Service,V13.2.4,"[DELETED, DUPLICATE OF 11.1.4]",,,,,
+V13,,V13.2,RESTful Web Service,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,,V13.2,RESTful Web Service,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,,V13.3,SOAP Web Service,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,,V13.3,SOAP Web Service,V13.3.2,Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.,,✓,✓,345,
+V13,,V13.4,GraphQL,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,,V13.4,GraphQL,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,,V14.1,Build and Deploy,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,,V14.1,Build and Deploy,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,,V14.1,Build and Deploy,V14.1.3,Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.,,✓,✓,16,
+V14,,V14.1,Build and Deploy,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,,V14.1,Build and Deploy,V14.1.5,Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.,,,✓,,
+V14,,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,,V14.2,Dependency,V14.2.2,"Verify that all unneeded features, documentation, sample applications and configurations are removed.",✓,✓,✓,1002,
+V14,,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,,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,,V14.2,Dependency,V14.2.5,Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,,
+V14,,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,,V14.3,Unintended Security Disclosure,V14.3.1,"[DELETED, DUPLICATE OF 7.4.1]",,,,,
+V14,,V14.3,Unintended Security Disclosure,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,,V14.3,Unintended Security Disclosure,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,,V14.4,HTTP Security Headers,V14.4.1,"Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.",✓,✓,✓,173,
+V14,,V14.4,HTTP Security Headers,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,,V14.4,HTTP Security Headers,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,,V14.4,HTTP Security Headers,V14.4.4,Verify that all responses contain a X-Content-Type-Options: nosniff header.,✓,✓,✓,116,
+V14,,V14.4,HTTP Security Headers,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,,V14.4,HTTP Security Headers,V14.4.6,Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.,✓,✓,✓,116,
+V14,,V14.4,HTTP Security Headers,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.,✓,✓,✓,1021,
+V14,,V14.5,HTTP Request Header Validation,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,,V14.5,HTTP Request Header Validation,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,,V14.5,HTTP Request Header Validation,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,,V14.5,HTTP Request Header Validation,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/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.docx
similarity index 62%
rename from 4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx
rename to 4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.docx
index ae9b718019..16521d7398 100644
Binary files a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.docx and b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.docx differ
diff --git a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.flat.json b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.flat.json
new file mode 100644
index 0000000000..bdb118ed60
--- /dev/null
+++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.flat.json
@@ -0,0 +1,3150 @@
+{
+ "requirements": [
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1053",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1110",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.4",
+ "Description": "Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1059",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1059",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "637",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.1.7",
+ "Description": "Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "637",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "250",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "306",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "306",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "306",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.4.1",
+ "Description": "Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "602",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.4.2",
+ "Description": "[DELETED, NOT ACTIONABLE]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.4.3",
+ "Description": "[DELETED, DUPLICATE OF 4.1.3]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "284",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "275",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1029",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "502",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.5.3",
+ "Description": "Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "602",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.6.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.6.2",
+ "Description": "Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.6.3",
+ "Description": "Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.6.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.7.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1009",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.7.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.8.1",
+ "Description": "Verify that all sensitive data is identified and classified into protection levels.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.8.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.9.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "319",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.9.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "295",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.10.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "284",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.11.1",
+ "Description": "Verify the definition and documentation of all application components in terms of the business or security functions they provide.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1059",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.11.2",
+ "Description": "Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "362",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.11.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "367",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.12.1",
+ "Description": "[DELETED, DUPLICATE OF 12.4.1]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.12.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "646",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "923",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.2",
+ "Description": "Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "494",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.3",
+ "Description": "Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1104",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "265",
+ "NIST": ""
+ },
+ {
+ "Section": "V1",
+ "Name": "",
+ "Item": "V1.14.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "477",
+ "NIST": ""
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.2",
+ "Description": "Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.4",
+ "Description": "Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.5",
+ "Description": "Verify users can change their password.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "620",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.6",
+ "Description": "Verify that password change functionality requires the user's current and new password.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "620",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.8",
+ "Description": "Verify that a password strength meter is provided to help users set a stronger password.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.10",
+ "Description": "Verify that there are no periodic credential rotation or password history requirements.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "263",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.11",
+ "Description": "Verify that \"paste\" functionality, browser password helpers, and external password managers are permitted.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "521",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "307",
+ "NIST": "5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "304",
+ "NIST": "5.2.10"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "620",
+ "NIST": ""
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "5.2.5"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "319",
+ "NIST": "5.2.6"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.6",
+ "Description": "Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "5.2.8"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "5.2.9"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "330",
+ "NIST": "5.1.1.2 / A.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.3.2",
+ "Description": "Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "6.1.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.3.3",
+ "Description": "Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "6.1.4"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "916",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "916",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "916",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.4.4",
+ "Description": "Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "916",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "916",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "640",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.2",
+ "Description": "Verify password hints or knowledge-based authentication (so-called \"secret questions\") are not present.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "640",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "640",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.4",
+ "Description": "Verify shared or default accounts are not present (e.g. \"root\", \"admin\", or \"sa\").",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": "5.1.1.2 / A.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.5",
+ "Description": "Verify that if an authentication factor is changed or replaced, that the user is notified of this event.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "304",
+ "NIST": "6.1.2.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "640",
+ "NIST": "5.1.1.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "6.1.2.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.6.1",
+ "Description": "Verify that lookup secrets can be used only once.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "5.1.2.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.6.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "330",
+ "NIST": "5.1.2.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.6.3",
+ "Description": "Verify that lookup secrets are resistant to offline attacks, such as predictable values.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "310",
+ "NIST": "5.1.2.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.2",
+ "Description": "Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.4",
+ "Description": "Verify that the out of band authenticator and verifier communicates over a secure independent channel.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "523",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.5",
+ "Description": "Verify that the out of band verifier retains only a hashed version of the authentication code.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "256",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.7.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "310",
+ "NIST": "5.1.3.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.1",
+ "Description": "Verify that time-based OTPs have a defined lifetime before expiring.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "5.1.4.2 / 5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": "5.1.4.2 / 5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.3",
+ "Description": "Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": "5.1.4.2 / 5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.4",
+ "Description": "Verify that time-based OTP can be used only once within the validity period.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.4.2 / 5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.5.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "5.2.1"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.8.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "308",
+ "NIST": "5.2.3"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.9.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": "5.1.7.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.9.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "330",
+ "NIST": "5.1.7.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.9.3",
+ "Description": "Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "327",
+ "NIST": "5.1.7.2"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.10.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": "5.1.1.1"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.10.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "255",
+ "NIST": "5.1.1.1"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.10.3",
+ "Description": "Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "522",
+ "NIST": "5.1.1.1"
+ },
+ {
+ "Section": "V2",
+ "Name": "",
+ "Item": "V2.10.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "798",
+ "NIST": ""
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.1.1",
+ "Description": "Verify the application never reveals session tokens in URL parameters.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "598",
+ "NIST": ""
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.2.1",
+ "Description": "Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "384",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.2.2",
+ "Description": "Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "331",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "539",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.2.4",
+ "Description": "Verify that session tokens are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "331",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "7.2"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": ""
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "7.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.4.1",
+ "Description": "Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "614",
+ "NIST": "7.1.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.4.2",
+ "Description": "Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1004",
+ "NIST": "7.1.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": "7.1.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.4.4",
+ "Description": "Verify that cookie-based session tokens use the \"__Host-\" prefix so cookies are only sent to the host that initially set the cookie.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": "7.1.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.4.5",
+ "Description": "Verify that if the application is published under a domain name with other applications that set or use session cookies that might 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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": "7.1.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.5.1",
+ "Description": "Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "290",
+ "NIST": "7.1.2"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.5.2",
+ "Description": "Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "798",
+ "NIST": ""
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "345",
+ "NIST": ""
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.6.1",
+ "Description": "Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "7.2.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.6.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "613",
+ "NIST": "7.2.1"
+ },
+ {
+ "Section": "V3",
+ "Name": "",
+ "Item": "V3.7.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "306",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "602",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "639",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.1.4",
+ "Description": "[DELETED, DUPLICATE OF 4.1.3]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.1.5",
+ "Description": "Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "639",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "352",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.3.1",
+ "Description": "Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "419",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "548",
+ "NIST": ""
+ },
+ {
+ "Section": "V4",
+ "Name": "",
+ "Item": "V4.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "732",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "235",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "915",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "20",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.1.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, e-mail addresses, telephone numbers, 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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "20",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "601",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.2",
+ "Description": "Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "138",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.3",
+ "Description": "Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "147",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "95",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.5",
+ "Description": "Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "94",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "918",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "159",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "94",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "176",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "79",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "89",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "89",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.6",
+ "Description": "Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "830",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "90",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "78",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.9",
+ "Description": "Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "829",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "643",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "120",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.4.2",
+ "Description": "Verify that format strings do not take potentially hostile input, and are constant.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "134",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.4.3",
+ "Description": "Verify that sign, range, and input validation techniques are used to prevent integer overflows.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "190",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "502",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "611",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "502",
+ "NIST": ""
+ },
+ {
+ "Section": "V5",
+ "Name": "",
+ "Item": "V5.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "95",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "311",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "311",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "311",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.1",
+ "Description": "Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "310",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "327",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.3",
+ "Description": "Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "385",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "338",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "338",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.3.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "338",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "798",
+ "NIST": ""
+ },
+ {
+ "Section": "V6",
+ "Name": "",
+ "Item": "V6.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "320",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "532",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "532",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "778",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "778",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "778",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.3.1",
+ "Description": "Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "117",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.3.2",
+ "Description": "[DELETED, DUPLICATE OF 7.3.1]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.3.3",
+ "Description": "Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "200",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "210",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "544",
+ "NIST": ""
+ },
+ {
+ "Section": "V7",
+ "Name": "",
+ "Item": "V7.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "431",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.1",
+ "Description": "Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "524",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "524",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.3",
+ "Description": "Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "233",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "770",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.5",
+ "Description": "Verify that regular backups of important data are performed and that test restoration of data is performed.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "19",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.1.6",
+ "Description": "Verify that backups are stored securely to prevent data from being stolen or corrupted.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "19",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.2.1",
+ "Description": "Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "525",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.2.2",
+ "Description": "Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "922",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.2.3",
+ "Description": "Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "922",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "319",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.2",
+ "Description": "Verify that users have a method to remove or export their data on demand.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "212",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "200",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "532",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "226",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "327",
+ "NIST": ""
+ },
+ {
+ "Section": "V8",
+ "Name": "",
+ "Item": "V8.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.1.1",
+ "Description": "Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "319",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.1.2",
+ "Description": "Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.1.3",
+ "Description": "Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "326",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "295",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "319",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.2.3",
+ "Description": "Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "287",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.2.4",
+ "Description": "Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "299",
+ "NIST": ""
+ },
+ {
+ "Section": "V9",
+ "Name": "",
+ "Item": "V9.2.5",
+ "Description": "Verify that backend TLS connection failures are logged.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "544",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.1.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "749",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "359",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "272",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "507",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "511",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.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": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "511",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.2.6",
+ "Description": "Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "507",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "353",
+ "NIST": ""
+ },
+ {
+ "Section": "V10",
+ "Name": "",
+ "Item": "V10.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "350",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.1",
+ "Description": "Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "841",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.2",
+ "Description": "Verify that 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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "799",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.3",
+ "Description": "Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "770",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.4",
+ "Description": "Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "770",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "841",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.6",
+ "Description": "Verify that the application does not suffer from \"Time Of Check to Time Of Use\" (TOCTOU) issues or other race conditions for sensitive operations.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "367",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.7",
+ "Description": "Verify that 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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "754",
+ "NIST": ""
+ },
+ {
+ "Section": "V11",
+ "Name": "",
+ "Item": "V11.1.8",
+ "Description": "Verify that the application has configurable alerting when automated attacks or unusual activity is detected.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "390",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.1.1",
+ "Description": "Verify that the application will not accept large files that could fill up storage or cause a denial of service.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "400",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.1.2",
+ "Description": "Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "409",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "770",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.2.1",
+ "Description": "Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "434",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "22",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "73",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "98",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "641",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.5",
+ "Description": "Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "78",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.3.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "829",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.4.1",
+ "Description": "Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "552",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.4.2",
+ "Description": "Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "509",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "552",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.5.2",
+ "Description": "Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "434",
+ "NIST": ""
+ },
+ {
+ "Section": "V12",
+ "Name": "",
+ "Item": "V12.6.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "918",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.1.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.1.2",
+ "Description": "[DELETED, DUPLICATE OF 4.3.1]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.1.3",
+ "Description": "Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "598",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "434",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "650",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.2",
+ "Description": "Verify that JSON schema validation is in place and verified before accepting input.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "20",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "352",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.4",
+ "Description": "[DELETED, DUPLICATE OF 11.1.4]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "436",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "345",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "20",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.3.2",
+ "Description": "Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "345",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "770",
+ "NIST": ""
+ },
+ {
+ "Section": "V13",
+ "Name": "",
+ "Item": "V13.4.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "285",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "120",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.1.3",
+ "Description": "Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "16",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.1.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.1.5",
+ "Description": "Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.",
+ "L1": "",
+ "L2": "",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1026",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.2",
+ "Description": "Verify that all unneeded features, documentation, sample applications and configurations are removed.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1002",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "829",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "829",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.5",
+ "Description": "Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",
+ "L1": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.2.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "265",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.3.1",
+ "Description": "[DELETED, DUPLICATE OF 7.4.1]",
+ "L1": "",
+ "L2": "",
+ "L3": "",
+ "CWE": "",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.3.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "497",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.3.3",
+ "Description": "Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "200",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.1",
+ "Description": "Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "173",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1021",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.4",
+ "Description": "Verify that all responses contain a X-Content-Type-Options: nosniff header.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "523",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.6",
+ "Description": "Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.",
+ "L1": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "116",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.4.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "1021",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "749",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "346",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.5.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": "X",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "346",
+ "NIST": ""
+ },
+ {
+ "Section": "V14",
+ "Name": "",
+ "Item": "V14.5.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": "",
+ "L2": "X",
+ "L3": "X",
+ "CWE": "306",
+ "NIST": ""
+ }
+ ]
+}
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.3-en.json
similarity index 94%
rename from 4.0/docs_en/OWASP Application Security Verification Standard 4.0.2-en.json
rename to 4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.json
index 2a5c35f039..a0a38129e5 100644
--- 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.3-en.json
@@ -1,19 +1,19 @@
{
"Name": "Application Security Verification Standard Project",
"ShortName": "ASVS",
- "Version": "4.0.2",
+ "Version": "4.0.3",
"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",
+ "Name": "",
"Items": [
{
"Shortcode": "V1.1",
"Ordinal": 1,
- "Name": "Secure Software Development Lifecycle Requirements",
+ "Name": "Secure Software Development Lifecycle",
"Items": [
{
"Shortcode": "V1.1.1",
@@ -165,7 +165,7 @@
{
"Shortcode": "V1.2",
"Ordinal": 2,
- "Name": "Authentication Architectural Requirements",
+ "Name": "Authentication Architecture",
"Items": [
{
"Shortcode": "V1.2.1",
@@ -256,18 +256,18 @@
{
"Shortcode": "V1.3",
"Ordinal": 3,
- "Name": "Session Management Architectural Requirements",
+ "Name": "Session Management Architecture",
"Items": []
},
{
"Shortcode": "V1.4",
"Ordinal": 4,
- "Name": "Access Control Architectural Requirements",
+ "Name": "Access Control Architecture",
"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.",
+ "Description": "Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.",
"L1": {
"Required": false,
"Requirement": ""
@@ -288,43 +288,39 @@
{
"Shortcode": "V1.4.2",
"Ordinal": 2,
- "Description": "Verify that the chosen access control solution is flexible enough to meet the application's needs. ",
+ "Description": "[DELETED, NOT ACTIONABLE]",
"L1": {
"Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 284
- ],
+ "CWE": [],
"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.",
+ "Description": "[DELETED, DUPLICATE OF 4.1.3]",
"L1": {
"Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 272
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -374,12 +370,12 @@
{
"Shortcode": "V1.5",
"Ordinal": 5,
- "Name": "Input and Output Architectural Requirements",
+ "Name": "Input and Output Architecture",
"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. ",
+ "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": ""
@@ -465,7 +461,7 @@
{
"Shortcode": "V1.6",
"Ordinal": 6,
- "Name": "Cryptographic Architectural Requirements",
+ "Name": "Cryptographic Architecture",
"Items": [
{
"Shortcode": "V1.6.1",
@@ -556,12 +552,12 @@
{
"Shortcode": "V1.7",
"Ordinal": 7,
- "Name": "Errors, Logging and Auditing Architectural Requirements",
+ "Name": "Errors, Logging and Auditing Architecture",
"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))",
+ "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": ""
@@ -603,7 +599,7 @@
{
"Shortcode": "V1.8",
"Ordinal": 8,
- "Name": "Data Protection and Privacy Architectural Requirements",
+ "Name": "Data Protection and Privacy Architecture",
"Items": [
{
"Shortcode": "V1.8.1",
@@ -648,7 +644,7 @@
{
"Shortcode": "V1.9",
"Ordinal": 9,
- "Name": "Communications Architectural Requirements",
+ "Name": "Communications Architecture",
"Items": [
{
"Shortcode": "V1.9.1",
@@ -697,7 +693,7 @@
{
"Shortcode": "V1.10",
"Ordinal": 10,
- "Name": "Malicious Software Architectural Requirements",
+ "Name": "Malicious Software Architecture",
"Items": [
{
"Shortcode": "V1.10.1",
@@ -725,7 +721,7 @@
{
"Shortcode": "V1.11",
"Ordinal": 11,
- "Name": "Business Logic Architectural Requirements",
+ "Name": "Business Logic Architecture",
"Items": [
{
"Shortcode": "V1.11.1",
@@ -795,27 +791,25 @@
{
"Shortcode": "V1.12",
"Ordinal": 12,
- "Name": "Secure File Upload Architectural Requirements",
+ "Name": "Secure File Upload Architecture",
"Items": [
{
"Shortcode": "V1.12.1",
"Ordinal": 1,
- "Description": "Verify that user-uploaded files are stored outside of the web root.",
+ "Description": "[DELETED, DUPLICATE OF 12.4.1]",
"L1": {
"Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 552
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -844,13 +838,13 @@
{
"Shortcode": "V1.13",
"Ordinal": 13,
- "Name": "API Architectural Requirements",
+ "Name": "API Architecture",
"Items": []
},
{
"Shortcode": "V1.14",
"Ordinal": 14,
- "Name": "Configuration Architectural Requirements",
+ "Name": "Configuration Architecture",
"Items": [
{
"Shortcode": "V1.14.1",
@@ -984,12 +978,12 @@
"Shortcode": "V2",
"Ordinal": 2,
"ShortName": "Authentication",
- "Name": "Authentication Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V2.1",
"Ordinal": 1,
- "Name": "Password Security Requirements",
+ "Name": "Password Security",
"Items": [
{
"Shortcode": "V2.1.1",
@@ -1017,7 +1011,7 @@
{
"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))",
+ "Description": "Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": true,
"Requirement": ""
@@ -1272,7 +1266,7 @@
{
"Shortcode": "V2.2",
"Ordinal": 2,
- "Name": "General Authenticator Requirements",
+ "Name": "General Authenticator Security",
"Items": [
{
"Shortcode": "V2.2.1",
@@ -1441,7 +1435,7 @@
{
"Shortcode": "V2.3",
"Ordinal": 3,
- "Name": "Authenticator Lifecycle Requirements",
+ "Name": "Authenticator Lifecycle",
"Items": [
{
"Shortcode": "V2.3.1",
@@ -1470,7 +1464,7 @@
{
"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.",
+ "Description": "Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.",
"L1": {
"Required": false,
"Requirement": ""
@@ -1518,7 +1512,7 @@
{
"Shortcode": "V2.4",
"Ordinal": 4,
- "Name": "Credential Storage Requirements",
+ "Name": "Credential Storage",
"Items": [
{
"Shortcode": "V2.4.1",
@@ -1592,7 +1586,7 @@
{
"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))",
+ "Description": "Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": false,
"Requirement": ""
@@ -1640,7 +1634,7 @@
{
"Shortcode": "V2.5",
"Ordinal": 5,
- "Name": "Credential Recovery Requirements",
+ "Name": "Credential Recovery",
"Items": [
{
"Shortcode": "V2.5.1",
@@ -1809,7 +1803,7 @@
{
"Shortcode": "V2.6",
"Ordinal": 6,
- "Name": "Look-up Secret Verifier Requirements",
+ "Name": "Look-up Secret Verifier",
"Items": [
{
"Shortcode": "V2.6.1",
@@ -1885,7 +1879,7 @@
{
"Shortcode": "V2.7",
"Ordinal": 7,
- "Name": "Out of Band Verifier Requirements",
+ "Name": "Out of Band Verifier",
"Items": [
{
"Shortcode": "V2.7.1",
@@ -2030,7 +2024,7 @@
{
"Shortcode": "V2.8",
"Ordinal": 8,
- "Name": "Single or Multi-factor One Time Verifier Requirements",
+ "Name": "One Time Verifier",
"Items": [
{
"Shortcode": "V2.8.1",
@@ -2202,7 +2196,7 @@
{
"Shortcode": "V2.9",
"Ordinal": 9,
- "Name": "Cryptographic Software and Devices Verifier Requirements",
+ "Name": "Cryptographic Verifier",
"Items": [
{
"Shortcode": "V2.9.1",
@@ -2278,7 +2272,7 @@
{
"Shortcode": "V2.10",
"Ordinal": 10,
- "Name": "Service Authentication Requirements",
+ "Name": "Service Authentication",
"Items": [
{
"Shortcode": "V2.10.1",
@@ -2378,17 +2372,17 @@
"Shortcode": "V3",
"Ordinal": 3,
"ShortName": "Session",
- "Name": "Session Management Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V3.1",
"Ordinal": 1,
- "Name": "Fundamental Session Management Requirements",
+ "Name": "Fundamental Session Management Security",
"Items": [
{
"Shortcode": "V3.1.1",
"Ordinal": 1,
- "Description": "Verify the application never reveals session tokens in URL parameters. ",
+ "Description": "Verify the application never reveals session tokens in URL parameters.",
"L1": {
"Required": true,
"Requirement": ""
@@ -2411,7 +2405,7 @@
{
"Shortcode": "V3.2",
"Ordinal": 2,
- "Name": "Session Binding Requirements",
+ "Name": "Session Binding",
"Items": [
{
"Shortcode": "V3.2.1",
@@ -2485,7 +2479,7 @@
{
"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))",
+ "Description": "Verify that session tokens are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": false,
"Requirement": ""
@@ -2510,7 +2504,7 @@
{
"Shortcode": "V3.3",
"Ordinal": 3,
- "Name": "Session Logout and Timeout Requirements",
+ "Name": "Session Termination",
"Items": [
{
"Shortcode": "V3.3.1",
@@ -2681,7 +2675,7 @@
{
"Shortcode": "V3.4.4",
"Ordinal": 4,
- "Description": "Verify that cookie-based session tokens use \"__Host-\" prefix (see references) to provide session cookie confidentiality.",
+ "Description": "Verify that cookie-based session tokens use the \"__Host-\" prefix so cookies are only sent to the host that initially set the cookie.",
"L1": {
"Required": true,
"Requirement": ""
@@ -2704,7 +2698,7 @@
{
"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))",
+ "Description": "Verify that if the application is published under a domain name with other applications that set or use session cookies that might 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": ""
@@ -2734,7 +2728,7 @@
{
"Shortcode": "V3.5.1",
"Ordinal": 1,
- "Description": "Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. ",
+ "Description": "Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.",
"L1": {
"Required": false,
"Requirement": ""
@@ -2801,12 +2795,12 @@
{
"Shortcode": "V3.6",
"Ordinal": 6,
- "Name": "Re-authentication from a Federation or Assertion",
+ "Name": "Federated Re-authentication",
"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.",
+ "Description": "Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period.",
"L1": {
"Required": false,
"Requirement": ""
@@ -2885,7 +2879,7 @@
"Shortcode": "V4",
"Ordinal": 4,
"ShortName": "Access",
- "Name": "Access Control Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V4.1",
@@ -2958,22 +2952,20 @@
{
"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))",
+ "Description": "[DELETED, DUPLICATE OF 4.1.3]",
"L1": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 276
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -3124,12 +3116,12 @@
"Shortcode": "V5",
"Ordinal": 5,
"ShortName": "Validation",
- "Name": "Validation, Sanitization and Encoding Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V5.1",
"Ordinal": 1,
- "Name": "Input Validation Requirements",
+ "Name": "Input Validation",
"Items": [
{
"Shortcode": "V5.1.1",
@@ -3197,7 +3189,7 @@
{
"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))",
+ "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, e-mail addresses, telephone numbers, 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": ""
@@ -3241,7 +3233,7 @@
{
"Shortcode": "V5.2",
"Ordinal": 2,
- "Name": "Sanitization and Sandboxing Requirements",
+ "Name": "Sanitization and Sandboxing",
"Items": [
{
"Shortcode": "V5.2.1",
@@ -3416,7 +3408,7 @@
{
"Shortcode": "V5.3",
"Ordinal": 3,
- "Name": "Output Encoding and Injection Prevention Requirements",
+ "Name": "Output Encoding and Injection Prevention",
"Items": [
{
"Shortcode": "V5.3.1",
@@ -3526,7 +3518,7 @@
{
"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))",
+ "Description": "Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": true,
"Requirement": ""
@@ -3633,7 +3625,7 @@
{
"Shortcode": "V5.4",
"Ordinal": 4,
- "Name": "Memory, String, and Unmanaged Code Requirements",
+ "Name": "Memory, String, and Unmanaged Code",
"Items": [
{
"Shortcode": "V5.4.1",
@@ -3703,7 +3695,7 @@
{
"Shortcode": "V5.5",
"Ordinal": 5,
- "Name": "Deserialization Prevention Requirements",
+ "Name": "Deserialization Prevention",
"Items": [
{
"Shortcode": "V5.5.1",
@@ -3729,7 +3721,7 @@
{
"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. ",
+ "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": ""
@@ -3750,7 +3742,7 @@
{
"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). ",
+ "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": ""
@@ -3797,7 +3789,7 @@
"Shortcode": "V6",
"Ordinal": 6,
"ShortName": "Cryptography",
- "Name": "Stored Cryptography Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V6.1",
@@ -4169,12 +4161,12 @@
"Shortcode": "V7",
"Ordinal": 7,
"ShortName": "Error",
- "Name": "Error Handling and Logging Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V7.1",
"Ordinal": 1,
- "Name": "Log Content Requirements",
+ "Name": "Log Content",
"Items": [
{
"Shortcode": "V7.1.1",
@@ -4265,12 +4257,12 @@
{
"Shortcode": "V7.2",
"Ordinal": 2,
- "Name": "Log Processing Requirements",
+ "Name": "Log Processing",
"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. ",
+ "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": ""
@@ -4314,12 +4306,12 @@
{
"Shortcode": "V7.3",
"Ordinal": 3,
- "Name": "Log Protection Requirements",
+ "Name": "Log Protection",
"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))",
+ "Description": "Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": false,
"Requirement": ""
@@ -4340,22 +4332,20 @@
{
"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))",
+ "Description": "[DELETED, DUPLICATE OF 7.3.1]",
"L1": {
"Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 117
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -4408,7 +4398,7 @@
{
"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))",
+ "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": ""
@@ -4476,7 +4466,7 @@
"Shortcode": "V8",
"Ordinal": 8,
"ShortName": "Data",
- "Name": "Data Protection Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V8.1",
@@ -4640,7 +4630,7 @@
{
"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.",
+ "Description": "Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.",
"L1": {
"Required": true,
"Requirement": ""
@@ -4862,17 +4852,17 @@
"Shortcode": "V9",
"Ordinal": 9,
"ShortName": "Communications",
- "Name": "Communications Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V9.1",
"Ordinal": 1,
- "Name": "Client Communications Security Requirements",
+ "Name": "Client Communication Security",
"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))",
+ "Description": "Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": true,
"Requirement": ""
@@ -4893,7 +4883,7 @@
{
"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.",
+ "Description": "Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.",
"L1": {
"Required": true,
"Requirement": ""
@@ -4914,7 +4904,7 @@
{
"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.",
+ "Description": "Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.",
"L1": {
"Required": true,
"Requirement": ""
@@ -4937,7 +4927,7 @@
{
"Shortcode": "V9.2",
"Ordinal": 2,
- "Name": "Server Communications Security Requirements",
+ "Name": "Server Communication Security",
"Items": [
{
"Shortcode": "V9.2.1",
@@ -5052,12 +5042,12 @@
"Shortcode": "V10",
"Ordinal": 10,
"ShortName": "Malicious",
- "Name": "Malicious Code Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V10.1",
"Ordinal": 1,
- "Name": "Code Integrity Controls",
+ "Name": "Code Integrity",
"Items": [
{
"Shortcode": "V10.1.1",
@@ -5090,7 +5080,7 @@
{
"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.",
+ "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": ""
@@ -5218,7 +5208,7 @@
{
"Shortcode": "V10.3",
"Ordinal": 3,
- "Name": "Deployed Application Integrity Controls",
+ "Name": "Application Integrity",
"Items": [
{
"Shortcode": "V10.3.1",
@@ -5291,17 +5281,17 @@
"Shortcode": "V11",
"Ordinal": 11,
"ShortName": "BusLogic",
- "Name": "Business Logic Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V11.1",
"Ordinal": 1,
- "Name": "Business Logic Security Requirements",
+ "Name": "Business Logic Security",
"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.",
+ "Description": "Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.",
"L1": {
"Required": true,
"Requirement": ""
@@ -5322,7 +5312,7 @@
{
"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.",
+ "Description": "Verify that 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": ""
@@ -5364,7 +5354,7 @@
{
"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.",
+ "Description": "Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.",
"L1": {
"Required": true,
"Requirement": ""
@@ -5406,7 +5396,7 @@
{
"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.",
+ "Description": "Verify that 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": ""
@@ -5427,7 +5417,7 @@
{
"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))",
+ "Description": "Verify that 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": ""
@@ -5448,7 +5438,7 @@
{
"Shortcode": "V11.1.8",
"Ordinal": 8,
- "Description": "Verify the application has configurable alerting when automated attacks or unusual activity is detected.",
+ "Description": "Verify that the application has configurable alerting when automated attacks or unusual activity is detected.",
"L1": {
"Required": false,
"Requirement": ""
@@ -5474,12 +5464,12 @@
"Shortcode": "V12",
"Ordinal": 12,
"ShortName": "Files",
- "Name": "File and Resources Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V12.1",
"Ordinal": 1,
- "Name": "File Upload Requirements",
+ "Name": "File Upload",
"Items": [
{
"Shortcode": "V12.1.1",
@@ -5505,7 +5495,7 @@
{
"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.",
+ "Description": "Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.",
"L1": {
"Required": false,
"Requirement": ""
@@ -5549,7 +5539,7 @@
{
"Shortcode": "V12.2",
"Ordinal": 2,
- "Name": "File Integrity Requirements",
+ "Name": "File Integrity",
"Items": [
{
"Shortcode": "V12.2.1",
@@ -5577,7 +5567,7 @@
{
"Shortcode": "V12.3",
"Ordinal": 3,
- "Name": "File Execution Requirements",
+ "Name": "File Execution",
"Items": [
{
"Shortcode": "V12.3.1",
@@ -5624,7 +5614,7 @@
{
"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. ",
+ "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": ""
@@ -5710,12 +5700,12 @@
{
"Shortcode": "V12.4",
"Ordinal": 4,
- "Name": "File Storage Requirements",
+ "Name": "File Storage",
"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.",
+ "Description": "Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.",
"L1": {
"Required": true,
"Requirement": ""
@@ -5729,14 +5719,14 @@
"Requirement": ""
},
"CWE": [
- 922
+ 552
],
"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.",
+ "Description": "Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.",
"L1": {
"Required": true,
"Requirement": ""
@@ -5759,7 +5749,7 @@
{
"Shortcode": "V12.5",
"Ordinal": 5,
- "Name": "File Download Requirements",
+ "Name": "File Download",
"Items": [
{
"Shortcode": "V12.5.1",
@@ -5808,7 +5798,7 @@
{
"Shortcode": "V12.6",
"Ordinal": 6,
- "Name": "SSRF Protection Requirements",
+ "Name": "SSRF Protection",
"Items": [
{
"Shortcode": "V12.6.1",
@@ -5839,12 +5829,12 @@
"Shortcode": "V13",
"Ordinal": 13,
"ShortName": "API",
- "Name": "API and Web Service Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V13.1",
"Ordinal": 1,
- "Name": "Generic Web Service Security Verification Requirements",
+ "Name": "Generic Web Service Security",
"Items": [
{
"Shortcode": "V13.1.1",
@@ -5870,22 +5860,20 @@
{
"Shortcode": "V13.1.2",
"Ordinal": 2,
- "Description": "Verify that access to administration and management functions is limited to authorized administrators.",
+ "Description": "[DELETED, DUPLICATE OF 4.3.1]",
"L1": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 419
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -5956,7 +5944,7 @@
{
"Shortcode": "V13.2",
"Ordinal": 2,
- "Name": "RESTful Web Service Verification Requirements",
+ "Name": "RESTful Web Service",
"Items": [
{
"Shortcode": "V13.2.1",
@@ -6024,22 +6012,20 @@
{
"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.",
+ "Description": "[DELETED, DUPLICATE OF 11.1.4]",
"L1": {
"Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 770
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -6089,7 +6075,7 @@
{
"Shortcode": "V13.3",
"Ordinal": 3,
- "Name": "SOAP Web Service Verification Requirements",
+ "Name": "SOAP Web Service",
"Items": [
{
"Shortcode": "V13.3.1",
@@ -6138,7 +6124,7 @@
{
"Shortcode": "V13.4",
"Ordinal": 4,
- "Name": "GraphQL and other Web Service Data Layer Security Requirements",
+ "Name": "GraphQL",
"Items": [
{
"Shortcode": "V13.4.1",
@@ -6190,12 +6176,12 @@
"Shortcode": "V14",
"Ordinal": 14,
"ShortName": "Config",
- "Name": "Configuration Verification Requirements",
+ "Name": "",
"Items": [
{
"Shortcode": "V14.1",
"Ordinal": 1,
- "Name": "Build",
+ "Name": "Build and Deploy",
"Items": [
{
"Shortcode": "V14.1.1",
@@ -6327,7 +6313,7 @@
{
"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.",
+ "Description": "Verify that all unneeded features, documentation, sample applications and configurations are removed.",
"L1": {
"Required": true,
"Requirement": ""
@@ -6390,7 +6376,7 @@
{
"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))",
+ "Description": "Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",
"L1": {
"Required": false,
"Requirement": ""
@@ -6432,27 +6418,25 @@
{
"Shortcode": "V14.3",
"Ordinal": 3,
- "Name": "Unintended Security Disclosure Requirements",
+ "Name": "Unintended Security Disclosure",
"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.",
+ "Description": "[DELETED, DUPLICATE OF 7.4.1]",
"L1": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L2": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
"L3": {
- "Required": true,
+ "Required": false,
"Requirement": ""
},
- "CWE": [
- 209
- ],
+ "CWE": [],
"NIST": []
},
{
@@ -6502,12 +6486,12 @@
{
"Shortcode": "V14.4",
"Ordinal": 4,
- "Name": "HTTP Security Headers Requirements",
+ "Name": "HTTP Security Headers",
"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).",
+ "Description": "Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.",
"L1": {
"Required": true,
"Requirement": ""
@@ -6612,7 +6596,7 @@
{
"Shortcode": "V14.4.6",
"Ordinal": 6,
- "Description": "Verify that a suitable \"Referrer-Policy\" header is included, such as \"no-referrer\" or \"same-origin\".",
+ "Description": "Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.",
"L1": {
"Required": true,
"Requirement": ""
@@ -6647,7 +6631,7 @@
"Requirement": ""
},
"CWE": [
- 346
+ 1021
],
"NIST": []
}
@@ -6656,7 +6640,7 @@
{
"Shortcode": "V14.5",
"Ordinal": 5,
- "Name": "Validate HTTP Request Header Requirements",
+ "Name": "HTTP Request Header Validation",
"Items": [
{
"Shortcode": "V14.5.1",
diff --git a/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.xml b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.xml
new file mode 100644
index 0000000000..6fc3c4df4a
--- /dev/null
+++ b/4.0/docs_en/OWASP Application Security Verification Standard 4.0.3-en.xml
@@ -0,0 +1 @@
+Application Security Verification Standard ProjectASVS4.0.3The 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.- V11Architecture
- V1.11Secure Software Development Lifecycle
- V1.1.11Verify 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))FalseTrueTrue
- V1.1.22Verify 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.FalseTrueTrue
- 1053
- V1.1.33Verify 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"FalseTrueTrue
- 1110
- V1.1.44Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.FalseTrueTrue
- 1059
- V1.1.55Verify 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))FalseTrueTrue
- 1059
- V1.1.66Verify 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))FalseTrueTrue
- 637
- V1.1.77Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.FalseTrueTrue
- 637
- V1.22Authentication Architecture
- V1.2.11Verify 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))FalseTrueTrue
- 250
- V1.2.22Verify 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))FalseTrueTrue
- 306
- V1.2.33Verify 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.FalseTrueTrue
- 306
- V1.2.44Verify 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.FalseTrueTrue
- 306
- V1.33Session Management Architecture
- V1.44Access Control Architecture
- V1.4.11Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.FalseTrueTrue
- 602
- V1.4.22[DELETED, NOT ACTIONABLE]FalseFalseFalse
- V1.4.33[DELETED, DUPLICATE OF 4.1.3]FalseFalseFalse
- V1.4.44Verify 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))FalseTrueTrue
- 284
- V1.4.55Verify 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))FalseTrueTrue
- 275
- V1.55Input and Output Architecture
- V1.5.11Verify 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.FalseTrueTrue
- 1029
- V1.5.22Verify 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.FalseTrueTrue
- 502
- V1.5.33Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 602
- V1.5.44Verify 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))FalseTrueTrue
- 116
- V1.66Cryptographic Architecture
- V1.6.11Verify 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.FalseTrueTrue
- 320
- V1.6.22Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.FalseTrueTrue
- 320
- V1.6.33Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.FalseTrueTrue
- 320
- V1.6.44Verify 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.FalseTrueTrue
- 320
- V1.77Errors, Logging and Auditing Architecture
- V1.7.11Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 1009
- V1.7.22Verify 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))FalseTrueTrue
- V1.88Data Protection and Privacy Architecture
- V1.8.11Verify that all sensitive data is identified and classified into protection levels.FalseTrueTrue
- V1.8.22Verify 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.FalseTrueTrue
- V1.99Communications Architecture
- V1.9.11Verify 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))FalseTrueTrue
- 319
- V1.9.22Verify 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.FalseTrueTrue
- 295
- V1.1010Malicious Software Architecture
- V1.10.11Verify 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.FalseTrueTrue
- 284
- V1.1111Business Logic Architecture
- V1.11.11Verify the definition and documentation of all application components in terms of the business or security functions they provide.FalseTrueTrue
- 1059
- V1.11.22Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.FalseTrueTrue
- 362
- V1.11.33Verify 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.FalseFalseTrue
- 367
- V1.1212Secure File Upload Architecture
- V1.12.11[DELETED, DUPLICATE OF 12.4.1]FalseFalseFalse
- V1.12.22Verify 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.FalseTrueTrue
- 646
- V1.1313API Architecture
- V1.1414Configuration Architecture
- V1.14.11Verify 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.FalseTrueTrue
- 923
- V1.14.22Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.FalseTrueTrue
- 494
- V1.14.33Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.FalseTrueTrue
- 1104
- V1.14.44Verify 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.FalseTrueTrue
- V1.14.55Verify 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))FalseTrueTrue
- 265
- V1.14.66Verify 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.FalseTrueTrue
- 477
- V22Authentication
- V2.11Password Security
- V2.1.11Verify 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))TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.22Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.33Verify 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))TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.44Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.55Verify users can change their password.TrueTrueTrue
- 620
- 5.1.1.2
- V2.1.66Verify that password change functionality requires the user's current and new password.TrueTrueTrue
- 620
- 5.1.1.2
- V2.1.77Verify 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))TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.88Verify that a password strength meter is provided to help users set a stronger password.TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.99Verify 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))TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.1010Verify that there are no periodic credential rotation or password history requirements.TrueTrueTrue
- 263
- 5.1.1.2
- V2.1.1111Verify that "paste" functionality, browser password helpers, and external password managers are permitted.TrueTrueTrue
- 521
- 5.1.1.2
- V2.1.1212Verify 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.TrueTrueTrue
- 521
- 5.1.1.2
- V2.22General Authenticator Security
- V2.2.11Verify 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.TrueTrueTrue
- 307
- 5.2.2
- 5.1.1.2
- 5.1.4.2
- 5.1.5.2
- V2.2.22Verify 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.TrueTrueTrue
- 304
- 5.2.10
- V2.2.33Verify 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.TrueTrueTrue
- 620
- V2.2.44Verify 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.FalseFalseTrue
- 308
- 5.2.5
- V2.2.55Verify that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.FalseFalseTrue
- 319
- 5.2.6
- V2.2.66Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.FalseFalseTrue
- 308
- 5.2.8
- V2.2.77Verify 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.FalseFalseTrue
- 308
- 5.2.9
- V2.33Authenticator Lifecycle
- V2.3.11Verify 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.TrueTrueTrue
- 330
- 5.1.1.2
- A.3
- V2.3.22Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.FalseTrueTrue
- 308
- 6.1.3
- V2.3.33Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.FalseTrueTrue
- 287
- 6.1.4
- V2.44Credential Storage
- V2.4.11Verify 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))FalseTrueTrue
- 916
- 5.1.1.2
- V2.4.22Verify 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))FalseTrueTrue
- 916
- 5.1.1.2
- V2.4.33Verify 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))FalseTrueTrue
- 916
- 5.1.1.2
- V2.4.44Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 916
- 5.1.1.2
- V2.4.55Verify 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).FalseTrueTrue
- 916
- 5.1.1.2
- V2.55Credential Recovery
- V2.5.11Verify 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))TrueTrueTrue
- 640
- 5.1.1.2
- V2.5.22Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.TrueTrueTrue
- 640
- 5.1.1.2
- V2.5.33Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 640
- 5.1.1.2
- V2.5.44Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").TrueTrueTrue
- 16
- 5.1.1.2
- A.3
- V2.5.55Verify that if an authentication factor is changed or replaced, that the user is notified of this event.TrueTrueTrue
- 304
- 6.1.2.3
- V2.5.66Verify 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))TrueTrueTrue
- 640
- 5.1.1.2
- V2.5.77Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.FalseTrueTrue
- 308
- 6.1.2.3
- V2.66Look-up Secret Verifier
- V2.6.11Verify that lookup secrets can be used only once.FalseTrueTrue
- 308
- 5.1.2.2
- V2.6.22Verify 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.FalseTrueTrue
- 330
- 5.1.2.2
- V2.6.33Verify that lookup secrets are resistant to offline attacks, such as predictable values.FalseTrueTrue
- 310
- 5.1.2.2
- V2.77Out of Band Verifier
- V2.7.11Verify 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.TrueTrueTrue
- 287
- 5.1.3.2
- V2.7.22Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.TrueTrueTrue
- 287
- 5.1.3.2
- V2.7.33Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.TrueTrueTrue
- 287
- 5.1.3.2
- V2.7.44Verify that the out of band authenticator and verifier communicates over a secure independent channel.TrueTrueTrue
- 523
- 5.1.3.2
- V2.7.55Verify that the out of band verifier retains only a hashed version of the authentication code.FalseTrueTrue
- 256
- 5.1.3.2
- V2.7.66Verify 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).FalseTrueTrue
- 310
- 5.1.3.2
- V2.88One Time Verifier
- V2.8.11Verify that time-based OTPs have a defined lifetime before expiring.TrueTrueTrue
- 613
- 5.1.4.2
- 5.1.5.2
- V2.8.22Verify 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.FalseTrueTrue
- 320
- 5.1.4.2
- 5.1.5.2
- V2.8.33Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.FalseTrueTrue
- 326
- 5.1.4.2
- 5.1.5.2
- V2.8.44Verify that time-based OTP can be used only once within the validity period.FalseTrueTrue
- 287
- 5.1.4.2
- 5.1.5.2
- V2.8.55Verify 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.FalseTrueTrue
- 287
- 5.1.5.2
- V2.8.66Verify 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.FalseTrueTrue
- 613
- 5.2.1
- V2.8.77Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.FalseTrueOptionalTrue
- 308
- 5.2.3
- V2.99Cryptographic Verifier
- V2.9.11Verify 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.FalseTrueTrue
- 320
- 5.1.7.2
- V2.9.22Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.FalseTrueTrue
- 330
- 5.1.7.2
- V2.9.33Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.FalseTrueTrue
- 327
- 5.1.7.2
- V2.1010Service Authentication
- V2.10.11Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.FalseTrueOS assistedTrueHSM
- 287
- 5.1.1.1
- V2.10.22Verify 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).FalseTrueOS assistedTrueHSM
- 255
- 5.1.1.1
- V2.10.33Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.FalseTrueOS assistedTrueHSM
- 522
- 5.1.1.1
- V2.10.44Verify 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.FalseTrueOS assistedTrueHSM
- 798
- V33Session
- V3.11Fundamental Session Management Security
- V3.1.11Verify the application never reveals session tokens in URL parameters.TrueTrueTrue
- 598
- V3.22Session Binding
- V3.2.11Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 384
- 7.1
- V3.2.22Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 331
- 7.1
- V3.2.33Verify 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.TrueTrueTrue
- 539
- 7.1
- V3.2.44Verify that session tokens are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 331
- 7.1
- V3.33Session Termination
- V3.3.11Verify 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))TrueTrueTrue
- 613
- 7.1
- V3.3.22If 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))True30 daysTrue12 hours or 30 minutes of inactivity, 2FA optionalTrue12 hours or 15 minutes of inactivity, with 2FA
- 613
- 7.2
- V3.3.33Verify 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.FalseTrueTrue
- 613
- V3.3.44Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.FalseTrueTrue
- 613
- 7.1
- V3.44Cookie-based Session Management
- V3.4.11Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 614
- 7.1.1
- V3.4.22Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 1004
- 7.1.1
- V3.4.33Verify 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))TrueTrueTrue
- 16
- 7.1.1
- V3.4.44Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie.TrueTrueTrue
- 16
- 7.1.1
- V3.4.55Verify that if the application is published under a domain name with other applications that set or use session cookies that might 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))TrueTrueTrue
- 16
- 7.1.1
- V3.55Token-based Session Management
- V3.5.11Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.FalseTrueTrue
- 290
- 7.1.2
- V3.5.22Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.FalseTrueTrue
- 798
- V3.5.33Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.FalseTrueTrue
- 345
- V3.66Federated Re-authentication
- V3.6.11Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period.FalseFalseTrue
- 613
- 7.2.1
- V3.6.22Verify 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.FalseFalseTrue
- 613
- 7.2.1
- V3.77Defenses Against Session Management Exploits
- V3.7.11Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.TrueTrueTrue
- 306
- V44Access
- V4.11General Access Control Design
- V4.1.11Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.TrueTrueTrue
- 602
- V4.1.22Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.TrueTrueTrue
- 639
- V4.1.33Verify 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))TrueTrueTrue
- 285
- V4.1.44[DELETED, DUPLICATE OF 4.1.3]FalseFalseFalse
- V4.1.55Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 285
- V4.22Operation Level Access Control
- V4.2.11Verify 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.TrueTrueTrue
- 639
- V4.2.22Verify 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.TrueTrueTrue
- 352
- V4.33Other Access Control Considerations
- V4.3.11Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.TrueTrueTrue
- 419
- V4.3.22Verify 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.TrueTrueTrue
- 548
- V4.3.33Verify 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.FalseTrueTrue
- 732
- V55Validation
- V5.11Input Validation
- V5.1.11Verify 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).TrueTrueTrue
- 235
- V5.1.22Verify 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))TrueTrueTrue
- 915
- V5.1.33Verify 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))TrueTrueTrue
- 20
- V5.1.44Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, 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))TrueTrueTrue
- 20
- V5.1.55Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.TrueTrueTrue
- 601
- V5.22Sanitization and Sandboxing
- V5.2.11Verify 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))TrueTrueTrue
- 116
- V5.2.22Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.TrueTrueTrue
- 138
- V5.2.33Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.TrueTrueTrue
- 147
- V5.2.44Verify 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.TrueTrueTrue
- 95
- V5.2.55Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.TrueTrueTrue
- 94
- V5.2.66Verify 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.TrueTrueTrue
- 918
- V5.2.77Verify 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.TrueTrueTrue
- 159
- V5.2.88Verify 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.TrueTrueTrue
- 94
- V5.33Output Encoding and Injection Prevention
- V5.3.11Verify 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))TrueTrueTrue
- 116
- V5.3.22Verify 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))TrueTrueTrue
- 176
- V5.3.33Verify 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))TrueTrueTrue
- 79
- V5.3.44Verify 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))TrueTrueTrue
- 89
- V5.3.55Verify 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))TrueTrueTrue
- 89
- V5.3.66Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 830
- V5.3.77Verify 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))TrueTrueTrue
- 90
- V5.3.88Verify 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))TrueTrueTrue
- 78
- V5.3.99Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.TrueTrueTrue
- 829
- V5.3.1010Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 643
- V5.44Memory, String, and Unmanaged Code
- V5.4.11Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.FalseTrueTrue
- 120
- V5.4.22Verify that format strings do not take potentially hostile input, and are constant.FalseTrueTrue
- 134
- V5.4.33Verify that sign, range, and input validation techniques are used to prevent integer overflows.FalseTrueTrue
- 190
- V5.55Deserialization Prevention
- V5.5.11Verify 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))TrueTrueTrue
- 502
- V5.5.22Verify 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.TrueTrueTrue
- 611
- V5.5.33Verify 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).TrueTrueTrue
- 502
- V5.5.44Verify 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.TrueTrueTrue
- 95
- V66Cryptography
- V6.11Data Classification
- V6.1.11Verify 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.FalseTrueTrue
- 311
- V6.1.22Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.FalseTrueTrue
- 311
- V6.1.33Verify 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.FalseTrueTrue
- 311
- V6.22Algorithms
- V6.2.11Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.TrueTrueTrue
- 310
- V6.2.22Verify 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))FalseTrueTrue
- 327
- V6.2.33Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.FalseTrueTrue
- 326
- V6.2.44Verify 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))FalseTrueTrue
- 326
- V6.2.55Verify 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.FalseTrueTrue
- 326
- V6.2.66Verify 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.FalseTrueTrue
- 326
- V6.2.77Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.FalseFalseTrue
- 326
- V6.2.88Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.FalseFalseTrue
- 385
- V6.33Random Values
- V6.3.11Verify 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.FalseTrueTrue
- 338
- V6.3.22Verify 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.FalseTrueTrue
- 338
- V6.3.33Verify 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.FalseFalseTrue
- 338
- V6.44Secret Management
- V6.4.11Verify 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))FalseTrueTrue
- 798
- V6.4.22Verify 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))FalseTrueTrue
- 320
- V77Error
- V7.11Log Content
- V7.1.11Verify 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))TrueTrueTrue
- 532
- V7.1.22Verify 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))TrueTrueTrue
- 532
- V7.1.33Verify 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))FalseTrueTrue
- 778
- V7.1.44Verify 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))FalseTrueTrue
- 778
- V7.22Log Processing
- V7.2.11Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations.FalseTrueTrue
- 778
- V7.2.22Verify 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.FalseTrueTrue
- 285
- V7.33Log Protection
- V7.3.11Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 117
- V7.3.22[DELETED, DUPLICATE OF 7.3.1]FalseFalseFalse
- V7.3.33Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 200
- V7.3.44Verify 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))FalseTrueTrue
- V7.44Error Handling
- V7.4.11Verify 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))TrueTrueTrue
- 210
- V7.4.22Verify 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))FalseTrueTrue
- 544
- V7.4.33Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 431
- V88Data
- V8.11General Data Protection
- V8.1.11Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.FalseTrueTrue
- 524
- V8.1.22Verify 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.FalseTrueTrue
- 524
- V8.1.33Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.FalseTrueTrue
- 233
- V8.1.44Verify 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.FalseTrueTrue
- 770
- V8.1.55Verify that regular backups of important data are performed and that test restoration of data is performed.FalseFalseTrue
- 19
- V8.1.66Verify that backups are stored securely to prevent data from being stolen or corrupted.FalseFalseTrue
- 19
- V8.22Client-side Data Protection
- V8.2.11Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.TrueTrueTrue
- 525
- V8.2.22Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.TrueTrueTrue
- 922
- V8.2.33Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.TrueTrueTrue
- 922
- V8.33Sensitive Private Data
- V8.3.11Verify 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.TrueTrueTrue
- 319
- V8.3.22Verify that users have a method to remove or export their data on demand.TrueTrueTrue
- 212
- V8.3.33Verify 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.TrueTrueTrue
- 285
- V8.3.44Verify 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))TrueTrueTrue
- 200
- V8.3.55Verify 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.FalseTrueTrue
- 532
- V8.3.66Verify 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.FalseTrueTrue
- 226
- V8.3.77Verify 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))FalseTrueTrue
- 327
- V8.3.88Verify 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.FalseTrueTrue
- 285
- V99Communications
- V9.11Client Communication Security
- V9.1.11Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))TrueTrueTrue
- 319
- V9.1.22Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.TrueTrueTrue
- 326
- V9.1.33Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.TrueTrueTrue
- 326
- V9.22Server Communication Security
- V9.2.11Verify 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.FalseTrueTrue
- 295
- V9.2.22Verify 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.FalseTrueTrue
- 319
- V9.2.33Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.FalseTrueTrue
- 287
- V9.2.44Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.FalseTrueTrue
- 299
- V9.2.55Verify that backend TLS connection failures are logged.FalseFalseTrue
- 544
- V1010Malicious
- V10.11Code Integrity
- V10.1.11Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.FalseFalseTrue
- 749
- V10.22Malicious Code Search
- V10.2.11Verify 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.FalseTrueTrue
- 359
- V10.2.22Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.FalseTrueTrue
- 272
- V10.2.33Verify 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.FalseFalseTrue
- 507
- V10.2.44Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.FalseFalseTrue
- 511
- V10.2.55Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.FalseFalseTrue
- 511
- V10.2.66Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.FalseFalseTrue
- 507
- V10.33Application Integrity
- V10.3.11Verify 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.TrueTrueTrue
- 16
- V10.3.22Verify 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.TrueTrueTrue
- 353
- V10.3.33Verify 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.TrueTrueTrue
- 350
- V1111BusLogic
- V11.11Business Logic Security
- V11.1.11Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.TrueTrueTrue
- 841
- V11.1.22Verify that 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.TrueTrueTrue
- 799
- V11.1.33Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.TrueTrueTrue
- 770
- V11.1.44Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.TrueTrueTrue
- 770
- V11.1.55Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.TrueTrueTrue
- 841
- V11.1.66Verify that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.FalseTrueTrue
- 367
- V11.1.77Verify that 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))FalseTrueTrue
- 754
- V11.1.88Verify that the application has configurable alerting when automated attacks or unusual activity is detected.FalseTrueTrue
- 390
- V1212Files
- V12.11File Upload
- V12.1.11Verify that the application will not accept large files that could fill up storage or cause a denial of service.TrueTrueTrue
- 400
- V12.1.22Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.FalseTrueTrue
- 409
- V12.1.33Verify 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.FalseTrueTrue
- 770
- V12.22File Integrity
- V12.2.11Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.FalseTrueTrue
- 434
- V12.33File Execution
- V12.3.11Verify 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.TrueTrueTrue
- 22
- V12.3.22Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).TrueTrueTrue
- 73
- V12.3.33Verify 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.TrueTrueTrue
- 98
- V12.3.44Verify 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.TrueTrueTrue
- 641
- V12.3.55Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.TrueTrueTrue
- 78
- V12.3.66Verify 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.FalseTrueTrue
- 829
- V12.44File Storage
- V12.4.11Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.TrueTrueTrue
- 552
- V12.4.22Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.TrueTrueTrue
- 509
- V12.55File Download
- V12.5.11Verify 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.TrueTrueTrue
- 552
- V12.5.22Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.TrueTrueTrue
- 434
- V12.66SSRF Protection
- V12.6.11Verify 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.TrueTrueTrue
- 918
- V1313API
- V13.11Generic Web Service Security
- V13.1.11Verify 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.TrueTrueTrue
- 116
- V13.1.22[DELETED, DUPLICATE OF 4.3.1]FalseFalseFalse
- V13.1.33Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.TrueTrueTrue
- 598
- V13.1.44Verify 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.FalseTrueTrue
- 285
- V13.1.55Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).FalseTrueTrue
- 434
- V13.22RESTful Web Service
- V13.2.11Verify 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.TrueTrueTrue
- 650
- V13.2.22Verify that JSON schema validation is in place and verified before accepting input.TrueTrueTrue
- 20
- V13.2.33Verify 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.TrueTrueTrue
- 352
- V13.2.44[DELETED, DUPLICATE OF 11.1.4]FalseFalseFalse
- V13.2.55Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.FalseTrueTrue
- 436
- V13.2.66Verify 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.FalseTrueTrue
- 345
- V13.33SOAP Web Service
- V13.3.11Verify 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.TrueTrueTrue
- 20
- V13.3.22Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.FalseTrueTrue
- 345
- V13.44GraphQL
- V13.4.11Verify 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.FalseTrueTrue
- 770
- V13.4.22Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.FalseTrueTrue
- 285
- V1414Config
- V14.11Build and Deploy
- V14.1.11Verify 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.FalseTrueTrue
- V14.1.22Verify 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.FalseTrueTrue
- 120
- V14.1.33Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.FalseTrueTrue
- 16
- V14.1.44Verify 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.FalseTrueTrue
- V14.1.55Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.FalseFalseTrue
- V14.22Dependency
- V14.2.11Verify 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))TrueTrueTrue
- 1026
- V14.2.22Verify that all unneeded features, documentation, sample applications and configurations are removed.TrueTrueTrue
- 1002
- V14.2.33Verify 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.TrueTrueTrue
- 829
- V14.2.44Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- 829
- V14.2.55Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))FalseTrueTrue
- V14.2.66Verify 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))FalseTrueTrue
- 265
- V14.33Unintended Security Disclosure
- V14.3.11[DELETED, DUPLICATE OF 7.4.1]FalseFalseFalse
- V14.3.22Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.TrueTrueTrue
- 497
- V14.3.33Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.TrueTrueTrue
- 200
- V14.44HTTP Security Headers
- V14.4.11Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.TrueTrueTrue
- 173
- V14.4.22Verify that all API responses contain a Content-Disposition: attachment; filename="api.json" header (or other appropriate filename for the content type).TrueTrueTrue
- 116
- V14.4.33Verify 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.TrueTrueTrue
- 1021
- V14.4.44Verify that all responses contain a X-Content-Type-Options: nosniff header.TrueTrueTrue
- 116
- V14.4.55Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.TrueTrueTrue
- 523
- V14.4.66Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.TrueTrueTrue
- 116
- V14.4.77Verify 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.TrueTrueTrue
- 1021
- V14.55HTTP Request Header Validation
- V14.5.11Verify 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.TrueTrueTrue
- 749
- V14.5.22Verify 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.TrueTrueTrue
- 346
- V14.5.33Verify 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.TrueTrueTrue
- 346
- V14.5.44Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.FalseTrueTrue
- 306
diff --git a/4.0/en/0x00-Header.md b/4.0/en/0x00-Header.md
index 0209a4197d..da277ff782 100644
--- a/4.0/en/0x00-Header.md
+++ b/4.0/en/0x00-Header.md
@@ -2,8 +2,8 @@
-# Application Security Verification Standard 4.0.2
+# Application Security Verification Standard 4.0.3
## Final
-October 2020
+October 2021
diff --git a/4.0/en/0x01-Frontispiece.md b/4.0/en/0x01-Frontispiece.md
index 8542c124d3..08a7d39193 100644
--- a/4.0/en/0x01-Frontispiece.md
+++ b/4.0/en/0x01-Frontispiece.md
@@ -6,41 +6,46 @@ The Application Security Verification Standard is a list of application security
## Copyright and License
-Version 4.0.2, October 2020
+Version 4.0.3, October 2021
-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.
+Copyright © 2008-2021 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 | |
+| Josh C Grossman | Elar Lang | |
## Major Contributors
| | | |
|---------------- |---------------- |------------------- |
-| Abhay Bhargav | Benedikt Bauer | Elar Lang |
-| Osama Elnaggar | Ron Perris | Tonimir Kisasondi |
+| Abhay Bhargav | Benedikt Bauer | Osama Elnaggar |
+| Ralph Andalis | Ron Perris | Sjoerd Langkemper |
+| Tonimir Kisasondi | | |
## Other Contributors and Reviewers
-| | | | | |
-|---------------- |------------------ |--------------------- |-------------------- |--------------------- |
-| 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.
+| | | | | |
+| ------------------- | ------------------ | ----------------- | ---------------- | ----------------- |
+| Aaron Guzman | Alina Vasiljeva | Andreas Kurtz | Anthony Weems | Barbara Schachner |
+| Christian Heinrich | Christopher Loessl | Clément Notin | Dan Cornell | Daniël Geerts |
+| David Clarke | David Johansson | David Quisenberry | Elie Saad | Erlend Oftedal |
+| Fatih Ersinadim | Filip van Laenen | Geoff Baskwill | Glenn ten Cate | Grant Ongers |
+| hello7s | Isaac Lewis | Jacob Salassi | James Sulinski | Jason Axley |
+| Jason Morrow | Javier Dominguez | Jet Anderson | jeurgen | Jim Newman |
+| Jonathan Schnittger | Joseph Kerby | Kelby Ludwig | Lars Haulin | Lewis Ardern |
+| Liam Smit | lyz-code | Marc Aubry | Marco Schnüriger | Mark Burnett |
+| Philippe De Ryck | 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 | Tim Hemel | Tomasz Wrobel |
+| Vincent De Schutter | | | | |
+
+
+
+If a credit is missing from the 4.0.3 credit list above, please log a ticket at GitHub to be recognized in future 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 47dd497b99..f7c2d55856 100644
--- a/4.0/en/0x02-Preface.md
+++ b/4.0/en/0x02-Preface.md
@@ -2,7 +2,7 @@
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.
+Version 4.0.3 is the third minor patch to v4.0 intended to fix spelling errors and make requirements clearer without making breaking changes such as materially changing requirements, strengthening requirements or adding requirements. However, some requirements may have been slightly weakened where we felt appropriate and some entirely redundant requirements have been removed (but without renumbering).
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.
@@ -24,7 +24,7 @@ We set out to ensure that the ASVS 4.0 Level 1 is a comprehensive superset of PC
We have completed the shift of the ASVS from monolithic server-side only controls, to providing security controls for all modern applications and APIs. In the days of functional programming, server-less API, mobile, cloud, containers, CI/CD and DevSecOps, federation and more, we cannot continue to ignore modern application architecture. Modern applications are designed very differently to those built when the original ASVS was released in 2009. The ASVS must always look far into the future so that we provide sound advice for our primary audience - developers. We have clarified or dropped any requirement that assumes that applications are executed on systems owned by a single organization.
-Due to the size of the ASVS 4.0, as well as our desire to become the baseline ASVS for all other ASVS efforts, we have retired the mobile section, in favor of the Mobile Application Security Verification Standard (MASVS). The Internet of Things appendix will appear in a future IoT ASVS care of the OWASP Internet of Things Project. We have included an early preview of the IoT ASVS in Appendix C. We thank both the OWASP Mobile Team and OWASP IoT Project Team for their support of the ASVS, and look forward to working with them in the future to provide complementary standards.
+Due to the size of the ASVS 4.0, as well as our desire to become the baseline ASVS for all other ASVS efforts, we have retired the mobile chapter, in favor of the Mobile Application Security Verification Standard (MASVS). The Internet of Things appendix will appear in a future IoT ASVS care of the OWASP Internet of Things Project. We have included an early preview of the IoT ASVS in Appendix C. We thank both the OWASP Mobile Team and OWASP IoT Project Team for their support of the ASVS, and look forward to working with them in the future to provide complementary standards.
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.
diff --git a/4.0/en/0x03-Using-ASVS.md b/4.0/en/0x03-Using-ASVS.md
index 55f8f7f17f..cd75de8143 100644
--- a/4.0/en/0x03-Using-ASVS.md
+++ b/4.0/en/0x03-Using-ASVS.md
@@ -53,7 +53,7 @@ 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 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).
+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), authorization, and auditing (logging).
## Applying ASVS in Practice
@@ -65,12 +65,12 @@ Organizations are strongly encouraged to look deeply at their unique risk charac
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:
+- The `` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architecture` 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.3 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-`.)
+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.3-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architecture' section of the 'Architecture' chapter from version 4.0.3. (This could be summarized as `v-`.)
Note: The `v` preceding the version portion is to be lower case.
diff --git a/4.0/en/0x10-V1-Architecture.md b/4.0/en/0x10-V1-Architecture.md
index 378df182dd..c5e3fa67dc 100644
--- a/4.0/en/0x10-V1-Architecture.md
+++ b/4.0/en/0x10-V1-Architecture.md
@@ -1,4 +1,4 @@
-# V1: Architecture, Design and Threat Modeling Requirements
+# V1 Architecture, Design and Threat Modeling
## Control Objective
@@ -10,21 +10,21 @@ If developers had invested in a single, secure identity provider model, such as
In this chapter, the ASVS covers off the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Each of these security principles must be built in and be innate to all applications. It is critical to "shift left", starting with developer enablement with secure coding checklists, mentoring and training, coding and testing, building, deployment, configuration, and operations, and finishing with follow up independent testing to assure that all of the security controls are present and functional. The last step used to be everything we did as an industry, but that is no longer sufficient when developers push code into production tens or hundreds of times a day. Application security professionals must keep up with agile techniques, which means adopting developer tools, learning to code, and working with developers rather than criticizing the project months after everyone else has moved on.
-## V1.1 Secure Software Development Lifecycle Requirements
+## V1.1 Secure Software Development Lifecycle
| # | 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://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.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://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
+## V1.2 Authentication Architecture
-When designing authentication, it doesn't matter if you have strong hardware enabled multi-factor authentication if an attacker can reset an account by calling a call center and answering commonly known questions. When proofing identity, all authentication pathways must have the same strength.
+When designing authentication, it doesn't matter if you have strong hardware enabled multi-factor authentication if an attacker can reset an account by calling a call center and answering commonly known questions. When proving identity, all authentication pathways must have the same strength.
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
@@ -33,34 +33,34 @@ When designing authentication, it doesn't matter if you have strong hardware ena
| **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 |
-## V1.3 Session Management Architectural Requirements
+## V1.3 Session Management Architecture
This is a placeholder for future architectural requirements.
-## V1.4 Access Control Architectural Requirements
+## V1.4 Access Control Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 284 |
+| **1.4.1** | Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client. | | ✓ | ✓ | 602 |
+| **1.4.2** | [DELETED, NOT ACTIONABLE] | | | | |
+| **1.4.3** | [DELETED, DUPLICATE OF 4.1.3] | | | | |
+| **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
+## V1.5 Input and Output Architecture
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.
+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.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://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
+## V1.6 Cryptographic Architecture
Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Encrypting everything is wasteful, not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start.
@@ -73,34 +73,34 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi
| **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 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
+## V1.7 Errors, Logging and Auditing Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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.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
+## V1.8 Data Protection and Privacy Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **1.8.1** | Verify that all sensitive data is identified and classified into protection levels. | | ✓ | ✓ | |
| **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. | | ✓ | ✓ | |
-## V1.9 Communications Architectural Requirements
+## V1.9 Communications Architecture
| # | 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://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 |
+| **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
+## V1.10 Malicious Software Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | | ✓ | ✓ | 284 |
-## V1.11 Business Logic Architectural Requirements
+## V1.11 Business Logic Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
@@ -108,18 +108,18 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi
| **1.11.2** | Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state. | | ✓ | ✓ | 362 |
| **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. | | | ✓ | 367 |
-## V1.12 Secure File Upload Architectural Requirements
+## V1.12 Secure File Upload Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **1.12.1** | Verify that user-uploaded files are stored outside of the web root. | | ✓ | ✓ | 552 |
+| **1.12.1** | [DELETED, DUPLICATE OF 12.4.1] | | | | |
| **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
+## V1.13 API Architecture
This is a placeholder for future architectural requirements.
-## V1.14 Configuration Architectural Requirements
+## V1.14 Configuration Architecture
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
diff --git a/4.0/en/0x11-V2-Authentication.md b/4.0/en/0x11-V2-Authentication.md
index d2378f4bc1..1de455b66c 100644
--- a/4.0/en/0x11-V2-Authentication.md
+++ b/4.0/en/0x11-V2-Authentication.md
@@ -1,4 +1,4 @@
-# V2: Authentication Verification Requirements
+# V2 Authentication
## Control Objective
@@ -6,7 +6,7 @@ Authentication is the act of establishing, or confirming, someone (or something)
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.
+Of all the chapters 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
@@ -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 chapters 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
@@ -30,7 +30,7 @@ Applications can always exceed the current level's requirements, especially if m
| o | Recommended, but not required |
| ✓ | Required |
-## V2.1 Password Security Requirements
+## V2.1 Password Security
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.
@@ -41,7 +41,7 @@ Credential Service Providers (CSPs) provide federated identity for users. Users
| # | 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 (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.2** | Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. ([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 |
@@ -55,7 +55,7 @@ Credential Service Providers (CSPs) provide federated identity for users. Users
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
+## V2.2 General Authenticator Security
Authenticator agility is essential to future-proof applications. Refactor application verifiers to allow additional authenticators as per user preferences, as well as allowing retiring deprecated or unsafe authenticators in an orderly fashion.
@@ -66,12 +66,12 @@ NIST considers email and SMS as ["restricted" authenticator types](https://pages
| **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 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 |
+| **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 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
+## V2.3 Authenticator Lifecycle
Authenticators are passwords, soft tokens, hardware tokens, and biometric devices. The lifecycle of authenticators is critical to the security of an application - if anyone can self-register an account with no evidence of identity, there can be little trust in the identity assertion. For social media sites like Reddit, that's perfectly okay. For banking systems, a greater focus on the registration and issuance of credentials and devices is critical to the security of the application.
@@ -80,12 +80,12 @@ Note: Passwords are not to have a maximum lifetime or be subject to password rot
| # | 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 |
-| **2.3.3** | Verify that renewal instructions are sent with sufficient time to renew time bound authenticators. | | ✓ | ✓ | 287 | 6.1.4 |
+| **2.3.2** | Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens. | | ✓ | ✓ | 308 | 6.1.3 |
+| **2.3.3** | Verify that renewal instructions are sent with sufficient time to renew time bound authenticators. | | ✓ | ✓ | 287 | 6.1.4 |
-## V2.4 Credential Storage Requirements
+## V2.4 Credential Storage
-Architects and developers should adhere to this section when building or refactoring code. This section can only be fully verified using source code review or through secure unit or integration tests. Penetration testing cannot identify any of these issues.
+Architects and developers should adhere to this section when building or refactoring code. This section can only be fully verified using source code review or through secure unit or integration tests. Penetration testing cannot identify any of these issues.
The list of approved one-way key derivation functions is detailed in NIST 800-63 B section 5.1.1.2, and in [BSI Kryptographische Verfahren: Empfehlungen und Schlussellängen (2018)](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile). The latest national or regional algorithm and key length standards can be chosen in place of these choices.
@@ -96,12 +96,12 @@ This section cannot be penetration tested, so controls are not marked as L1. How
| **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 |
+| **2.4.4** | Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. ([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
+## V2.5 Credential Recovery
| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
@@ -111,19 +111,19 @@ Where US standards are mentioned, a regional or local standard can be used in pl
| **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 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 |
+| **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
+## V2.6 Look-up Secret Verifier
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 §](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 |
-| **2.6.3** | Verify that lookup secrets are resistant to offline attacks, such as predictable values. | | ✓ | ✓ | 310 | 5.1.2.2 |
+| **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 |
+| **2.6.3** | Verify that lookup secrets are resistant to offline attacks, such as predictable values. | | ✓ | ✓ | 310 | 5.1.2.2 |
-## V2.7 Out of Band Verifier Requirements
+## V2.7 Out of Band Verifier
In the past, a common out of band verifier would have been an email or SMS containing a password reset link. Attackers use this weak mechanism to reset accounts they don't yet control, such as taking over a person's email account and re-using any discovered reset links. There are better ways to handle out of band verification.
@@ -139,24 +139,24 @@ Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PST
| **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 |
| **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. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 |
| **2.7.4** | Verify that the out of band authenticator and verifier communicates over a secure independent channel. | ✓ | ✓ | ✓ | 523 | 5.1.3.2 |
-| **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 |
+| **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 One Time Verifier
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 §](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 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.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 |
+| **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 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.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
+## V2.9 Cryptographic Verifier
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.
@@ -164,20 +164,20 @@ The requirements for single-factor cryptographic devices and software, and multi
| # | 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 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.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 |
-## V2.10 Service Authentication Requirements
+## V2.10 Service Authentication
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 §](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
-| **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 TPM, or an HSM (L3) is recommended for password storage. | | OS assisted | HSM | 798 | |
+| **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 TPM, or an HSM (L3) is recommended for password storage. | | OS assisted | HSM | 798 | |
## Additional US Agency Requirements
@@ -193,7 +193,7 @@ 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), |
+| 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
diff --git a/4.0/en/0x12-V3-Session-management.md b/4.0/en/0x12-V3-Session-management.md
index 7ae4ac3568..20c0aebe02 100644
--- a/4.0/en/0x12-V3-Session-management.md
+++ b/4.0/en/0x12-V3-Session-management.md
@@ -1,4 +1,4 @@
-# V3: Session Management Verification Requirements
+# V3 Session Management
## Control Objective
@@ -13,24 +13,24 @@ As previously noted, these requirements have been adapted to be a compliant subs
## Security Verification Requirements
-## V3.1 Fundamental Session Management Requirements
+## V3.1 Fundamental Session Management Security
| # | 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. | ✓ | ✓ | ✓ | 598 | |
+| **3.1.1** | Verify the application never reveals session tokens in URL parameters. | ✓ | ✓ | ✓ | 598 | |
-## V3.2 Session Binding Requirements
+## V3.2 Session Binding
| # | 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://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://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 331 | 7.1 |
+| **3.2.4** | Verify that session tokens 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.
-## V3.3 Session Logout and Timeout Requirements
+## V3.3 Session Termination
Session timeouts have been aligned with NIST 800-63, which permits much longer session timeouts than traditionally permitted by security standards. Organizations should review the table below, and if a longer time out is desirable based around the application's risk, the NIST value should be the upper bounds of session idle timeouts.
@@ -40,8 +40,8 @@ L1 in this context is IAL1/AAL1, L2 is IAL2/AAL3, L3 is IAL3/AAL3. For IAL2/AAL2
| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
| **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 |
+| **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
@@ -50,8 +50,8 @@ L1 in this context is IAL1/AAL1, L2 is IAL2/AAL3, L3 is IAL3/AAL3. For IAL2/AAL2
| **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://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 |
+| **3.4.4** | Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie. | ✓ | ✓ | ✓ | 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 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
@@ -59,17 +59,17 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these
| # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
-| **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 | |
+| **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
+## V3.6 Federated Re-authentication
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 §](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
-| **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.1** | Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user 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
diff --git a/4.0/en/0x12-V4-Access-Control.md b/4.0/en/0x12-V4-Access-Control.md
index 5d9e39f641..28e9b55f69 100644
--- a/4.0/en/0x12-V4-Access-Control.md
+++ b/4.0/en/0x12-V4-Access-Control.md
@@ -1,4 +1,4 @@
-# V4: Access Control Verification Requirements
+# V4 Access Control
## Control Objective
@@ -16,9 +16,9 @@ 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://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 |
+| **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** | [DELETED, DUPLICATE OF 4.1.3] | | | | |
+| **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
@@ -33,7 +33,7 @@ Authorization is the concept of allowing access to resources only to those permi
| :---: | :--- | :---: | :---:| :---: | :---: |
| **4.3.1** | Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use. | ✓ | ✓ | ✓ | 419 |
| **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. | ✓ | ✓ | ✓ | 548 |
-| **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. | | ✓ | ✓ | 732 |
+| **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. | | ✓ | ✓ | 732 |
## References
diff --git a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md
index 6a84ff6b27..e18716e636 100644
--- a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md
+++ b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md
@@ -1,4 +1,4 @@
-# V5: Validation, Sanitization and Encoding Verification Requirements
+# V5 Validation, Sanitization and Encoding
## Control Objective
@@ -12,7 +12,7 @@ Ensure that a verified application satisfies the following high-level requiremen
With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.
-## V5.1 Input Validation Requirements
+## V5.1 Input Validation
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.
@@ -21,10 +21,10 @@ Properly implemented input validation controls, using positive allow lists and s
| **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://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.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, e-mail addresses, telephone numbers, 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
+## V5.2 Sanitization and Sandboxing
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
@@ -37,7 +37,7 @@ Properly implemented input validation controls, using positive allow lists and s
| **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
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.
@@ -48,7 +48,7 @@ Output encoding close or adjacent to the interpreter in use is critical to the s
| **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.6** | Verify that the application protects against JSON injection attacks, JSON eval attacks, 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 |
@@ -58,23 +58,23 @@ Note: Using parameterized queries or escaping SQL is not always sufficient; tabl
Note: The SVG format explicitly allows ECMA script in almost all contexts, so it may not be possible to block all SVG XSS vectors completely. If SVG upload is required, we strongly recommend either serving these uploaded files as text/plain or using a separate user supplied content domain to prevent successful XSS from taking over the application.
-## V5.4 Memory, String, and Unmanaged Code Requirements
+## V5.4 Memory, String, and Unmanaged Code
The following requirements will only apply when the application uses a systems language or unmanaged code.
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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. | | ✓ | ✓ | 120 |
-| **5.4.2** | Verify that format strings do not take potentially hostile input, and are constant. | | ✓ | ✓ | 134 |
-| **5.4.3** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | | ✓ | ✓ | 190 |
+| **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. | | ✓ | ✓ | 120 |
+| **5.4.2** | Verify that format strings do not take potentially hostile input, and are constant. | | ✓ | ✓ | 134 |
+| **5.4.3** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | | ✓ | ✓ | 190 |
-## V5.5 Deserialization Prevention Requirements
+## V5.5 Deserialization Prevention
| # | 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://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.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 |
## References
@@ -99,7 +99,7 @@ For more information on auto-escaping, please see:
* [AngularJS Strict Contextual Escaping](https://docs.angularjs.org/api/ng/service/$sce)
* [AngularJS ngBind](https://docs.angularjs.org/api/ng/directive/ngBind)
* [Angular Sanitization](https://angular.io/guide/security#sanitization-and-security-contexts)
-* [Angular Template Security](https://angular.io/guide/template-syntax#content-security)
+* [Angular Security](https://angular.io/guide/security)
* [ReactJS Escaping](https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks)
* [Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html)
diff --git a/4.0/en/0x14-V6-Cryptography.md b/4.0/en/0x14-V6-Cryptography.md
index 9bf97a8255..906feadb4f 100644
--- a/4.0/en/0x14-V6-Cryptography.md
+++ b/4.0/en/0x14-V6-Cryptography.md
@@ -1,4 +1,4 @@
-# V6: Stored Cryptography Verification Requirements
+# V6 Stored Cryptography
## Control Objective
@@ -14,9 +14,9 @@ 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.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 |
+| **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 |
## V6.2 Algorithms
@@ -28,7 +28,7 @@ Although this section is not easily penetration tested, developers should consid
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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://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.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://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 |
@@ -41,9 +41,9 @@ True Pseudo-random Number Generation (PRNG) is incredibly difficult to get right
| # | 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.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 |
+| **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.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
diff --git a/4.0/en/0x15-V7-Error-Logging.md b/4.0/en/0x15-V7-Error-Logging.md
index a014e32031..e577a8c860 100644
--- a/4.0/en/0x15-V7-Error-Logging.md
+++ b/4.0/en/0x15-V7-Error-Logging.md
@@ -1,4 +1,4 @@
-# V7: Error Handling and Logging Verification Requirements
+# V7 Error Handling and Logging
## Control Objective
@@ -14,7 +14,7 @@ If logs contain private or sensitive data, the definition of which varies from c
It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
-## V7.1 Log Content Requirements
+## V7.1 Log Content
Logging sensitive information is dangerous - the logs become classified themselves, which means they need to be encrypted, become subject to retention policies, and must be disclosed in security audits. Ensure only necessary information is kept in logs, and certainly no payment, credentials (including session tokens), sensitive or personally identifiable information.
@@ -30,7 +30,7 @@ V7.1 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetrat
| **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
+## V7.2 Log Processing
Timely logging is critical for audit events, triage, and escalation. Ensure that the application's logs are clear and can be easily monitored and analyzed either locally or log shipped to a remote monitoring system.
@@ -41,17 +41,17 @@ 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 tokens 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
+## V7.3 Log Protection
Logs that can be trivially modified or deleted are useless for investigations and prosecutions. Disclosure of logs can expose inner details about the application or the data it contains. Care must be taken when protecting logs from unauthorized disclosure, modification or deletion.
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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.1** | Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 117 |
+| **7.3.2** | [DELETED, DUPLICATE OF 7.3.1] | | | | |
| **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)) | | ✓ | ✓ | |
@@ -63,7 +63,7 @@ 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://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 210 |
+| **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 |
@@ -73,5 +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://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)
+* [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 4393dd1607..310103dca5 100644
--- a/4.0/en/0x16-V8-Data-Protection.md
+++ b/4.0/en/0x16-V8-Data-Protection.md
@@ -1,4 +1,4 @@
-# V8: Data Protection Verification Requirements
+# V8 Data Protection
## Control Objective
@@ -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 browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII. | ✓ | ✓ | ✓ | 922 |
+| **8.2.2** | Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data. | ✓ | ✓ | ✓ | 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
diff --git a/4.0/en/0x17-V9-Communications.md b/4.0/en/0x17-V9-Communications.md
index 40001e9378..5bb9273a41 100644
--- a/4.0/en/0x17-V9-Communications.md
+++ b/4.0/en/0x17-V9-Communications.md
@@ -1,42 +1,51 @@
-# V9: Communications Verification Requirements
+# V9 Communication
## Control Objective
-Ensure that a verified application satisfies the following high level requirements:
+Ensure that a verified application meets the following high level requirements:
-* TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
-* The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers
-* Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
-* Deprecated or known insecure algorithms and ciphers are disabled.
+* Require TLS or strong encryption, independent of sensitivity of the content.
+* Follow the latest guidance, including:
+ * Configuration advice
+ * Preferred algorithms and ciphers
+* Avoid weak or soon to be deprecated algorithms and ciphers, except as a last resort
+* Disable deprecated or known insecure algorithms and ciphers.
-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.
+Within these requirements:
-## V9.1 Client Communications Security Requirements
+* Stay current with recommended industry advice on secure TLS configuration, as it changes frequently (often due to catastrophic breaks in existing algorithms and ciphers).
+* Use the most recent versions of TLS configuration review tools to configure the preferred order and algorithm selection.
+* Check your configuration periodically to ensure that secure communication is always present and effective.
-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.
+## V9.1 Client Communication Security
+
+Ensure all client messages are sent over encrypted networks, using TLS 1.2 or later.
+Use up to date tools to review the client configuration on a regular basis.
| # | 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://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 |
+| **9.1.1** | Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 319 |
+| **9.1.2** | Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred. | ✓ | ✓ | ✓ | 326 |
+| **9.1.3** | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. | ✓ | ✓ | ✓ | 326 |
-## V9.2 Server Communications Security Requirements
+## V9.2 Server Communication Security
Server communications are more than just HTTP. Secure connections to and from other systems, such as monitoring systems, management tools, remote access and ssh, middleware, database, mainframes, partner or external source systems — must be in place. All of these must be encrypted to prevent "hard on the outside, trivially easy to intercept on the inside".
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | | ✓ | ✓ | 295 |
-| **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. | | ✓ | ✓ | 319 |
-| **9.2.3** | Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated. | | ✓ | ✓ | 287 |
-| **9.2.4** | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | | ✓ | ✓ | 299 |
-| **9.2.5** | Verify that backend TLS connection failures are logged. | | | ✓ | 544 |
+| **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. | | ✓ | ✓ | 319 |
+| **9.2.3** | Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated. | | ✓ | ✓ | 287 |
+| **9.2.4** | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | | ✓ | ✓ | 299 |
+| **9.2.5** | Verify that backend TLS connection failures are logged. | | | ✓ | 544 |
## References
For more information, see also:
-* [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.
+* [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 section 9.1 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 and up to date TLS evaluation tools to obtain a desired level of security.
diff --git a/4.0/en/0x18-V10-Malicious.md b/4.0/en/0x18-V10-Malicious.md
index b3a4d5264d..4af3e7f4bd 100644
--- a/4.0/en/0x18-V10-Malicious.md
+++ b/4.0/en/0x18-V10-Malicious.md
@@ -1,17 +1,17 @@
-# V10: Malicious Code Verification Requirements
+# V10 Malicious Code
## Control Objective
Ensure that code satisfies the following high level requirements:
-* Malicious activity is handled securely and properly to not affect the rest of the application.
+* Malicious activity is handled securely and properly to not affect the rest of the application.
* Does not have time bombs or other time-based attacks.
* Does not "phone home" to malicious or unauthorized destinations.
* Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.
Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
-## V10.1 Code Integrity Controls
+## V10.1 Code Integrity
The best defense against malicious code is "trust, but verify". Introducing unauthorized or malicious code into code is often a criminal offence in many jurisdictions. Policies and procedures should make sanctions regarding malicious code clear.
@@ -29,14 +29,14 @@ Complying with this section is not possible without complete access to source co
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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.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 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
+## V10.3 Application Integrity
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.
diff --git a/4.0/en/0x19-V11-BusLogic.md b/4.0/en/0x19-V11-BusLogic.md
index 3af3af02ad..c818325f6b 100644
--- a/4.0/en/0x19-V11-BusLogic.md
+++ b/4.0/en/0x19-V11-BusLogic.md
@@ -1,4 +1,4 @@
-# V11: Business Logic Verification Requirements
+# V11 Business Logic
## Control Objective
@@ -6,22 +6,22 @@ Ensure that a verified application satisfies the following high level requiremen
* The business logic flow is sequential, processed in order, and cannot be bypassed.
* Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
-* High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
+* High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks.
-## V11.1 Business Logic Security Requirements
+## V11.1 Business Logic Security
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.| ✓ | ✓ | ✓ | 799 |
+| **11.1.1** | Verify that 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 that 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.4** | Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, 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 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 |
+| **11.1.6** | Verify that 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 that 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 that the application has configurable alerting when automated attacks or unusual activity is detected. | | ✓ | ✓ | 390 |
## References
diff --git a/4.0/en/0x20-V12-Files-Resources.md b/4.0/en/0x20-V12-Files-Resources.md
index 380af3adcd..ff903b37cb 100644
--- a/4.0/en/0x20-V12-Files-Resources.md
+++ b/4.0/en/0x20-V12-Files-Resources.md
@@ -1,4 +1,4 @@
-# V12: File and Resources Verification Requirements
+# V12 Files and Resources
## Control Objective
@@ -7,48 +7,48 @@ Ensure that a verified application satisfies the following high level requiremen
* Untrusted file data should be handled accordingly and in a secure manner.
* Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.
-## V12.1 File Upload Requirements
+## V12.1 File Upload
Although zip bombs are eminently testable using penetration testing techniques, they are considered L2 and above to encourage design and development consideration with careful manual testing, and to avoid automated or unskilled manual penetration testing of a denial of service condition.
| # | 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. | ✓ | ✓ | ✓ | 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.2** | Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | | ✓ | ✓ | 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 |
-## V12.2 File Integrity Requirements
+## V12.2 File Integrity
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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 via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | ✓ | ✓ | ✓ | 98 |
+| **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 |
+| **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 |
-## V12.4 File Storage Requirements
+## V12.4 File Storage
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **12.4.1** | Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation. | ✓ | ✓ | ✓ | 922 |
-| **12.4.2** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content. | ✓ | ✓ | ✓ | 509 |
+| **12.4.1** | Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions. | ✓ | ✓ | ✓ | 552 |
+| **12.4.2** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | ✓ | ✓ | ✓ | 509 |
-## V12.5 File Download Requirements
+## V12.5 File Download
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | ✓ | ✓ | ✓ | 552 |
| **12.5.2** | Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content. | ✓ | ✓ | ✓ | 434 |
-## V12.6 SSRF Protection Requirements
+## V12.6 SSRF Protection
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
diff --git a/4.0/en/0x21-V13-API.md b/4.0/en/0x21-V13-API.md
index 92c7e44731..ce9e1a8bcb 100644
--- a/4.0/en/0x21-V13-API.md
+++ b/4.0/en/0x21-V13-API.md
@@ -1,4 +1,4 @@
-# V13: API and Web Service Verification Requirements
+# V13 API and Web Service
## Control Objective
@@ -10,17 +10,17 @@ Ensure that a verified application that uses trusted service layer APIs (commonl
Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns.
-## V13.1 Generic Web Service Security Verification Requirements
+## V13.1 Generic Web Service Security
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | ✓ | ✓ | ✓ | 116 |
-| **13.1.2** | Verify that access to administration and management functions is limited to authorized administrators. | ✓ | ✓ | ✓ | 419 |
+| **13.1.2** | [DELETED, DUPLICATE OF 4.3.1] | | | | |
| **13.1.3** | Verify API URLs do not expose sensitive information, such as the API key, session tokens etc. | ✓ | ✓ | ✓ | 598 |
-| **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. | | ✓ | ✓ | 285 |
-| **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). | | ✓ | ✓ | 434 |
+| **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. | | ✓ | ✓ | 285 |
+| **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). | | ✓ | ✓ | 434 |
-## V13.2 RESTful Web Service Verification Requirements
+## V13.2 RESTful Web Service
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:
@@ -32,28 +32,28 @@ Once the JSON schema validation standard is formalized, ASVS will update its adv
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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.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: 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 |
+| **13.2.4** | [DELETED, DUPLICATE OF 11.1.4] | | | | |
+| **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
+## V13.3 SOAP Web Service
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | ✓ | ✓ | ✓ | 20 |
-| **13.3.2** | Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service. | | ✓ | ✓ | 345 |
+| **13.3.2** | Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service. | | ✓ | ✓ | 345 |
Note: Due to issues with XXE attacks against DTDs, DTD validation should not be used, and framework DTD evaluation disabled as per the requirements set out in V14 Configuration.
-## V13.4 GraphQL and other Web Service Data Layer Security Requirements
+## V13.4 GraphQL
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---:| :---: | :---: |
-| **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 |
+| **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
diff --git a/4.0/en/0x22-V14-Config.md b/4.0/en/0x22-V14-Config.md
index 7f8d66ea9e..56f406d0f7 100644
--- a/4.0/en/0x22-V14-Config.md
+++ b/4.0/en/0x22-V14-Config.md
@@ -1,4 +1,4 @@
-# V14: Configuration Verification Requirements
+# V14 Configuration
## Control Objective
@@ -6,11 +6,10 @@ Ensure that a verified application has:
* A secure, repeatable, automatable build environment.
* Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
-* A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration.
-## V14.1 Build
+## V14.1 Build and Deploy
Build pipelines are the basis for repeatable security - every time something insecure is discovered, it can be resolved in the source code, build or deployment scripts, and tested automatically. We are strongly encouraging the use of build pipelines with automatic security and dependency checks that warn or break the build to prevent known security issues being deployed into production. Manual steps performed irregularly directly leads to avoidable security mistakes.
@@ -21,9 +20,9 @@ If traditional models are still in place, then manual steps must be taken to har
Compliance with this section requires an automated build system, and access to build and deployment scripts.
| # | Description | L1 | L2 | L3 | CWE |
-| --- | --- | --- | --- | -- | -- |
+| :---: | :--- | :---: | :---:| :---: | :---: |
| **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. | | ✓ | ✓ | |
-| **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. | | ✓ | ✓ | 120 |
+| **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. | | ✓ | ✓ | 120 |
| **14.1.3** | Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use. | | ✓ | ✓ | 16 |
| **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. | | ✓ | ✓ | |
| **14.1.5** | Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering. | | | ✓ | |
@@ -35,40 +34,40 @@ Dependency management is critical to the safe operation of any application of an
Note: At Level 1, 14.2.1 compliance relates to observations or detections of client-side and other libraries and components, rather than the more accurate build-time static code analysis or dependency analysis. These more accurate techniques could be discoverable by interview as required.
| # | 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://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.2** | Verify that all unneeded features, documentation, sample applications and configurations are removed. | ✓ | ✓ | ✓ | 1002 |
| **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.5** | Verify that a Software Bill of Materials (SBOM) 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
+## V14.3 Unintended Security Disclosure
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 |
-| --- | --- | --- | --- | -- | -- |
-| **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. | ✓ | ✓ | ✓ | 209 |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.3.1** | [DELETED, DUPLICATE OF 7.4.1] | | | | |
| **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. | ✓ | ✓ | ✓ | 497 |
| **14.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.4 HTTP Security Headers Requirements
+## V14.4 HTTP Security Headers
| # | Description | L1 | L2 | L3 | CWE |
-| --- | --- | --- | --- | -- | -- |
-| **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.1** | Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header. | ✓ | ✓ | ✓ | 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 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 |
+| **14.4.6** | Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties. | ✓ | ✓ | ✓ | 116 |
+| **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. | ✓ | ✓ | ✓ | 1021 |
-## V14.5 Validate HTTP Request Header Requirements
+## V14.5 HTTP Request Header Validation
| # | Description | L1 | L2 | L3 | CWE |
-| --- | --- | --- | --- | -- | -- |
+| :---: | :--- | :---: | :---:| :---: | :---: |
| **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-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 |
diff --git a/4.0/en/0x93-Appendix-C_IoT.md b/4.0/en/0x93-Appendix-C_IoT.md
index f837afb484..0f12b6cab5 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://owasp.org/www-project-internet-of-things/)
+This chapter 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
diff --git a/4.0/export.py b/4.0/export.py
index c88d8a5c7d..1d715d3874 100644
--- a/4.0/export.py
+++ b/4.0/export.py
@@ -32,7 +32,7 @@
from asvs import ASVS
parser = argparse.ArgumentParser(description='Export the ASVS requirements.')
-parser.add_argument('--format', choices=['json', 'xml', 'csv'], default='json')
+parser.add_argument('--format', choices=['json', 'json_flat', 'xml', 'csv'], default='json')
parser.add_argument('--language', default='en')
args = parser.parse_args()
@@ -43,5 +43,7 @@
print(m.to_csv())
elif args.format == "xml":
print(m.to_xml())
+elif args.format == "json_flat":
+ print(m.to_json_flat())
else:
print(m.to_json())
diff --git a/4.0/fr/0x00-Header.md b/4.0/fr/0x00-Header.md
new file mode 100644
index 0000000000..a096000199
--- /dev/null
+++ b/4.0/fr/0x00-Header.md
@@ -0,0 +1,9 @@
+#
+
+
+
+# Application Security Verification Standard 4.0
+
+## Final
+
+Mars 2019
diff --git a/4.0/fr/0x01-Frontispiece.md b/4.0/fr/0x01-Frontispiece.md
new file mode 100644
index 0000000000..086298d418
--- /dev/null
+++ b/4.0/fr/0x01-Frontispiece.md
@@ -0,0 +1,58 @@
+# Frontispice
+
+## À propos de la norme
+
+Le référentiel de vérification de la sécurité des applications est une liste d'exigences ou de tests de sécurité des applications qui peut être utilisée par les architectes, les développeurs, les testeurs, les professionnels de la sécurité, les fournisseurs d'outils et les utilisateurs pour définir, construire, tester et vérifier des applications sécurisées.
+
+## Copyright et licence
+
+! [licence](../images/license.png)
+Copyright © 2008-2019 La Fondation OWASP. Ce document est publié sous la [licence Creative Commons Attribution ShareAlike 3.0](https://creativecommons.org/licenses/by-sa/3.0/). Pour toute réutilisation ou distribution, vous devez indiquer clairement aux autres les termes de la licence de ce travail.
+
+Version 4.0.1, mars 2019
+
+## Chefs de projet
+
+- Andrew van der Stock
+- Daniel Cuthbert
+- Jim Manico
+- Josh C Grossman
+- Mark Burnett
+
+## Collaborateurs et relecteurs
+
+- 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
+- Daniël Geerts
+
+Le référentiel de vérification de la sécurité des applications repose sur les épaules des personnes concernées, de ASVS 1.0 en 2008 à 3.0 en 2016. Une grande partie de la structure et des éléments de vérification qui sont encore dans l'ASVS aujourd'hui ont été écrits à l'origine par Mike Boberski, Jeff Williams et Dave Wichers, mais il y a beaucoup plus de contributeurs. Merci à tous ceux qui y ont participé précédemment. Pour une liste complète de tous ceux qui ont contribué aux versions précédentes, veuillez consulter chaque version antérieure.
+
+S'il manque un crédit dans la liste des crédits 4.0 ci-dessus, veuillez contacter vanderaj@owasp.org ou enregistrer un ticket sur GitHub pour être reconnu dans les futures mises à jour 4.x.
diff --git a/4.0/fr/0x02-Preface.md b/4.0/fr/0x02-Preface.md
new file mode 100644
index 0000000000..49bdfc92b4
--- /dev/null
+++ b/4.0/fr/0x02-Preface.md
@@ -0,0 +1,31 @@
+# Préface
+
+Bienvenue dans la version 4.0 du référentiel de vérification de la sécurité des applications (ASVS). L'ASVS est un effort communautaire visant à établir un cadre d'exigences et de contrôles de sécurité qui se concentre sur la définition des contrôles de sécurité fonctionnels et non fonctionnels requis lors de la conception, du développement et du test d'applications et de services web modernes.
+
+La version 4.0.2 est la deuxième mise à jour mineure de la v4.0 destinée à corriger les erreurs d'orthographe et à rendre les exigences plus claires sans modifier les exigences ou ajouter/supprimer des exigences.
+
+L'ASVS v4.0 est l'aboutissement des efforts de la communauté et des réactions de l'industrie au cours de la dernière décennie. Nous avons tenté de faciliter l'adoption de l'ASVS pour une variété de cas d'utilisation différents tout au long du cycle de vie du développement de logiciels sécurisés.
+
+Nous pensons qu'il n'y aura très probablement jamais un accord à 100% sur le contenu de n'importe quel standard d'application web, y compris l'ASVS. L'analyse des risques est toujours subjective dans une certaine mesure, ce qui constitue un défi lorsque l'on tente de généraliser dans une norme unique. Cependant, nous espérons que les dernières mises à jour effectuées dans cette version sont un pas dans la bonne direction, et qu'elles améliorent les concepts introduits dans cette norme industrielle essentielle.
+
+## Quoi de neuf dans la version 4.0
+
+Le changement le plus important dans cette version est l'adoption des directives NIST 800-63-3 sur l'identité numérique, introduisant des contrôles d'authentification modernes, basés sur des preuves et avancés. Bien que nous nous attendions à un certain recul sur l'alignement avec une norme d'authentification avancée, nous estimons qu'il est essentiel que les normes soient alignées, principalement lorsqu'une autre norme de sécurité des applications bien considérée est fondée sur des preuves.
+
+Les normes de sécurité de l'information devraient essayer de minimiser le nombre d'exigences uniques, afin que les organisations qui s'y conforment n'aient pas à décider de contrôles concurrents ou incompatibles. Le Top 10 2017 de l'OWASP et maintenant la norme de vérification de la sécurité des applications de l'OWASP sont désormais alignés sur la norme NIST 800-63 pour l'authentification et la gestion des sessions. Nous encourageons les autres organismes de normalisation à travailler avec nous, le NIST et d'autres organismes pour parvenir à un ensemble généralement accepté de contrôles de sécurité des applications afin de maximiser la sécurité et de minimiser les coûts de mise en conformité.
+
+ASVS 4.0 a été entièrement renuméroté du début à la fin. Le nouveau schéma de numérotation nous a permis de combler les lacunes de chapitres disparus depuis longtemps, et de segmenter les chapitres plus longs afin de minimiser le nombre de contrôles auxquels un développeur ou une équipe doit se conformer. Par exemple, si une application n'utilise pas JWT, toute la section sur JWT dans la gestion des sessions n'est pas applicable.
+
+La nouveauté de la version 4.0 est une mise en correspondance complète avec le Common Weakness Enumeration (CWE), l'une des demandes de fonctionnalités les plus souvent souhaitées que nous avons eues au cours de la dernière décennie. Le mappage CWE permet aux fabricants d'outils et à ceux qui utilisent un logiciel de gestion des vulnérabilités de faire correspondre les résultats d'autres outils et des versions ASVS précédentes à la version 4.0 et aux versions ultérieures. Pour faire place à l'entrée CWE, nous avons dû retirer la colonne "Depuis", qui, comme nous l'avons complètement renumérotée, est moins logique que dans les versions précédentes de l'ASVS. Tous les éléments de l'ASVS ne sont pas associés à une CWE, et comme la CWE comporte de nombreux doublons, nous avons essayé d'utiliser la correspondance la plus courante plutôt que la plus proche. Les contrôles de vérification ne peuvent pas toujours être mis en correspondance avec des faiblesses équivalentes. Nous nous félicitons des discussions en cours avec la communauté du CWE et, plus généralement, avec le secteur de la sécurité de l'information, en vue de combler cette lacune.
+
+Nous nous sommes efforcés de satisfaire, voire de dépasser, les exigences relatives au Top 10 de l'OWASP 2017 et aux contrôles proactifs de l'OWASP 2018. Comme le Top 10 2017 de l'OWASP est le strict minimum pour éviter toute négligence, nous avons délibérément fait tous les contrôles de niveau 1, sauf les contrôles spécifiques de journalisation des exigences du Top 10, ce qui permet aux adoptants du Top 10 de l'OWASP de passer plus facilement à une norme de sécurité réelle.
+
+Nous avons voulu faire en sorte que l'ASVS 4.0 Niveau 1 soit un sur-ensemble complet des sections 6.5 de la norme PCI DSS 3.2.1, pour la conception d'applications, le codage, les tests, les examens de code sécurisé et les tests de pénétration. Cela a nécessité de couvrir les débordements de mémoire tampon et les opérations de mémoire non sécurisées dans la version 5, et les drapeaux de compilation liés à la mémoire non sécurisée dans la version 14, en plus des exigences de vérification des applications et des services web déjà en vigueur dans le secteur.
+
+Nous avons achevé le passage de l'ASVS des contrôles monolithiques côté serveur uniquement, à la fourniture de contrôles de sécurité pour toutes les applications et API modernes. À l'époque de la programmation fonctionnelle, des API sans serveur, des mobiles, du cloud, des conteneurs, des CI/CD et des DevSecOps, de la fédération et bien d'autres choses encore, nous ne pouvons pas continuer à ignorer l'architecture moderne des applications. Les applications modernes sont conçues de manière très différente de celles construites lors de la sortie du premier ASVS en 2009. L'ASVS doit toujours être tournée vers l'avenir afin de fournir des conseils judicieux à notre public principal, les développeurs. Nous avons clarifié ou supprimé toute exigence qui suppose que les applications sont exécutées sur des systèmes appartenant à une seule organisation.
+
+En raison de la taille de l'ASVS 4.0, ainsi que de notre désir de devenir l'ASVS de référence pour tous les autres efforts de l'ASVS, nous avons retiré la section mobile, en faveur de la norme MASVS (Mobile Application Security Verification Standard). L'appendice "Internet of Things" apparaîtra dans un futur IoT ASVS du projet "Internet of Things" de l'OWASP. Nous avons inclus un premier aperçu de l'IoT ASVS dans l'annexe C. Nous remercions l'équipe mobile de l'OWASP et l'équipe du projet IoT de l'OWASP pour leur soutien à l'ASVS, et nous nous réjouissons de travailler avec elles à l'avenir pour fournir des normes complémentaires.
+
+Enfin, nous avons supprimé et retiré les contrôles ayant moins d'impact. Avec le temps, l'ASVS a commencé à être un ensemble complet de contrôles, mais tous les contrôles ne sont pas égaux pour produire des logiciels sécurisés. Cet effort visant à éliminer les éléments à faible impact pourrait aller plus loin. Dans une prochaine édition de l'ASVS, le système de notation des faiblesses communes (CWSS) permettra de hiérarchiser davantage les contrôles qui sont vraiment importants et ceux qui devraient être retirés.
+
+À partir de la version 4.0, l'ASVS se concentrera uniquement sur le fait d'être le principal standard de services et d'applications web, couvrant l'architecture traditionnelle et moderne des applications, ainsi que les pratiques de sécurité agiles et la culture DevSecOps.
diff --git a/4.0/fr/0x03-Using-ASVS.md b/4.0/fr/0x03-Using-ASVS.md
new file mode 100644
index 0000000000..a9ca443955
--- /dev/null
+++ b/4.0/fr/0x03-Using-ASVS.md
@@ -0,0 +1,62 @@
+# Utiliser l'ASVS
+
+L'ASVS a deux objectifs principaux :
+
+* aider les organisations à développer et à maintenir des applications sécurisées.
+* permettre aux fournisseurs de services de sécurité, aux vendeurs d'outils de sécurité et aux consommateurs d'aligner leurs exigences et leurs offres.
+
+## Niveaux de vérification de la sécurité des applications
+
+La norme de vérification de la sécurité des applications définit trois niveaux de vérification de la sécurité, chacun d'eux étant plus approfondi.
+
+* Le niveau 1 de l'ASVS est destiné aux niveaux d'assurance faibles, et peut être testé via des tests d'intrusions classiques.
+* Le niveau 2 de l'ASVS est destiné aux applications qui contiennent des données sensibles, ce qui nécessite une protection et constitue le niveau recommandé pour la plupart des applications
+* Le niveau 3 de l'ASVS est destiné aux applications les plus critiques - les applications qui effectuent des transactions de grande valeur, qui contiennent des données médicales sensibles, ou toute application qui requiert le plus haut niveau de confiance.
+
+Chaque niveau ASVS contient une liste d'exigences de sécurité. Chacune de ces exigences peut également être mise en correspondance avec des caractéristiques et des capacités de sécurité spécifiques qui doivent être intégrées dans les logiciels par les développeurs.
+
+
+
+Figure 1 - Niveaux de vérification de la sécurité des applications OWASP 4.0
+
+Le niveau 1 est le seul qui soit entièrement adéquat pour des tests d'intrusions fait par des humains. Tous les autres niveaux nécessitent l'accès à la documentation, au code source, à la configuration et aux personnes impliquées dans le processus de développement. Cependant, même si le niveau 1 permet de réaliser des tests de "boîte noire" (pas de documentation et pas de source), ce n'est pas une activité d'assurance efficace et doit être activement découragée. Les attaquants malveillants ont beaucoup de temps, la plupart des tests d'intrusions sont terminés en quelques semaines. Les défenseurs doivent mettre en place des contrôles de sécurité, protéger, trouver et résoudre toutes les faiblesses, et détecter et répondre aux acteurs malveillants dans un délai raisonnable. Les acteurs malveillants disposent essentiellement d'un temps infini et n'ont besoin que d'une seule défense poreuse, d'une seule faiblesse ou d'une détection manquante pour réussir. Les tests de la boîte noire, souvent effectués en fin de développement, rapidement ou pas du tout, sont totalement incapables de faire face à cette asymétrie.
+
+Au cours des 30 dernières années, les tests en boîte noire ont prouvé à maintes reprises qu'ils passaient à côté de problèmes de sécurité critiques qui ont directement conduit à des violations de plus en plus massives. Nous encourageons vivement l'utilisation d'un large éventail de mesures d'assurance et de vérification de la sécurité, notamment le remplacement des tests d'intrusions par des tests d'intrusions (hybrides) de niveau 1 basés sur le code source, avec un accès complet aux développeurs et à la documentation tout au long du processus de développement. Les régulateurs financiers ne tolèrent pas les audits financiers externes sans accès aux livres, aux échantillons de transactions ou aux personnes effectuant les contrôles. L'industrie et les gouvernements doivent exiger le même niveau de transparence dans le domaine du génie logiciel.
+
+Nous encourageons fortement l'utilisation d'outils de sécurité, mais dans le cadre du processus de développement lui-même, tels que les outils DAST et SAST utilisés en permanence par le pipeline de construction pour trouver facilement des problèmes de sécurité qui ne devraient jamais être présents.
+
+Les outils automatisés et les scanners en ligne ne permettent pas de réaliser plus de la moitié des contrôles ASVS sans assistance humaine. Si une automatisation complète des tests pour chaque construction est nécessaire, on utilise alors une combinaison de tests unitaires et d'intégration personnalisés, ainsi que des scans en ligne initiés par la construction. Les failles de la logique métier et les tests de contrôle d'accès ne sont possibles qu'avec l'aide d'une personne. Ces tests doivent être transformés en tests unitaires et d'intégration.
+
+## Comment utiliser ce document
+
+L'une des meilleures façons d'utiliser le référentiel de vérification de la sécurité des applications est de l'utiliser comme plan directeur pour créer une liste de contrôle de codage sécurisé spécifique à votre application, plate-forme ou organisation. En adaptant l'ASVS à vos cas d'utilisation, vous pourrez mieux vous concentrer sur les exigences de sécurité les plus importantes pour vos projets et vos environnements.
+
+### Niveau 1 - Premières étapes, automatisé, ou vue de l'ensemble du portefeuille
+
+Une application atteint le niveau 1 de l'ASVS si elle se défend de manière adéquate contre les vulnérabilités de sécurité des applications qui sont faciles à découvrir, et qui figurent dans le Top 10 de l'OWASP et d'autres listes de contrôle similaires.
+
+Le niveau 1 est le strict minimum que toutes les applications devraient s'efforcer d'atteindre. Il est également utile comme première étape dans un effort en plusieurs phases ou lorsque les applications ne stockent pas ou ne traitent pas de données sensibles et n'ont donc pas besoin des contrôles plus rigoureux du niveau 2 ou 3. Les contrôles de niveau 1 peuvent être vérifiés soit automatiquement par des outils, soit simplement manuellement sans accès au code source. Nous considérons que le niveau 1 est le minimum requis pour toutes les applications.
+
+Les menaces pour l'application proviendront très probablement d'attaquants qui utilisent des techniques simples et peu exigeantes pour identifier des vulnérabilités faciles à trouver et à exploiter. En revanche, un attaquant déterminé dépensera une énergie considérable pour cibler spécifiquement l'application. Si les données traitées par votre application ont une valeur élevée, vous voudrez rarement vous arrêter à un examen de niveau 1.
+
+### Niveau 2 - La plupart des demandes
+
+Une application atteint le niveau 2 (ou norme) de l'ASVS si elle se défend adéquatement contre la plupart des risques associés aux logiciels d'aujourd'hui.
+
+Le niveau 2 garantit que les contrôles de sécurité sont en place, efficaces et utilisés au sein de l'application. Le niveau 2 est généralement approprié pour les applications qui traitent des transactions interentreprises importantes, y compris celles qui traitent des informations sur les soins de santé, mettent en œuvre des fonctions critiques ou sensibles, traitent d'autres actifs sensibles, ou les secteurs où l'intégrité est une facette essentielle pour protéger leur activité, comme le secteur des jeux pour contrecarrer les tricheurs et les pirates.
+
+Les menaces pesant sur les applications de niveau 2 seront généralement des attaquants compétents et motivés qui se concentrent sur des cibles spécifiques en utilisant des outils et des techniques très pratiques et efficaces pour découvrir et exploiter les faiblesses des applications.
+
+### Niveau 3 - Haute valeur, haute assurance ou haute sécurité
+
+Le niveau 3 de l'ASVS est le plus haut niveau de vérification au sein de l'ASVS. Ce niveau est généralement réservé aux applications qui nécessitent des niveaux de vérification de sécurité importants, comme celles qui peuvent se trouver dans les domaines de l'armée, de la santé et de la sécurité, des infrastructures critiques, etc.
+
+Les organisations peuvent exiger le niveau 3 de l'ASVS pour les applications qui remplissent des fonctions critiques, où une défaillance pourrait avoir un impact significatif sur les opérations de l'organisation, et même sur sa capacité de survie. Des exemples de conseils sur l'application de l'ASVS niveau 3 sont fournis ci-dessous. Une application atteint le niveau 3 ASVS (ou avancé) si elle se défend de manière adéquate contre les vulnérabilités de sécurité des applications avancées et si elle démontre également les principes d'une bonne conception de la sécurité.
+
+Une application au niveau 3 ASVS nécessite une analyse plus approfondie de l'architecture, du code et des tests que tous les autres niveaux. Une application sécurisée est modulaire de manière significative (pour faciliter la résilience, l'évolutivité et, surtout, les couches de sécurité), et chaque module (séparé par une connexion réseau et/ou une instance physique) prend en charge ses propres responsabilités en matière de sécurité (défense en profondeur), qui doivent être correctement documentés. Les responsabilités comprennent des contrôles pour garantir la confidentialité (par exemple, le cryptage), l'intégrité (par exemple, les transactions, la validation des entrées), la disponibilité (par exemple, gérer la charge avec élégance), l'authentification (y compris entre les systèmes), la non-répudiation, l'autorisation et l'audit (journalisation).
+
+## Application de l'ASVS en pratique
+
+Les différentes menaces ont des motivations différentes. Certains secteurs d'activité disposent d'atouts uniques en matière d'information et de technologie et ont des exigences de conformité réglementaire spécifiques à leur domaine.
+
+Les organisations sont fortement encouragées à examiner en profondeur leurs caractéristiques de risque uniques en fonction de la nature de leur activité, et à déterminer le niveau ASVS approprié en fonction de ce risque et des exigences commerciales.
diff --git a/4.0/fr/0x04-Assessment_and_Certification.md b/4.0/fr/0x04-Assessment_and_Certification.md
new file mode 100644
index 0000000000..51533184e1
--- /dev/null
+++ b/4.0/fr/0x04-Assessment_and_Certification.md
@@ -0,0 +1,59 @@
+# Évaluation et certification
+
+## Position de l'OWASP sur les certifications et marques de confiance ASVS
+
+L'OWASP, en tant qu'organisation à but non lucratif neutre, ne certifie actuellement aucun vendeur, vérificateur ou logiciel.
+
+Toutes ces assertions d'assurance, marques de confiance ou certifications ne sont pas officiellement vérifiées, enregistrées ou certifiées par l'OWASP, de sorte qu'une organisation qui s'appuie sur ce point de vue doit être prudente quant à la confiance placée dans une tierce partie ou une marque de confiance revendiquant la certification ASVS.
+
+Cela ne devrait pas empêcher les organisations d'offrir de tels services d'assurance, tant qu'elles ne revendiquent pas la certification officielle de l'OWASP.
+
+## Directives pour les organismes de certification
+
+La norme de vérification de la sécurité des applications peut être utilisée comme une vérification à livre ouvert de l'application, comprenant un accès ouvert et sans entrave aux ressources clés telles que les architectes et les développeurs, la documentation du projet, le code source, l'accès authentifié aux systèmes de test (y compris l'accès à un ou plusieurs comptes dans chaque rôle), en particulier pour les vérifications de L2 et L3.
+
+Historiquement, les tests de pénétration et les examens de code sécurisé ont inclus des questions "par exception" - c'est-à-dire que seuls les tests échoués apparaissent dans le rapport final. Un organisme de certification doit inclure dans tout rapport la portée de la vérification (en particulier si un élément clé est hors de portée, comme l'authentification du SSO), un résumé des résultats de la vérification, y compris les tests réussis et les tests échoués, avec des indications claires sur la manière de résoudre les tests échoués.
+
+Certaines exigences de vérification peuvent ne pas être applicables à l'application testée. Par exemple, si vous fournissez à vos clients une API de couche de service sans état sans implémentation client, de nombreuses exigences de la gestion de session V3 ne sont pas directement applicables. Dans de tels cas, un organisme de certification peut toujours prétendre à une conformité totale aux ASVS, mais doit clairement indiquer dans tout rapport une raison de non-applicabilité de ces exigences de vérification exclues.
+
+La conservation de documents de travail détaillés, de captures d'écran ou de films, de scripts permettant d'exploiter un problème de manière fiable et répétée, ainsi que d'enregistrements électroniques des tests, tels que l'interception de journaux de proxy et de notes associées comme une liste de nettoyage, est considérée comme une pratique standard de l'industrie et peut être vraiment utile comme preuve des résultats pour les développeurs les plus douteux. Il ne suffit pas de faire fonctionner un outil et de signaler les échecs ; cela ne prouve pas (du tout) que tous les problèmes à un niveau de certification ont été testés et éprouvés de manière approfondie. En cas de litige, il doit y avoir suffisamment de preuves d'assurance pour démontrer que chaque exigence vérifiée a bien été testée.
+
+### Méthode de test
+
+Les organismes certificateurs sont libres de choisir la ou les méthodes d'essai appropriées, mais doivent les indiquer dans un rapport.
+
+Selon l'application testée et l'exigence de vérification, différentes méthodes de test peuvent être utilisées pour obtenir une confiance similaire dans les résultats. Par exemple, la validation de l'efficacité des mécanismes de vérification des entrées d'une application peut être analysée soit par un test d'intrusion manuel, soit par des analyses du code source.
+
+#### Le rôle des outils de test de sécurité automatisés
+
+L'utilisation d'outils automatisés de test de pénétration est encouragée afin d'assurer une couverture aussi large que possible.
+
+Il n'est pas possible d'effectuer une vérification complète de l'ASVS en utilisant uniquement des outils de test de pénétration automatisés. Alors qu'une grande majorité des exigences de la L1 peuvent être réalisées à l'aide de tests automatisés, la majorité globale des exigences ne se prête pas à l'utilisation de tests d'intrusion automatisés.
+
+Veuillez noter que les limites entre les tests automatisés et manuels se sont estompées au fur et à mesure que le secteur de la sécurité des applications a évolué. Les outils automatisés sont souvent réglés manuellement par des experts et les testeurs manuels utilisent souvent une grande variété d'outils automatisés.
+
+#### Le rôle des tests de pénétration
+
+Dans la version 4.0, nous avons décidé de rendre la L1 entièrement testable par pénétration sans accès au code source, à la documentation ou aux développeurs. Deux éléments d'enregistrement, qui doivent être conformes au Top 10 2017 A10 de l'OWASP, nécessiteront des entretiens, des captures d'écran ou d'autres collectes de preuves, tout comme dans le Top 10 2017 de l'OWASP. Cependant, les tests sans accès aux informations nécessaires ne constituent pas une méthode idéale de vérification de la sécurité, car ils laissent de côté la possibilité d'examiner la source, d'identifier les menaces et les contrôles manquants, et de réaliser un test beaucoup plus approfondi dans un délai plus court.
+
+Dans la mesure du possible, l'accès aux développeurs, à la documentation, au code et l'accès à une application de test avec des données de non-production, est nécessaire lors de l'exécution d'une évaluation de niveau 2 ou 3. Les tests de pénétration effectués à ces niveaux nécessitent ce niveau d'accès, que nous appelons "examens hybrides" ou "tests de pénétration hybrides".
+
+## Autres utilisations de l'ASVS
+
+En plus de servir à l'évaluation de la sécurité d'une application, nous avons identifié plusieurs autres potentielles utilisations de l'ASVS.
+
+### Guide pour les tests unitaires et d'intégration automatisés
+
+L'ASVS est conçu pour être hautement testable, à la seule exception des exigences en matière d'architecture et de code malveillant. Grâce à des tests unitaires et d'intégration qui permettent de détecter des variantes et des cas d'abus spécifiques et pertinents, l'application se vérifie pratiquement d'elle-même à chaque nouvelle itération. Par exemple, des tests supplémentaires peuvent être élaborés pour la suite de tests d'un contrôleur de connexion, en testant le paramètre de nom d'utilisateur pour les noms d'utilisateur communs par défaut, l'énumération des comptes, l'énumération exhaustive (brute-force), l'injection LDAP et SQL, et XSS. De plus, un test sur le paramètre du mot de passe devrait inclure les mots de passe communs, la longueur du mot de passe, l'injection d'octets nuls, la suppression du paramètre, XSS, et plus encore.
+
+### Pour la formation au développement sécurisé
+
+L'ASVS peut également être utilisé pour définir les caractéristiques des logiciels sécurisés. De nombreux cours de "codage sécurisé" sont simplement des cours de piratage éthique avec une légère trace de conseils de codage. Cela n'aide pas nécessairement les développeurs à écrire un code plus sûr. Les cours de développement sécurisé peuvent plutôt utiliser l'ASVS en mettant l'accent sur les contrôles proactifs qu'il contient, plutôt que sur les dix principales erreurs à ne pas faire.
+
+### En tant que pilote pour la sécurité des applications agiles
+
+L'ASVS peut être utilisé dans un processus de développement agile comme cadre pour définir les tâches spécifiques qui doivent être mises en œuvre par l'équipe pour avoir un produit sécurisé. Une approche pourrait être : En commençant par le niveau 1, vérifier l'application ou le système spécifique selon les exigences de l'ASVS pour le niveau spécifié, trouver les contrôles manquants et soulever des tickets/tâches spécifiques dans le backlog. Cela permet de hiérarchiser les tâches spécifiques (ou grooming) et de rendre la sécurité visible dans le processus agile. Cela peut également être utilisé pour hiérarchiser les tâches d'audit et de révision dans l'organisation, où une exigence ASVS spécifique peut être un moteur de révision, de remaniement ou d'audit pour un membre spécifique de l'équipe et être visible en tant que "dette" dans le backlog qui doit finalement être fait.
+
+### Comme cadre pour guider l'acquisition de logiciels sécurisés
+
+L'ASVS est un cadre idéal pour aider à sécuriser l'acquisition de logiciels ou de services de développement personnalisés. L'acheteur peut simplement exiger que le logiciel qu'il souhaite acquérir soit développé au niveau X de l'ASVS, et demander au vendeur de prouver que le logiciel satisfait au niveau X de l'ASVS. Cette procédure fonctionne bien lorsqu'elle est combinée avec l'annexe du contrat de logiciel sécurisé de l'OWASP.
diff --git a/4.0/fr/0x10-V1-Architecture.md b/4.0/fr/0x10-V1-Architecture.md
new file mode 100644
index 0000000000..3059dc8537
--- /dev/null
+++ b/4.0/fr/0x10-V1-Architecture.md
@@ -0,0 +1,142 @@
+# V1 : Architecture, conception et exigences en matière de modélisation des menaces
+
+## Objectif de contrôle
+
+L'architecture de sécurité est presque devenue un art perdu dans de nombreuses organisations. Les jours de l'architecte d'entreprise sont passés à l'ère des DevSecOps. Le domaine de la sécurité des applications doit rattraper son retard et adopter des principes de sécurité agiles tout en réintroduisant les principes de l'architecture de sécurité de pointe auprès des praticiens du logiciel. L'architecture n'est pas une implémentation, mais une façon de penser à un problème qui peut avoir plusieurs réponses différentes, et pas une seule réponse "correcte". Trop souvent, la sécurité est considérée comme rigide et exige que les développeurs corrigent le code d'une manière particulière, alors qu'ils connaissent peut-être un bien meilleur moyen de résoudre le problème. Il n'existe pas de solution unique et simple pour l'architecture, et prétendre le contraire est un mauvais service rendu au domaine du génie logiciel.
+
+Une implémentation spécifique d'une application web est susceptible d'être révisée continuellement tout au long de sa vie, mais l'architecture globale ne changera probablement que rarement, mais évoluera lentement. L'architecture de sécurité est identique - nous avons besoin d'une authentification aujourd'hui, nous en aurons besoin demain, et nous en aurons besoin dans cinq ans. Si nous prenons des décisions judicieuses aujourd'hui, nous pouvons économiser beaucoup d'efforts, de temps et d'argent si nous sélectionnons et réutilisons des solutions conformes à l'architecture. Par exemple, il y a dix ans, l'authentification multifactorielle était rarement mise en œuvre.
+
+Si les développeurs avaient investi dans un modèle de fournisseur d'identité unique et sécurisé, tel que l'identité fédérée SAML, le fournisseur d'identité pourrait être mis à jour pour intégrer de nouvelles exigences telles que la conformité NIST 800-63, sans pour autant modifier les interfaces de l'application d'origine. Si de nombreuses applications partageaient la même architecture de sécurité et donc le même composant, elles bénéficient toutes de cette mise à jour en même temps. Toutefois, SAML ne restera pas toujours la meilleure ou la plus appropriée des solutions d'authentification - il pourrait être nécessaire de le remplacer par d'autres solutions au fur et à mesure que les exigences changent. De telles modifications sont soit compliquées, si coûteuses qu'elles nécessitent une réécriture complète, soit carrément impossibles sans architecture de sécurité.
+
+Dans ce chapitre, l'ASVS couvre les principaux aspects de toute architecture de sécurité solide : disponibilité, confidentialité, intégrité du traitement, non-répudiation et respect de la vie privée. Chacun de ces principes de sécurité doit être intégré et inné à toutes les applications. Il est essentiel de "tourner à gauche", en commençant par l'habilitation des développeurs avec des listes de contrôle de codage sécurisé, le mentorat et la formation, le codage et les tests, la construction, le déploiement, la configuration et les opérations, et en terminant par des tests indépendants de suivi pour s'assurer que tous les contrôles de sécurité sont présents et fonctionnels. La dernière étape était autrefois tout ce que nous faisions en tant qu'industrie, mais cela ne suffit plus lorsque les développeurs mettent le code en production des dizaines ou des centaines de fois par jour. Les professionnels de la sécurité des applications doivent se tenir au courant des techniques agiles, ce qui signifie adopter les outils des développeurs, apprendre à coder et travailler avec eux plutôt que de critiquer le projet des mois après que tout le monde est passé à autre chose.
+
+## V1.1 Exigences relatives au cycle de vie du développement de logiciels sécurisés
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.1.1** | Vérifier l'utilisation d'un cycle de développement de logiciel sécurisé qui prend en compte la sécurité à tous les stades du développement. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | |
+| **1.1.2** | Vérifier l'utilisation de la modélisation des menaces pour chaque modification de conception ou planification de sprint afin d'identifier les menaces, de planifier les contre-mesures, de faciliter les réponses appropriées aux risques et d'orienter les tests de sécurité. | | ✓ | ✓ | 1053 |
+| **1.1.3** | Vérifiez que toutes les récits utilisateurs et les fonctionnalités contiennent des contraintes de sécurité fonctionnelles, telles que "En tant qu'utilisateur, je devrais pouvoir consulter et modifier mon profil. Je ne devrais pas pouvoir voir ou modifier le profil de quelqu'un d'autre" | | ✓ | ✓ | 1110 |
+| **1.1.4** | Vérifier la documentation et la justification de toutes les frontières de confiance de la demande, de ses composantes et des flux de données importants. | | ✓ | ✓ | 1059 |
+| **1.1.5** | Vérifier la définition et l'analyse de sécurité de l'architecture de haut niveau de l'application et de tous les services à distance connectés. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 1059 |
+| **1.1.6** | Vérifier la mise en œuvre de contrôles de sécurité centralisés, simples (économie de conception), vérifiés, sécurisés et réutilisables pour éviter les contrôles en double, manquants, inefficaces ou peu sûrs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 637 |
+| **1.1.7** | Vérifier que tous les développeurs et testeurs disposent d'une liste de contrôle de codage sécurisé, d'exigences de sécurité, de lignes directrices ou de politiques. | | ✓ | ✓ | 637 |
+| **1.1.8** | Vérifier la disponibilité d'un fichier [security.txt](https://securitytxt.org/) accessible au public à la racine ou dans le répertoire .known de l'application, qui définit clairement un lien ou une adresse électronique permettant aux personnes de contacter les propriétaires pour des questions de sécurité. | | ✓ | ✓ | 1059 |
+
+## V1.2 Exigences architecturales d'authentification
+
+Lors de la conception de l'authentification, il importe peu que vous disposiez d'un matériel solide permettant une authentification multifactorielle si un attaquant peut réinitialiser un compte en appelant un centre d'appel et en répondant à des questions courantes. Lors de la vérification de l'identité, toutes les méthodes d'authentification doivent avoir la même force.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.2.1** | Vérifier que les communications entre les composants de l'application, y compris les API, les intergiciels et les couches de données, sont authentifiées et utilisent des comptes utilisateurs individuels. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 306 |
+| **1.2.2** | Vérifiez que l'application utilise un mécanisme d'authentification unique et contrôlé qui est connu pour être sûr, qui peut être étendu pour inclure une authentification forte et qui dispose d'une journalisation et d'une surveillance suffisantes pour détecter les abus ou les violations de compte. | | ✓ | ✓ | 306 |
+| **1.2.3** | Vérifier que toutes les méthodes d'authentification et les API de gestion de l'identité mettent en œuvre un contrôle de sécurité de l'authentification cohérent, de sorte qu'il n'y ait pas d'alternatives plus faibles par rapport au risque de l'application. | | ✓ | ✓ | 306 |
+
+## V1.3 Exigences architecturales pour la gestion des sessions
+
+Il s'agit d'un point de repère pour les futures exigences architecturales.
+
+## V1.4 Exigences architecturales en matière de contrôle d'accès
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.4.1** | Vérifiez que des points d'application de confiance tels que les passerelles de contrôle d'accès, les serveurs et les fonctions sans serveur font respecter les contrôles d'accès. N'imposez jamais de contrôles d'accès au client. | | ✓ | ✓ | 602 |
+| **1.4.2** | Vérifiez que la solution de contrôle d'accès choisie est suffisamment souple pour répondre aux besoins de l'application. | | ✓ | ✓ | 284 |
+| **1.4.3** | Vérifier l'application du principe du moindre privilège dans les fonctions, fichiers de données, URL, contrôleurs, services et autres ressources. Cela implique une protection contre l'usurpation et l'élévation des privilèges. | | ✓ | ✓ | 272 |
+| **1.4.4** | Vérifier que les communications entre les composants de l'application, y compris les API, les intergiciels et les couches de données, sont effectuées avec le moins de privilèges possibles. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 272 |
+| **1.4.5** | Vérifier que l'application utilise un mécanisme de contrôle d'accès unique et bien étudié pour accéder aux données et ressources protégées. Toutes les demandes doivent passer par ce mécanisme unique pour éviter le copier-coller ou les chemins alternatifs non sécurisés. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 284 |
+| **1.4.6** | Vérifiez que le contrôle d'accès basé sur les attributs ou les caractéristiques est utilisé, c'est-à-dire que le code vérifie l'autorisation de l'utilisateur pour une caractéristique ou une donnée plutôt que son seul rôle. Les autorisations doivent tout de même être attribuées à l'aide de rôles. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 275 |
+
+## V1.5 Exigences architecturales d'entrée et de sortie
+
+Dans la version 4.0, nous avons abandonné le terme "côté serveur" ayant la connotation de limite de confiance. La limite de confiance est toujours un enjeu - il est possible de contourner les décisions prises sur des navigateurs ou des appareils clients non fiables. Cependant, dans les déploiements architecturaux courants d'aujourd'hui, le point d'application de la confiance a considérablement changé. Par conséquent, lorsque le terme "couche de service de confiance" est utilisé dans l'ASVS, nous entendons par là tout point d'application de confiance, quel que soit son emplacement, tel qu'un microservice, un API sans serveur, côté serveur, un API de confiance sur un périphérique client qui a un démarrage sécurisé, des API partenaires ou externes, etc.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.5.1** | Vérifier que les exigences en matière d'entrée et de sortie définissent clairement la manière de traiter et d'exploiter les données en fonction du type, du contenu et de la conformité aux lois, règlements et autres politiques applicables. | | ✓ | ✓ | 1029 |
+| **1.5.2** | Vérifiez que la sérialisation n'est pas utilisée lorsque vous communiquez avec des clients non fiables. Si cela n'est pas possible, assurez-vous que des contrôles d'intégrité adéquats (et éventuellement un cryptage si des données sensibles sont envoyées) sont appliqués pour empêcher les attaques de désérialisation, y compris l'injection d'objets. | | ✓ | ✓ | 502 |
+| **1.5.3** | Vérifiez que la validation des entrées est appliquée sur une couche de service de confiance. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 602 |
+| **1.5.4** | Vérifiez que l'encodage de sortie se fait à proximité ou par l'interprète auquel il est destiné. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 116 |
+
+## V1.6 Exigences en matière d'architecture cryptographique
+
+Les applications doivent être conçues avec une architecture cryptographique solide pour protéger les données selon leur classification. Tout chiffrer est un gaspillage, ne rien chiffrer est une négligence légale. Un équilibre doit être trouvé, généralement lors de la conception architecturale ou de haut niveau, des sprints de conception ou des pics architecturaux. Concevoir la cryptographie au fur et à mesure ou l'adapter coûtera inévitablement beaucoup plus cher à mettre en œuvre de manière sécurisée que de l'intégrer dès le départ.
+
+Les exigences architecturales sont intrinsèques au code, et donc difficiles à unifier ou à intégrer dans les tests. Les exigences architecturales doivent être prises en compte dans les normes de codage, tout au long de la phase de codage, et doivent être examinées au cours de l'architecture de sécurité, des revues du code par les pairs, ou des rétrospectives.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.6.1** | Vérifier qu'il existe une politique explicite de gestion des clés cryptographiques et que le cycle de vie d'une clé cryptographique suit une norme de gestion des clés telle que NIST SP 800-57. | | ✓ | ✓ | 320 |
+| **1.6.2** | Vérifier que les consommateurs de services cryptographiques protègent les clés et autres secrets en utilisant des coffres-forts de clés ou des alternatives basées sur l'API. | | ✓ | ✓ | 320 |
+| **1.6.3** | Vérifiez que toutes les clés et tous les mots de passe sont remplaçables et font partie d'un processus bien défini de recryptage des données sensibles. | | ✓ | ✓ | 320 |
+| **1.6.4** | Vérifier que les clés symétriques, les mots de passe ou les secrets d'API générés par les clients ou partagés avec eux ne sont utilisés que pour protéger des secrets à faible risque, comme le chiffrement du stockage local, ou des utilisations éphémères temporaires comme l'obscurcissement des paramètres. Le partage de secrets avec les clients est équivalent à du texte en clair et, d'un point de vue architectural, il doit être traité comme tel. | | ✓ | ✓ | 320 |
+
+## V1.7 Erreurs, enregistrement et vérification des exigences architecturales
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.7.1** | Vérifier qu'un format de journalisation communs soit utilisés dans le système. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 1009 |
+| **1.7.2** | Vérifiez que les journaux sont transmis de manière sécurisée à un système de préférence distant pour analyse, détection, alerte et escalade. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | |
+
+## V1.8 Exigences architecturales en matière de protection des données et de la vie privée
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.8.1** | Vérifier que toutes les données sensibles sont identifiées et classées en niveaux de protection. | | ✓ | ✓ | |
+| **1.8.2** | Vérifier que tous les niveaux de protection sont associés à un ensemble d'exigences de protection, telles que des exigences de cryptage, d'intégrité, de conservation, de respect de la vie privée et d'autres exigences de confidentialité, et que celles-ci sont appliquées dans l'architecture. | | ✓ | ✓ | |
+
+## V1.9 Exigences en matière d'architecture des communications
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.9.1** | Vérifier que l'application chiffre les communications entre les composants, en particulier lorsque ces composants se trouvent dans des conteneurs, systèmes, sites ou fournisseurs de cloud différents. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 319 |
+| **1.9.2** | Vérifier que les composants de l'application vérifient l'authenticité de chaque partie d'un lien de communication afin de prévenir les attaques de type "man-in-the-middle". Par exemple, les composants d'application doivent valider les certificats et les chaînes TLS. | | ✓ | ✓ | 295 |
+
+## V1.10 Exigences en matière d'architecture des logiciels malveillants
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.10.1** | Vérifier qu'un système de contrôle du code source est utilisé, avec des procédures pour s'assurer que les enregistrements sont accompagnés de tickets d'émission ou de modification. Le système de contrôle du code source doit disposer d'un contrôle d'accès et d'utilisateurs identifiables pour permettre la traçabilité de toute modification. | | ✓ | ✓ | 284 |
+
+## V1.11 Exigences en matière d'architecture de la logique d'entreprise
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.11.1** | Vérifier la définition et la documentation de tous les composants de l'application en ce qui concerne la logique métier ou de sécurité qu'ils fournissent. | | ✓ | ✓ | 1059 |
+| **1.11.2** | Vérifiez que tous les flux de logique métier de grande valeur, y compris l'authentification, la gestion de session et le contrôle d'accès, ne partagent pas un état non synchronisé. | | ✓ | ✓ | 362 |
+| **1.11.3** | Vérifier que tous les flux de logique métier de grande valeur, y compris l'authentification, la gestion de session et le contrôle d'accès, sont sécurisés et résistants aux conditions de concurrence ("race condition") au temps de contrôle et au temps d'utilisation. | | | ✓ | 367 |
+
+## V1.12 Téléchargement de fichiers sécurisés Exigences architecturales
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.12.1** | Vérifiez que les fichiers envoyés par l'utilisateur sont stockés en dehors de la racine du site web. | | ✓ | ✓ | 552 |
+| **1.12.2** | Vérifiez que les fichiers envoyés par l'utilisateur - s'ils doivent être affichés ou téléchargés à partir de l'application - sont servis par des téléchargements en flux d'octets, ou à partir d'un domaine sans rapport, comme un compartiment de stockage de fichiers en nuage. Mettre en œuvre une politique de sécurité du contenu (CSP) appropriée pour réduire le risque de vecteurs XSS ou d'autres attaques provenant du fichier téléchargé. | | ✓ | ✓ | 646 |
+
+## V1.13 Exigences architecturales de l'API
+
+Il s'agit d'un point de repère pour les futures exigences architecturales.
+
+## V1.14 Configuration des exigences architecturales
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **1.14.1** | Vérifier l'utilisation d'un compte à faible privilège pour tous les composants d'application, services et serveurs. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 250 |
+| **1.14.2** | Vérifiez la séparation des composants de différents niveaux de confiance via des contrôles de sécurité bien définis, des règles de pare-feu, des passerelles API, des proxys inverses, des groupes de sécurité basés sur le cloud ou des mécanismes similaires. | | ✓ | ✓ | 923 |
+| **1.14.3** | Vérifier que les signatures binaires, les connexions de confiance et les nœuds vérifiés sont utilisés pour déployer des binaires sur des dispositifs distants. | | ✓ | ✓ | 494 |
+| **1.14.4** | Vérifier que le pipeline de construction signale les composants obsolètes ou peu sûrs et prend les mesures appropriées. | | ✓ | ✓ | 1104 |
+| **1.14.5** | Vérifier que le pipeline de construction contient une étape de compilation pour créer automatiquement et vérifier le déploiement sécurisé de l'application, en particulier si l'infrastructure de l'application est définie par un logiciel, comme les scripts de construction d'un environnement en nuage. | | ✓ | ✓ | |
+| **1.14.6** | Vérifier que les déploiements d'applications sont correctement sandboxés, conteneurisés et/ou isolés au niveau du réseau pour retarder et dissuader les attaquants d'attaquer d'autres applications, en particulier lorsqu'ils effectuent des actions sensibles ou dangereuses telles que la désérialisation. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 |
+| **1.14.7** | Vérifiez que l'application n'utilise pas de technologies côté client non prises en charge, peu sûres ou dépréciées telles que les plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou les applets Java côté client. | | ✓ | ✓ | 477 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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-5/final)
diff --git a/4.0/fr/0x11-V2-Authentication.md b/4.0/fr/0x11-V2-Authentication.md
new file mode 100644
index 0000000000..250506dd8b
--- /dev/null
+++ b/4.0/fr/0x11-V2-Authentication.md
@@ -0,0 +1,211 @@
+# V2 : Exigences de vérification de l'authentification
+
+## Objectif de contrôle
+
+L'authentification est l'acte qui consiste à établir ou à confirmer qu'une personne (ou quelque chose) est authentique et que les affirmations faites par une personne ou au sujet d'un dispositif sont correctes, résistantes à l'usurpation d'identité et empêchent la récupération ou l'interception des mots de passe.
+
+Lorsque l'ASVS a été publiée pour la première fois, le nom d'utilisateur + mot de passe était la forme d'authentification la plus courante en dehors des systèmes de haute sécurité. L'authentification à facteurs multiples (MFA) était communément acceptée dans les cercles de sécurité mais rarement requise ailleurs. Avec l'augmentation du nombre de brèches de mots de passe, l'idée que les noms d'utilisateur sont en quelque sorte confidentiels et les mots de passe inconnus, a rendu de nombreux contrôles de sécurité inefficaces. Par exemple, le NIST 800-63 considère les noms d'utilisateur et l'authentification basée sur la connaissance (KBA) comme des informations publiques, les notifications par SMS et par courrier électronique comme des [types d'authentificateurs "restreints"](https://pages.nist.gov/800-63-FAQ/#q-b1), et les mots de passe comme des préviolations. Cette réalité rend inutiles les authentificateurs basés sur la connaissance, la récupération de SMS et de courriels, l'historique des mots de passe, la complexité et les contrôles de rotation. Ces contrôles ont toujours été peu utiles, obligeant souvent les utilisateurs à trouver des mots de passe faibles tous les quelques mois, mais avec la publication de plus de 5 milliards de violations de noms d'utilisateur et de mots de passe, il est temps de passer à autre chose.
+
+De toutes les sections de l'ASVS, ce sont les chapitres sur l'authentification et la gestion des sessions qui ont le plus changé. L'adoption de pratiques de pointe efficaces et fondées sur des preuves sera un défi pour beaucoup, et c'est tout à fait normal. Nous devons commencer dès maintenant la transition vers un avenir post-mot de passe.
+
+## NIST 800-63 - Norme d'authentification moderne et fondée sur des preuves
+
+[NIST 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.html) est une norme moderne, basée sur des preuves, et représente le meilleur conseil disponible, indépendamment de son applicabilité. La norme est utile à toutes les organisations du monde entier, mais elle est particulièrement pertinente pour les agences américaines et celles qui traitent avec des agences américaines.
+
+ La terminologie de la norme NIST 800-63 peut être un peu déroutante au début, surtout si vous n'êtes habitué qu'à l'authentification par nom d'utilisateur + mot de passe. Des progrès en matière d'authentification moderne sont nécessaires, nous devons donc introduire une terminologie qui deviendra courante à l'avenir, mais nous comprenons la difficulté de compréhension jusqu'à ce que l'industrie s'habitue à ces nouveaux termes. Nous avons fourni un glossaire à la fin de ce chapitre pour vous aider. Nous avons reformulé de nombreuses exigences afin de satisfaire l'intention, plutôt que sa forme. Par exemple, l'ASVS utilise le terme "mot de passe" alors que le NIST utilise "secret mémorisé" tout au long de cette norme.
+
+L'authentification ASVS V2, la gestion de session V3 et, dans une moindre mesure, les contrôles d'accès V4 ont été adaptés pour constituer un sous-ensemble conforme de certains contrôles NIST 800-63b, axés sur les menaces communes et les faiblesses d'authentification couramment exploitées. Lorsque la conformité totale à la norme NIST 800-63 est requise, veuillez consulter la norme NIST 800-63.
+
+### Sélection d'un niveau NIST AAL approprié
+
+La norme de vérification de la sécurité des applications a tenté de faire correspondre les exigences ASVS L1 à celles du NIST AAL1, L2 à AAL2, et L3 à AAL3. Cependant, l'approche du niveau 1 ASVS en tant que contrôles "essentiels" n'est pas nécessairement le niveau AAL correct pour vérifier une application ou une API. Par exemple, si l'application est une application de niveau 3 ou a des exigences réglementaires pour être AAL3, le niveau 3 doit être choisi dans les sections V2 et V3 Gestion des sessions. Le choix du niveau d'affirmation d'authentification (AAL) conforme aux normes NIST doit être effectué conformément aux directives NIST 800-63b, comme indiqué dans la section *Selecting AAL* du [NIST 800-63b Section 6.2](https://pages.nist.gov/800-63-3/sp800-63-3.html#AAL_CYOA).
+
+## Légende
+
+Les applications peuvent toujours dépasser les exigences du niveau actuel, surtout si l'authentification moderne figure sur la feuille de route d'une application. Auparavant, l'ASVS exigeait une AMF obligatoire. Le NIST n'exige pas d'AMF obligatoire. C'est pourquoi nous avons utilisé une désignation optionnelle dans ce chapitre pour indiquer les cas où l'ASVS encourage mais n'exige pas de contrôle. Les clés suivantes sont utilisées tout au long de cette norme :
+
+| Marque | Description |
+| :---: | :---: |
+| | Non requis |
+| o | Recommandé, mais pas obligatoire |
+| ✓ | Obligatoire |
+
+## V2.1 Exigences en matière de sécurité des mots de passe
+
+Les mots de passe, appelés "Memorized Secrets" par NIST 800-63, comprennent les mots de passe, les codes PIN, les motifs de déverrouillage, le choix du chaton correct ou d'un autre élément d'image, et les phrases de passe. Ils sont généralement considérés comme "quelque chose que vous savez" et sont souvent utilisés comme des authentificateurs à facteur unique. L'utilisation continue de l'authentification à un facteur unique pose des problèmes importants, notamment les milliards de noms d'utilisateur et de mots de passe valides divulgués sur l'internet, les mots de passe par défaut ou faibles, les tables arc-en-ciel et les dictionnaires ordonnés des mots de passe les plus courants.
+
+Les applications devraient fortement encourager les utilisateurs à s'inscrire à l'authentification multi-facteurs, et devraient permettre aux utilisateurs de réutiliser les jetons qu'ils possèdent déjà, tels que les jetons FIDO ou U2F, ou de se relier à un fournisseur de services d'accréditation qui fournit une authentification multi-facteurs.
+
+Les fournisseurs de services d'accréditation (CSP) fournissent une identité fédérée aux utilisateurs. Les utilisateurs auront souvent plus d'une identité avec plusieurs CSP, comme une identité d'entreprise utilisant Azure AD, Okta, Ping Identity ou Google, ou une identité de consommateur utilisant Facebook, Twitter, Google ou WeChat, pour ne citer que quelques alternatives courantes. Cette liste n'est pas une approbation de ces entreprises ou services, mais simplement un encouragement pour les développeurs à prendre en compte la réalité que de nombreux utilisateurs ont plusieurs identités établies. Les organisations devraient envisager de s'intégrer aux identités des utilisateurs existants, conformément au profil de risque de la force du CSP en matière de vérification d'identité. Par exemple, il est peu probable qu'une organisation gouvernementale accepte une identité de média social comme identifiant pour des systèmes sensibles, car il est facile de créer de fausses identités ou de jeter des identités, alors qu'une société de jeux pour mobiles pourrait bien avoir besoin de s'intégrer aux principales plateformes de médias sociaux pour accroître sa base de joueurs actifs.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.1.1** | Vérifiez que les mots de passe définis par l'utilisateur comportent au moins 12 caractères. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.2** | Vérifiez que les mots de passe de 64 caractères ou plus sont autorisés. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.3** | Vérifiez que le mot de passe n'est pas tronqué. Toutefois, des espaces multiples consécutifs peuvent être remplacés par un seul espace. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.4** | Vérifiez que tout caractère Unicode imprimable, y compris les caractères neutres comme les espaces et les Emojis, sont autorisés dans les mots de passe. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.5** | Vérifier que les utilisateurs peuvent changer leur mot de passe. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 |
+| **2.1.6** | Vérifiez que la fonctionnalité de changement de mot de passe nécessite le mot de passe actuel et le nouveau mot de passe de l'utilisateur. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 |
+| **2.1.7** | Vérifiez que les mots de passe soumis lors de l'enregistrement du compte, de la connexion et de la modification du mot de passe sont vérifiés par rapport à un ensemble de mots de passe non respectés, soit localement (comme les 1 000 ou 10 000 mots de passe les plus courants qui correspondent à la politique du système en matière de mots de passe), soit en utilisant une API externe. En cas d'utilisation d'une API, il convient d'utiliser un mécanisme de vérification de l'absence de connaissance ou un autre mécanisme pour s'assurer que le mot de passe en texte clair n'est pas envoyé ou utilisé pour vérifier l'état de violation du mot de passe. En cas de violation du mot de passe, l'application doit demander à l'utilisateur de définir un nouveau mot de passe non violé. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.8** | Vérifiez qu'un compteur de force de mot de passe est fourni pour aider les utilisateurs à définir un mot de passe plus fort. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.9** | Vérifiez qu'il n'existe pas de règles de composition des mots de passe limitant le type de caractères autorisés. Il ne doit pas y avoir restrictions sur l'utilisation de majuscules ou de minuscules, de chiffres ou de caractères spéciaux. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.10** | Vérifiez qu'il n'y a pas d'exigences en matière de rotation périodique du mots de passe ou d'historique des mots de passe. | ✓ | ✓ | ✓ | 263 | 5.1.1.2 |
+| **2.1.11** | Vérifiez que la fonction "coller", les aides de mot de passe du navigateur et les gestionnaires de mots de passe externes sont autorisés. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.12** | Vérifiez que l'utilisateur peut choisir soit de visualiser temporairement la totalité du mot de passe masqué, soit de visualiser temporairement le dernier caractère tapé du mot de passe sur les plateformes qui n'ont pas cette fonctionnalité en natif. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+
+Note : L'objectif de permettre à l'utilisateur de visualiser son mot de passe ou de voir temporairement le dernier caractère est d'améliorer la facilité d'utilisation de la saisie des données d'identification, notamment en ce qui concerne l'utilisation de mots de passe plus longs, de phrases de passe et de gestionnaires de mots de passe. Une autre raison d'inclure cette exigence est de dissuader ou d'empêcher les rapports de test exigeant inutilement des organisations de passer outre le comportement du champ de mot de passe de la plate-forme native pour supprimer cette expérience de sécurité moderne et conviviale.
+
+## V2.2 Exigences générales relatives aux authentificateurs
+
+L'agilité des authentificateurs est essentielle pour que les applications soient à l'épreuve du temps. Les vérificateurs d'applications Refactor permettent d'ajouter des authentificateurs supplémentaires en fonction des préférences de l'utilisateur, et de mettre à la retraite de manière ordonnée les authentificateurs obsolètes ou dangereux.
+
+Le NIST considère le courrier électronique et les SMS comme des [types d'authentificateurs "restreints"](https://pages.nist.gov/800-63-FAQ/#q-b1), et il est probable qu'ils soient retirés du NIST 800-63 et donc de l'ASVS à un moment donné dans le futur. Les applications devraient prévoir une feuille de route qui ne nécessite pas l'utilisation du courrier électronique ou des SMS.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.2.1** | Vérifiez que les contrôles anti-automatisation sont efficaces pour atténuer les attaques par violation des tests d'accréditation, par énumération exhaustive (brute-force) et par verrouillage de compte. Ces contrôles comprennent le blocage des mots de passe les plus courants, les verrouillages progressifs, la limitation de débit, les CAPTCHA, les délais toujours plus longs entre les tentatives, les restrictions d'adresse IP ou les restrictions basées sur le risque telles que l'emplacement, la première connexion sur un appareil, les tentatives récentes de déverrouillage du compte, ou autres. Vérifiez qu'il n'y a pas plus de 100 tentatives infructueuses par heure sur un seul compte. | ✓ | ✓ | ✓ | 307 | 5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2 |
+| **2.2.2** | Vérifier que l'utilisation d'authentificateurs faibles (tels que les SMS et les e-mails) se limite à la vérification secondaire et à l'approbation des transactions et ne remplace pas les méthodes d'authentification plus sûres. Vérifiez que les méthodes plus fortes sont proposées avant les méthodes faibles, que les utilisateurs sont conscients des risques, ou que des mesures appropriées sont en place pour limiter les risques de compromission du compte. | ✓ | ✓ | ✓ | 304 | 5.2.10 |
+| **2.2.3** | Vérifier que des notifications sécurisées sont envoyées aux utilisateurs après la mise à jour des détails d'authentification, tels que la réinitialisation de l'identifiant, le changement d'adresse électronique ou d'adresse, la connexion à partir d'un lieu inconnu ou risqué. L'utilisation de notifications "push" - plutôt que de SMS ou d'e-mail - est préférable, mais en l'absence de notifications "push", les SMS ou les e-mails sont acceptables tant qu'aucune information sensible n'est divulguée dans la notification. | ✓ | ✓ | ✓ | 620 | |
+| **2.2.4** | Vérifier la résistance à l'usurpation d'identité contre le phishing, comme l'utilisation de l'authentification multi-facteurs, les dispositifs cryptographiques avec intention (comme les clés connectées avec un "push to authenticate"), ou à des niveaux AAL supérieurs, les certificats côté client. | | | ✓ | 308 | 5.2.5 |
+| **2.2.5** | Vérifier que lorsqu'un fournisseur de services d'accréditation (CSP) et l'application vérifiant l'authentification sont séparés, un TLS mutuellement authentifié est en place entre les deux points terminaux. | | | ✓ | 319 | 5.2.6 |
+| **2.2.6** | Vérifier la résistance au attaque de rejeu par l'utilisation obligatoire de dispositifs OTP, d'authentificateurs cryptographiques ou de codes de consultation. | | | ✓ | 308 | 5.2.8 |
+| **2.2.7** | Vérifier l'intention d'authentification en exigeant l'entrée d'un jeton OTP ou une action initiée par l'utilisateur telle qu'une pression sur un bouton d'une clé matérielle FIDO. | | | ✓ | 308 | 5.2.9 |
+
+## V2.3 Exigences relatives au cycle de vie des authentificateurs
+
+Les authentificateurs sont les mots de passe, les jetons logiciels, les jetons matériels et les dispositifs biométriques. Le cycle de vie des authentificateurs est essentiel pour la sécurité d'une application - si quelqu'un peut s'enregistrer lui-même sur un compte sans preuve d'identité, il ne peut guère faire confiance à l'affirmation de son identité. Pour les sites de médias sociaux comme Reddit, c'est tout à fait normal. Pour les systèmes bancaires, il est essentiel de mettre davantage l'accent sur l'enregistrement et la délivrance de justificatifs d'identité et de dispositifs pour assurer la sécurité de l'application.
+
+Remarque : les mots de passe ne doivent pas avoir une durée de vie maximale ni être soumis à une rotation. Les mots de passe doivent être vérifiés et non remplacés régulièrement.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.3.1** | Vérifier que les mots de passe ou codes d'activation initiaux générés par le système DOIVENT être générés de manière aléatoire et sécurisée, DOIVENT comporter au moins 6 caractères, PEUVENT contenir des lettres et des chiffres, et expirent après une courte période de temps. Ces secrets initiaux ne doivent pas être autorisés à devenir le mot de passe à long terme. | ✓ | ✓ | ✓ | 330 | 5.1.1.2 / A.3 |
+| **2.3.2** | Vérifiez que l'inscription et l'utilisation de dispositifs d'authentification fournis par l'abonné sont prises en charge, comme les jetons U2F ou FIDO. | | ✓ | ✓ | 308 | 6.1.3 |
+| **2.3.3** | Vérifier que les instructions de renouvellement sont envoyées suffisamment tôt pour renouveler les authentificateurs à durée déterminée. | | ✓ | ✓ | 287 | 6.1.4 |
+
+## V2.4 Exigences en matière de stockage des identifiants
+
+Les architectes et les développeurs doivent se conformer à cette section lorsqu'ils construisent ou remanient du code. Cette section ne peut être entièrement vérifiée qu'en utilisant la révision du code source ou par des tests unitaires ou d'intégration sécurisés. Les tests d'intrusions ne peuvent pas identifier l'un de ces problèmes.
+
+La liste des fonctions de dérivation de clés à sens unique approuvées est détaillée dans la section 5.1.1.2 de la norme NIST 800-63 B, et dans [BSI Kryptographische Verfahren : Empfehlungen und Schlussellängen (2018)](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile). Ces choix peuvent être remplacés par les derniers algorithmes nationaux ou régionaux et les dernières normes de longueur de clé.
+
+Cette section ne peut pas être soumise à un test de pénétration, les contrôles ne sont donc pas marqués comme L1. Cependant, cette section est d'une importance vitale pour la sécurité des données d'identifications en cas de vol. Si vous bifurquez l'ASVS pour une directive sur l'architecture ou le codage ou une liste de contrôle pour l'examen du code source, veuillez replacer ces contrôles en L1 dans votre version privée.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.4.1** | Vérifiez que les mots de passe sont stockés sous une forme qui résiste aux attaques hors ligne. Les mots de passe DOIVENT être salés et hachés en utilisant une fonction approuvée à sens unique ou de hachage de mot de passe. Les fonctions de dérivation de clé et de hachage de mot de passe prennent un mot de passe, un sel et un facteur de coût (ex. : nombre d’itération algorithmique) comme intrants lors de la génération d'un hachage de mot de passe. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 |
+| **2.4.2** | Vérifiez que le sel a une longueur d'au moins 32 bits et qu'il est choisi arbitrairement pour minimiser les collisions de la valeur du sel parmi les hashs stockés. Pour chaque authentifiant, une valeur de sel unique et le hachage qui en résulte DOIVENT être stockés. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 |
+| **2.4.3** | Vérifiez que si le PBKDF2 est utilisé, le nombre d'itérations DOIT être aussi important que les performances du serveur de vérification le permettent, généralement au moins 100 000 itérations. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 |
+| **2.4.4** | Vérifiez que si bcrypt est utilisé, le facteur de travail DOIT être aussi important que les performances du serveur de vérification le permettent, généralement au moins 13. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 916 | 5.1.1.2 |
+| **2.4.5** | Vérifier qu'une itération supplémentaire d'une fonction de dérivation clé est effectuée, en utilisant une valeur de sel qui est secrète et connue uniquement du vérificateur. Générer la valeur de sel en utilisant un générateur de bits aléatoires approuvé [SP 800-90Ar1] et fournir au moins la sécurité minimale spécifiée dans la dernière révision de la norme SP 800-131A. La valeur de sel secrète DOIT être stockée séparément des mots de passe hachés (par exemple, dans un dispositif spécialisé comme un module de sécurité matériel). | | ✓ | ✓ | 916 | 5.1.1.2 |
+
+Lorsque des normes américaines sont mentionnées, une norme régionale ou locale peut être utilisée à la place ou en plus de la norme américaine, selon les besoins.
+
+## V2.5 Exigences en matière de récupération des identifiants
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.5.1** | Vérifiez que si un secret d'activation initiale ou de récupération du système est envoyé à l'utilisateur, il est à usage unique, limité dans le temps et aléatoire. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 |
+| **2.5.2** | Vérifier que les indices de mot de passe ou l'authentification basée sur la connaissance (dites "questions secrètes") ne sont pas présents. | ✓ | ✓ | ✓ | 640 | 5.1.1.2 |
+| **2.5.3** | Vérifiez que la récupération du mot de passe ne révèle en aucune façon le mot de passe actuel. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 |
+| **2.5.4** | Vérifiez que les comptes partagés ou par défaut ne sont pas présents (par exemple "root", "admin" ou "sa"). | ✓ | ✓ | ✓ | 16 | 5.1.1.2 / A.3 |
+| **2.5.5** | Vérifier que si un facteur d'authentification est modifié ou remplacé, l'utilisateur est informé de cet événement. | ✓ | ✓ | ✓ | 304 | 6.1.2.3 |
+| **2.5.6** | Vérifier les mots de passe oubliés, et les autres chemins de récupération utilisent un mécanisme de récupération sécurisé, tel que TOTP ou autre soft token, mobile push, ou un autre mécanisme de récupération hors ligne. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 |
+| **2.5.7** | Vérifier qu'en cas de perte des facteurs d'authentification OTP ou multi-facteurs, la preuve d'identité est effectuée au même niveau que lors de l'inscription. | | ✓ | ✓ | 308 | 6.1.2.3 |
+
+## V2.6 Exigences relatives aux vérificateurs des secrets
+
+Les tables d’authentifications secrètes sont des listes pré-générées de codes secrets, similaires aux numéros d'autorisation de transaction (TAN), aux codes de récupération des médias sociaux ou à une grille contenant un ensemble de valeurs aléatoires. Ils sont distribués aux utilisateurs en toute sécurité. Ces codes de recherche sont utilisés une fois, et une fois qu'ils sont tous utilisés, la liste secrète de recherche est jetée. Ce type d'authentificateur est considéré comme "quelque chose que vous avez".
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.6.1** | Vérifiez que les secrets de la table d’authentification ne peuvent être utilisés qu'une seule fois. | | ✓ | ✓ | 308 | 5.1.2.2 |
+| **2.6.2** | Vérifiez que les secrets de la table d’authentification ont un caractère aléatoire suffisant (112 bits d'entropie) ou, s'ils ont moins de 112 bits d'entropie, qu'ils sont salés avec un sel unique et aléatoire de 32 bits et hachés avec un hachage unidirectionnel approuvé. | | ✓ | ✓ | 330 | 5.1.2.2 |
+| **2.6.3** | Vérifiez que les secrets de la table d’authentification résistent aux attaques hors ligne, comme les valeurs prévisibles. | | ✓ | ✓ | 310 | 5.1.2.2 |
+
+## V2.7 Exigences relatives aux vérificateurs hors bande
+
+Dans le passé, un vérificateur hors bande courant aurait été un courriel ou un SMS contenant un lien de réinitialisation de mot de passe. Les attaquants utilisent ce faible mécanisme pour réinitialiser des comptes qu'ils ne contrôlent pas encore, par exemple en prenant le compte de courrier électronique d'une personne et en réutilisant tout lien de réinitialisation découvert. Il existe de meilleurs moyens de gérer la vérification hors bande.
+
+Les authentificateurs hors bande sécurisés sont des dispositifs physiques qui peuvent communiquer avec le vérificateur par un canal secondaire sécurisé. Les notifications "push" vers les appareils mobiles en sont des exemples. Ce type d'authentificateur est considéré comme "quelque chose que vous avez". Lorsqu'un utilisateur souhaite s'authentifier, l'application de vérification envoie un message à l'authentificateur hors bande via une connexion à l'authentificateur directement ou indirectement par le biais d'un service tiers. Le message contient un code d'authentification (généralement un nombre aléatoire de six chiffres ou un dialogue d'approbation modale). L'application de vérification attend de recevoir le code d'authentification par le canal principal et compare le hachage de la valeur reçue au hachage du code d'authentification original. En cas de correspondance, le vérificateur hors bande peut supposer que l'utilisateur s'est authentifié.
+
+L'ASVS suppose que seuls quelques développeurs développeront de nouveaux authentificateurs hors bande, tels que les notifications "push", et donc que les contrôles suivants de l'ASVS s'appliquent aux vérificateurs, tels que l'API d'authentification, les applications et les mises en œuvre de l'authentification unique. Si vous développez un nouvel authentificateur hors bande, veuillez vous référer à NIST 800-63B 5.1.3.1.
+
+Les authentificateurs hors bande dangereux tels que le courrier électronique et la voix sur IP ne sont pas autorisés. Les authentifications PSTN et SMS sont actuellement "restreintes" par le NIST et devraient être interdites au profit des notifications "push" ou similaires. Si vous devez utiliser l'authentification hors bande par téléphone ou SMS, veuillez consulter 5.1.3.3.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.7.1** | Vérifiez que les authentificateurs de texte en clair hors bande (NIST "restreint"), tels que les SMS ou le PSTN, ne sont pas proposés par défaut, et que des alternatives plus fortes, telles que les notifications "push", sont proposées en premier lieu. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 |
+| **2.7.2** | Vérifiez que le vérificateur hors bande expire les demandes d'authentification, les codes ou les jetons hors bande après 10 minutes. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 |
+| **2.7.3** | Vérifiez que les demandes d'authentification, codes ou jetons hors bande du vérificateur ne sont utilisables qu'une seule fois, et uniquement pour la demande d'authentification originale. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 |
+| **2.7.4** | Vérifier que l'authentificateur et le vérificateur hors bande communiquent sur un canal indépendant sécurisé. | ✓ | ✓ | ✓ | 523 | 5.1.3.2 |
+| **2.7.5** | Vérifiez que le vérificateur hors bande ne conserve qu'une version hachée du code d'authentification. | | ✓ | ✓ | 256 | 5.1.3.2 |
+| **2.7.6** | Vérifiez que le code d'authentification initial est généré par un générateur de nombres aléatoires sécurisé, contenant au moins 20 bits d'entropie (en général, un nombre aléatoire de six chiffres est suffisant). | | ✓ | ✓ | 310 | 5.1.3.2 |
+
+## V2.8 Exigences relatives aux vérificateurs uniques à facteur unique ou à facteurs multiples
+
+Les mots de passe à usage unique (OTP) sont des jetons physiques ou logiciels qui affichent un défi pseudo-aléatoire à usage unique en constante évolution. Ces dispositifs rendent le phishing (usurpation d'identité) difficile, mais pas impossible. Ce type d'authentifiant est considéré comme "quelque chose que vous avez". Les jetons multi-facteurs sont similaires aux OTP à facteur unique, mais nécessitent un code PIN valide, un déverrouillage biométrique, une insertion USB ou un appariement NFC ou une valeur supplémentaire (comme les calculatrices de signature de transaction) à saisir pour créer l'OTP final.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.8.1** | Vérifier que les OTP basées sur le temps ont une durée de vie définie avant d'expirer. | ✓ | ✓ | ✓ | 613 | 5.1.4.2 / 5.1.5.2 |
+| **2.8.2** | Vérifier que les clés symétriques utilisées pour vérifier les OTP soumises sont hautement protégées, par exemple en utilisant un module de sécurité matériel ou un stockage de clés basé sur un système d'exploitation sécurisé. | | ✓ | ✓ | 320 | 5.1.4.2 / 5.1.5.2|
+| **2.8.3** | Vérifier que des algorithmes cryptographiques approuvés sont utilisés dans la génération, dans la préparation et dans la vérification des OTP. | | ✓ | ✓ | 326 | 5.1.4.2 / 5.1.5.2 |
+| **2.8.4** | Vérifiez que l'OTP basé sur le temps ne peut être utilisé qu'une seule fois pendant la période de validité. | | ✓ | ✓ | 287 | 5.1.4.2 / 5.1.5.2 |
+| **2.8.5** | Vérifier que si un jeton OTP multi-facteur basé sur le temps est réutilisé pendant la période de validité, il est enregistré et rejeté avec des notifications sécurisées envoyées au détenteur du dispositif. | | ✓ | ✓ | 287 | 5.1.5.2 |
+| **2.8.6** | Vérifier que le générateur OTP physique à facteur unique peut être révoqué en cas de vol ou autre perte. S'assurer que la révocation est immédiatement effective pour toutes les sessions connectées, quel que soit le lieu. | | ✓ | ✓ | 613 | 5.2.1 |
+| **2.8.7** | Vérifiez que les authentificateurs biométriques sont limités à une utilisation en tant que facteurs secondaires en conjonction avec quelque chose que vous avez et quelque chose que vous connaissez. | | o | ✓ | 308 | 5.2.3 |
+
+## V2.9 Exigences relatives aux vérificateurs de logiciels et d'appareils cryptographiques
+
+Les clés de sécurité cryptographiques sont des cartes à puce ou des clés FIDO, où l'utilisateur doit brancher ou apparier le dispositif cryptographique à l'ordinateur pour compléter l'authentification. Les vérificateurs envoient un défi aux dispositifs ou logiciels cryptographiques, et le dispositif ou le logiciel calcule une réponse basée sur une clé cryptographique stockée en toute sécurité.
+
+Les exigences relatives aux dispositifs et logiciels cryptographiques à facteur unique et aux dispositifs et logiciels cryptographiques à facteurs multiples sont les mêmes, car la vérification de l'authentificateur cryptographique prouve la possession du facteur d'authentification.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.9.1** | Vérifier que les clés cryptographiques utilisées dans la vérification sont stockées de manière sûre et protégées contre la divulgation, par exemple en utilisant un TPM ou un HSM, ou un service OS qui peut utiliser ce stockage sécurisé. | | ✓ | ✓ | 320 | 5.1.7.2 |
+| **2.9.2** | Vérifiez que le nonce de défi est d'une longueur d'au moins 64 bits, et statistiquement unique ou non pendant la durée de vie du dispositif cryptographique. | | ✓ | ✓ | 330 | 5.1.7.2 |
+| **2.9.3** | Vérifier que des algorithmes cryptographiques approuvés sont utilisés dans la génération, la préparation et la vérification. | | ✓ | ✓ | 327 | 5.1.7.2 |
+
+## V2.10 Exigences d'authentification des services
+
+Cette section n'est pas testable par tests d'intrusions, et n'a donc aucune exigence de L1. Toutefois, si elle est utilisée dans une architecture, un codage ou une révision de code sécurisé, veuillez supposer que le logiciel (tout comme le Java Key Store) est l'exigence minimale de la L1. Le stockage de secrets en texte clair n'est en aucun cas acceptable.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **2.10.1** | Vérifiez que les secrets d'intégration ne reposent pas sur des mots de passe immuables, tels que les clés API ou les comptes privilégiés partagés. | | OS assisté | HSM | 287 | 5.1.1.1 |
+| **2.10.2** | Vérifiez que si des mots de passe sont requis, l'authentification ne soit pas avec un compte par défaut. | | OS assisté | HSM | 255 | 5.1.1.1 |
+| **2.10.3** | Vérifiez que les mots de passe sont stockés avec une protection suffisante pour empêcher les attaques de récupération hors ligne, y compris l'accès au système local. | | Assistance du système d'exploitation | HSM | 522 | 5.1.1.1 |
+| **2.10.4** | Vérifier que les mots de passe, les intégrations avec les bases de données et les systèmes tiers, les seeds et les secrets internes, ainsi que les clés API sont gérés de manière sécurisée et ne sont pas inclus dans le code source ou stockés dans des dépôts de code source. Ce type de stockage DEVRAIT résister aux attaques hors ligne. L'utilisation d'un stockage de clés logiciel sécurisé (L1), d'un module de plate-forme de confiance (TPM) ou d'un module de sécurité matériel (L3) est recommandée pour le stockage des mots de passe. | | OS assisté | HSM | 798 | |
+
+## Exigences supplémentaires des agences américaines
+
+Les agences américaines ont des exigences obligatoires concernant le NIST 800-63. La norme de vérification de la sécurité des applications a toujours été d'environ 80% des contrôles qui s'appliquent à près de 100% des applications, et non les derniers 20% des contrôles avancés ou ceux qui ont une applicabilité limitée. En tant que telle, l'ASVS est un sous-ensemble strict de la norme NIST 800-63, en particulier pour les classifications IAL1/2 et AAL1/2, mais elle n'est pas suffisamment complète, notamment en ce qui concerne les classifications IAL3/AAL3.
+
+Nous demandons instamment aux agences gouvernementales américaines de revoir et de mettre en œuvre la norme NIST 800-63 dans son intégralité.
+
+## Glossaire des termes
+
+| Terme | Signification |
+| --- | --- |
+| CSP | Credential Service Provider également appelé fournisseur d'identité |
+| Authenticator | Code qui authentifie un mot de passe, un jeton, un MFA, une affirmation fédérée, etc. |
+| Vérificateur | "Entité qui vérifie l'identité du demandeur en vérifiant la possession et le contrôle par le demandeur d'un ou deux authentificateurs au moyen d'un protocole d'authentification. Pour ce faire, le vérificateur peut également avoir besoin de valider les références qui lient le ou les authentificateurs à l'identifiant de l'abonné et vérifier leur statut" |
+| OTP | Mot de passe unique |
+| SFA | Les authentificateurs à facteur unique, tels que quelque chose que vous connaissez (secrets mémorisés, mots de passe, phrases de passe, codes PIN), quelque chose que vous êtes (biométrie, empreintes digitales, scanners du visage), ou quelque chose que vous avez (jetons OTP, un dispositif cryptographique tel qu'une carte à puce), |
+| MFA | Authentification multi-facteurs, qui comprend deux ou plusieurs facteurs uniques |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [NIST 800-63 - Digital Identity Guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf)
+* [NIST 800-63 A - Enrollment and Identity Proofing](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf)
+* [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://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/fr/0x12-V3-Session-management.md b/4.0/fr/0x12-V3-Session-management.md
new file mode 100644
index 0000000000..d27be83254
--- /dev/null
+++ b/4.0/fr/0x12-V3-Session-management.md
@@ -0,0 +1,95 @@
+# V3 : Exigences de vérification de la gestion des sessions
+
+## Objectif de contrôle
+
+L'une des composantes essentielles de toute application web ou API à état est le mécanisme par lequel elle contrôle et maintient l'état pour un utilisateur ou un dispositif qui interagit avec elle. La gestion de session transforme un protocole sans état en protocole avec état, ce qui est essentiel pour différencier les différents utilisateurs ou appareils.
+
+Assurez-vous qu'une application vérifiée satisfait aux exigences de gestion de session de haut niveau suivantes :
+
+* Les sessions sont uniques à chaque individu et ne peuvent être devinées ou partagées.
+* Les sessions sont invalidées lorsqu'elles ne sont plus nécessaires et sont interrompues pendant les périodes d'inactivité.
+
+Comme indiqué précédemment, ces exigences ont été adaptées pour constituer un sous-ensemble conforme de contrôles NIST 800-63b sélectionnés, axés sur les menaces communes et les faiblesses d'authentification couramment exploitées. Les exigences de vérification précédentes ont été supprimées, réduites ou, dans la plupart des cas, adaptées pour être fortement alignées sur l'intention des exigences obligatoires [NIST 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.html).
+
+## Exigences de vérification de sécurité
+
+## V3.1 Exigences fondamentales en matière de gestion des sessions
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.1.1** | Vérifiez que l'application ne révèle jamais les jetons de session dans les paramètres d'URL ou les messages d'erreur. | ✓ | ✓ | ✓ | 598 | |
+
+## V3.2 Exigences contraignantes de la session
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.2.1** | Vérifiez que l'application génère un nouveau jeton de session sur l'authentification de l'utilisateur. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 384 | 7.1 |
+| **3.2.2** | Vérifiez que les jetons de session possèdent au moins 128 bits d'entropie. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 331 | 7.1 |
+| **3.2.3** | Vérifiez que l'application ne stocke que des jetons de session dans le navigateur en utilisant des méthodes sûres telles que les cookies correctement sécurisés (voir section 3.4) ou le stockage de session HTML 5. | ✓ | ✓ | ✓ | 539 | 7.1 |
+| **3.2.4** | Vérifiez que les jetons de session sont générés à l'aide d'algorithmes cryptographiques approuvés. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 331 | 7.1 |
+
+Le TLS ou un autre canal de transport sécurisé est obligatoire pour la gestion des sessions. Cette question est traitée dans le chapitre sur la sécurité des communications.
+
+## V3.3 Exigences en matière de déconnexion et de temporisation des sessions
+
+Les durées de session ont été alignées sur la norme NIST 800-63, qui autorise des durées de session beaucoup plus longues que celles traditionnellement autorisées par les normes de sécurité. Les organisations doivent examiner le tableau ci-dessous, et si un délai plus long est souhaitable en fonction du risque de l'application, la valeur NIST doit être la limite supérieure des délais d'inactivité de la session.
+
+Dans ce contexte, la valeur L1 est IAL1/AAL1, la valeur L2 est IAL2/AAL3, la valeur L3 est IAL3/AAL3. Pour IAL2/AAL2 et IAL3/AAL3, le délai d'inactivité le plus court est la limite inférieure des délais d'inactivité pour être déconnecté ou ré-authentifié pour reprendre la session.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.3.1** | Vérifiez que la déconnexion et l'expiration invalident le jeton de session. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 613 | 7.1 |
+| **3.3.2** | Si les authentificateurs permettent aux utilisateurs de rester connectés, vérifiez que la ré-authentification a lieu périodiquement, que ce soit en cas d'utilisation active ou après une période d'inactivité. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | 30 jours | 12 heures ou 30 minutes d'inactivité, 2FA facultatif | 12 heures ou 15 minutes d'inactivité, avec 2FA | 613 | 7.2 |
+| **3.3.3** | Vérifiez que l'application offre la possibilité de mettre fin à toutes les autres sessions actives après un changement de mot de passe réussi (y compris le changement par réinitialisation/récupération du mot de passe), et que cette option est effective dans toute l'application, la connexion fédérée (si elle existe) et toute partie qui se fie à elle. | | ✓ | ✓ | 613 | |
+| **3.3.4** | Vérifiez que les utilisateurs sont en mesure de consulter et (après avoir saisi à nouveau leurs identifiants de connexion) de se déconnecter d'une ou de toutes les sessions et de tous les dispositifs actuellement actifs. | | ✓ | ✓ | 613 | 7.1 |
+
+## V3.4 Gestion de session basée sur les cookies
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.4.1** | Vérifiez que les jetons de session basés sur des cookies ont l'attribut "Secure". ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 614 | 7.1.1 |
+| **3.4.2** | Vérifiez que les jetons de session basés sur des cookies ont l'attribut "HttpOnly". ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 1004 | 7.1.1 |
+| **3.4.3** | Vérifiez que les jetons de session basés sur des cookies utilisent l'attribut "SameSite" pour limiter l'exposition aux attaques de contrefaçon par requête intersite. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 |
+| **3.4.4** | Vérifiez que les jetons de session basés sur les cookies utilisent le préfixe "__Host" (voir références) pour assurer la confidentialité des cookies de session. | ✓ | ✓ | ✓ | 16 | 7.1.1 |
+| **3.4.5** | Vérifiez que si la demande est publiée sous un nom de domaine avec d'autres applications qui définissent ou utilisent des cookies de session susceptibles de les remplacer ou de les divulguer, définissez l'attribut de chemin dans les jetons de session basés sur les cookies en utilisant le chemin le plus précis possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 16 | 7.1.1 |
+
+## V3.5 Gestion de session à jetons
+
+La gestion des sessions basée sur des jetons comprend les clés JWT, OAuth, SAML et API. Parmi celles-ci, les clés API sont connues pour être faibles et ne doivent pas être utilisées dans un nouveau code.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.5.1** | Vérifiez que l'application ne valide pas les jetons OAuth et refresh -- par eux-même -- comme la présence de l'abonné et permet aux utilisateurs de mettre fin aux relations de confiance avec les applications liées. | | ✓ | ✓ | 290 | 7.1.2 |
+| **3.5.2** | Vérifiez que l'application utilise des jetons de session plutôt que des secrets et des clés d'API statiques, sauf dans le cas d'anciennes implémentations(legacy). | | ✓ | ✓ | 798 | |
+| **3.5.3** | Vérifiez que les jetons de session sans état utilisent les signatures numériques, le cryptage et d'autres contre-mesures pour se protéger contre les attaques par altération, mise sous enveloppe, rediffusion, chiffrement nul et substitution de clé. | | ✓ | ✓ | 345 | |
+
+## V3.6 Re-authentification d'une fédération ou d'une assertion
+
+Cette section concerne les personnes qui écrivent le code de la partie de relais (RP) ou du fournisseur de services d'accréditation (CSP). Si vous comptez sur un code mettant en œuvre ces caractéristiques, assurez-vous que ces questions sont traitées correctement.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.6.1** | Vérifier que les parties qui se fient à la procédure précisent le délai maximal d'authentification aux fournisseurs de services d'authentification (CSP) et que ces derniers ré-authentifient l'abonné s'ils n'ont pas utilisé de session pendant cette période. | | | ✓ | 613 | 7.2.1 |
+| **3.6.2** | Vérifier que les fournisseurs de services d'accréditation (CSP) informent les parties ayant fait confiance au dernier événement d'authentification, afin de permettre aux RP de déterminer s'ils doivent ré-authentifier l'utilisateur. | | | ✓ | 613 | 7.2.1 |
+
+## V3.7 Défenses contre l'exploitation de la gestion des sessions
+
+Il existe un petit nombre d'attaques de gestion de session, dont certaines sont liées à l'expérience utilisateur (UX) des sessions. Auparavant, sur la base des exigences de la norme ISO 27002, l'ASVS exigeait le blocage de plusieurs sessions simultanées. Le blocage de sessions simultanées n'est plus approprié, non seulement parce que les utilisateurs modernes disposent de nombreux appareils ou que l'application est une API sans session de navigateur, mais aussi parce que dans la plupart de ces implémentations, le dernier authentificateur gagne, qui est souvent l'attaquant. Cette section fournit des conseils de premier plan sur la dissuasion, le retard et la détection des attaques de gestion de session à l'aide de code.
+
+### Description de l'attaque semi-ouverte
+
+Au début de 2018, plusieurs institutions financières ont été compromises par ce que les attaquants ont appelé des "attaques à demi ouvertes". Ce terme est resté dans l'industrie. Les attaquants ont frappé plusieurs institutions avec des bases de code propriétaires différentes, et en effet il semble que les bases de code soient différentes au sein des mêmes institutions. L'attaque semi-ouverte exploite un défaut de conception communément rencontré dans de nombreux systèmes d'authentification, de gestion de session et de contrôle d'accès existants.
+
+Les attaquants lancent une attaque à demi-ouverte en essayant de verrouiller, de réinitialiser ou de récupérer un justificatif d'identité. Un modèle de gestion de session très répandu réutilise les objets/modèles de session de profil utilisateur entre le code non authentifié, semi-authentifié (réinitialisation du mot de passe, nom d'utilisateur oublié) et entièrement authentifié. Ce modèle remplit un objet de session ou un jeton valide contenant le profil de la victime, y compris les hachages de mots de passe et les rôles. Si les contrôles d'accès dans les contrôleurs ou les routeurs ne vérifient pas correctement que l'utilisateur est bien connecté, l'attaquant pourra agir en tant qu'utilisateur. Les attaques peuvent inclure la modification du mot de passe de l'utilisateur à une valeur connue, la mise à jour de l'adresse électronique pour effectuer une réinitialisation de mot de passe valide, la désactivation de l'authentification multifactorielle ou l'inscription d'un nouveau dispositif d'AMF, la révélation ou la modification des clés API, etc.
+
+| # | Description | L1 | L2 | L3 | CWE | [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
+| :---: | :--- | :---: | :---:| :---: | :---: | :---: |
+| **3.7.1** | Vérifier que l'application garantit une session de connexion complète et valide ou exige une nouvelle authentification ou une vérification secondaire avant d'autoriser toute transaction sensible ou modification de compte. | ✓ | ✓ | ✓ | 306 | |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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/fr/0x12-V4-Access-Control.md b/4.0/fr/0x12-V4-Access-Control.md
new file mode 100644
index 0000000000..b74ee815dd
--- /dev/null
+++ b/4.0/fr/0x12-V4-Access-Control.md
@@ -0,0 +1,45 @@
+# V4 : Exigences de vérification du contrôle d'accès
+
+## Objectif de contrôle
+
+L'autorisation est le concept qui consiste à ne permettre l'accès aux ressources qu'à ceux qui sont autorisés à les utiliser. Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* Les personnes qui accèdent aux ressources possèdent une autorisation valide pour le faire.
+* Les utilisateurs sont associés à un ensemble bien défini de rôles et de privilèges.
+* Les métadonnées relatives aux rôles et aux autorisations sont protégées contre toute rediffusion ou altération.
+
+## Exigences de vérification de la sécurité
+
+## V4.1 Conception générale du contrôle d'accès
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **4.1.1** | Vérifiez que l'application applique les règles de contrôle d'accès sur une couche de service de confiance, en particulier si le contrôle d'accès côté client est présent et pourrait être contourné. | ✓ | ✓ | ✓ | 602 |
+| **4.1.2** | Vérifier que tous les attributs des utilisateurs et des données et les informations sur les politiques utilisées par les contrôles d'accès ne peuvent être manipulés par les utilisateurs finaux, sauf autorisation spécifique. | ✓ | ✓ | ✓ | 639 |
+| **4.1.3** | Vérifier que le principe du moindre privilège existe - les utilisateurs ne doivent pouvoir accéder qu'aux fonctions, fichiers de données, URL, contrôleurs, services et autres ressources pour lesquels ils possèdent une autorisation spécifique. Cela implique une protection contre l'usurpation et l'élévation des privilèges. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 285 |
+| **4.1.4** | Vérifiez que le principe de refus par défaut existe, selon lequel les nouveaux utilisateurs/rôles commencent avec des autorisations minimales ou nulles et les utilisateurs/rôles ne reçoivent pas l'accès aux nouvelles fonctionnalités tant que l'accès n'est pas explicitement attribué. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 276 |
+| **4.1.5** | Vérifier que les contrôles d'accès échouent de manière sûre, y compris lorsqu'une exception se produit. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 285 |
+
+## V4.2 Contrôle d'accès au niveau des opérations
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **4.2.1** | Vérifier que les données sensibles et les API sont protégées contre les attaques par référence directe à un objet (IDOR) non sécurisées visant la création, la lecture, la mise à jour et la suppression d'enregistrements, telles que la création ou la mise à jour de l'enregistrement de quelqu'un d'autre, la consultation de tous les enregistrements ou la suppression de tous les enregistrements. | ✓ | ✓ | ✓ | 639 |
+| **4.2.2** | Vérifiez que l'application ou le cadriciel applique un mécanisme anti-CSRF fort pour protéger les fonctionnalités authentifiées, et qu'une anti-automation ou un anti-CSRF efficace protège les fonctionnalités non authentifiées. | ✓ | ✓ | ✓ | 352 |
+
+## V4.3 Autres considérations relatives au contrôle d'accès
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **4.3.1** | Vérifier que les interfaces administratives utilisent une authentification multifactorielle appropriée pour empêcher toute utilisation non autorisée. | ✓ | ✓ | ✓ | 419 |
+| **4.3.2** | Vérifiez que la navigation dans les répertoires est désactivée, sauf si vous le souhaitez délibérément. En outre, les applications ne doivent pas permettre la découverte ou la divulgation de métadonnées de fichiers ou de répertoires, tels que les dossiers Thumbs.db, .DS_Store, .git ou .svn. | ✓ | ✓ | ✓ | 548 |
+| **4.3.3** | Vérifier que la demande dispose d'une autorisation supplémentaire (telle qu'une authentification renforcée ou adaptative) pour les systèmes à faible valeur, et/ou d'une séparation des tâches pour les demandes à valeur élevée afin de faire appliquer les contrôles anti-fraude en fonction du risque de fraude de la demande et de la fraude passée. | | ✓ | ✓ | 732 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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/fr/0x13-V5-Validation-Sanitization-Encoding.md b/4.0/fr/0x13-V5-Validation-Sanitization-Encoding.md
new file mode 100644
index 0000000000..06090f0804
--- /dev/null
+++ b/4.0/fr/0x13-V5-Validation-Sanitization-Encoding.md
@@ -0,0 +1,109 @@
+# V5 : Exigences de validation, d'assainissement et de vérification de l'encodage
+
+## Objectif de contrôle
+
+La faiblesse la plus courante en matière de sécurité des applications web est l'incapacité à valider correctement les données provenant du client ou de l'environnement avant de les utiliser directement sans aucun encodage de sortie. Cette faiblesse est à l'origine de presque toutes les vulnérabilités importantes des applications web, telles que le Cross-Site Scripting (XSS), l'injection SQL, l'injection d'interpréteur, les attaques locales/Unicode, les attaques de système de fichiers et les débordements de mémoire tampon.
+
+Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* La validation des entrées et l'architecture de codage des sorties ont un pipeline convenu pour prévenir les attaques par injection.
+* Les données d'entrée sont fortement typées, validées, vérifiées en plage ou en longueur ou, au pire, aseptisées ou filtrées.
+* Les données de sortie sont codées ou échappées selon le contexte des données, aussi près que possible de l'interpréteur.
+
+Avec l'architecture moderne des applications web, l'encodage des données de sortie est plus important que jamais. Il est difficile de fournir une validation robuste des entrées dans certains scénarios, de sorte que l'utilisation d'API plus sûres telles que les requêtes paramétrées, les cadres de modélisation à évasion automatique ou un encodage de sortie soigneusement choisi est essentiel pour la sécurité de l'application.
+
+## V5.1 Exigences de validation des entrées
+
+Des contrôles de validation des entrées correctement mis en œuvre, utilisant une liste d'autorisation positive et un fort typage des données, peuvent éliminer plus de 90 % de toutes les attaques par injection. Les contrôles de longueur et de portée peuvent encore réduire ce phénomène. Il est nécessaire de mettre en place une validation d'entrée sécurisée pendant l'architecture de l'application, les sprints de conception, le codage et les tests unitaires et d'intégration. Bien que nombre de ces éléments ne puissent être trouvés dans les tests de pénétration, les résultats de leur non-implantation se trouvent généralement dans la version 5.3 - Exigences en matière de codage de sortie et de prévention des injections. Il est recommandé aux développeurs et aux réviseurs de codes sécurisés de traiter cette section comme si la L1 était requise pour tous les éléments afin de prévenir les injections.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **5.1.1** | Vérifiez que l'application dispose de défenses contre les attaques de pollution des paramètres HTTP, en particulier si le cadre de l'application ne fait aucune distinction quant à la source des paramètres de la requête (GET, POST, cookies, en-têtes ou variables d'environnement). | ✓ | ✓ | ✓ | 235 |
+| **5.1.2** | Vérifiez que les cadriciels protègent contre les attaques par assignation massive de paramètres, ou que l'application dispose de contre-mesures pour protéger contre l'assignation dangereuse de paramètres, comme le marquage des champs privés ou similaires. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 915 |
+| **5.1.3** | Vérifiez que toutes les entrées (champs de formulaire HTML, demandes REST, paramètres URL, en-têtes HTTP, cookies, fichiers batch, flux RSS, etc) sont validées par une validation positive (liste d'autorisation). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 |
+| **5.1.4** | Vérifier que les données structurées sont fortement typées et validées par rapport à un schéma défini comprenant les caractères, la longueur et le modèle autorisés (par exemple, numéros de carte de crédit ou de téléphone, ou valider que deux champs connexes sont raisonnables, comme vérifier la correspondance entre la banlieue et le code postal). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 |
+| **5.1.5** | Vérifiez que les redirections et les transferts d'URL n'autorisent que les destinations prévu, ou affichez un avertissement lors d'une redirection vers un contenu potentiellement non fiable. | ✓ | ✓ | ✓ | 601 |
+
+## V5.2 Exigences en matière d'assainissement et de « bac à sable »
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **5.2.1** | Vérifiez que toutes les entrées HTML non fiables provenant d'éditeurs WYSIWYG ou similaires sont correctement assainit avec une bibliothèque ou une fonction de framework de nettoyage HTML. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 |
+| **5.2.2** | Vérifiez que les données non structurées sont assainit afin d'appliquer les mesures de sécurité telles que les caractères et la longueur autorisés. | ✓ | ✓ | ✓ | 138 |
+| **5.2.3** | Vérifiez que l'application assainit les entrées de l'utilisateur avant de passer aux systèmes de messagerie pour protéger contre l'injection SMTP ou IMAP. | ✓ | ✓ | ✓ | 147 |
+| **5.2.4** | Vérifiez que l'application évite l'utilisation de eval() ou d'autres fonctions d'exécution de code dynamique. Lorsqu'il n'y a pas d'alternative, toute entrée utilisateur incluse doit être assainit ou mise en sandbox avant d'être exécutée. | ✓ | ✓ | ✓ | 95 |
+| **5.2.5** | Vérifiez que l'application protège contre les attaques par injection de modèles en veillant à ce que toute entrée de l'utilisateur incluse soit aseptisée ou mise en bac à sable. | ✓ | ✓ | ✓ | 94 |
+| **5.2.6** | Vérifier que l'application protège contre les attaques SSRF, en validant ou en assainissant les données non fiables ou les métadonnées de fichiers HTTP, comme les noms de fichiers et les champs de saisie d'URL, utiliser la liste d'autorisation des protocoles, domaines, chemins et ports. | ✓ | ✓ | ✓ | 918 |
+| **5.2.7** | Vérifiez que l'application assainit, désactive ou met en place une isolation (sandbox) pour le contenu scriptable fourni par l'utilisateur (Scalable Vector Graphics - SVG), en particulier en ce qui concerne les XSS résultant de scripts natif au code présent et foreignObject. | ✓ | ✓ | ✓ | 159 |
+| **5.2.8** | Vérifiez que l'application assainit, désactive ou met en sandbox le contenu des scripts ou des modèles d'expression fournis par l'utilisateur, tels que les feuilles de style Markdown, CSS ou XSL, le BBCode ou autres. | ✓ | ✓ | ✓ | 94 |
+
+## V5.3 Exigences en matière d'encodage de sortie et de prévention des injections
+
+L'encodage de la sortie à proximité de l'interprète utilisé est essentiel pour la sécurité de toute application. Généralement, l'encodage de sortie n'est pas persistant, mais utilisé pour rendre la sortie sûre dans le contexte de sortie approprié pour une utilisation immédiate. Le défaut d'encodage de la sortie entraînera une application non sécurisée, injectable et dangereuse.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **5.3.1** | Vérifiez que l'encodage de sortie est pertinent pour l'interprète et le contexte requis. Par exemple, utilisez des encodeurs spécifiques pour les valeurs HTML, les attributs HTML, JavaScript, les paramètres URL, les en-têtes HTTP, SMTP et autres selon le contexte, en particulier à partir d'entrées non fiables (par exemple les noms avec Unicode ou apostrophes, comme ねこ ou O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 |
+| **5.3.2** | Vérifiez que l'encodage de sortie préserve le jeu de caractères et la langue choisis par l'utilisateur, de sorte que tout point de caractère Unicode soit valide et traité en toute sécurité. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 176 |
+| **5.3.3** | Vérifiez que l'encodage des sorties en fonction du contexte, de préférence automatisé - ou au pire, manuel - protège contre le XSS réfléchi, stocké et basé sur le DOM. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 79 |
+| **5.3.4** | Vérifier que la sélection de données ou les requêtes de base de données (par exemple SQL, HQL, ORM, NoSQL) utilisent des requêtes paramétrées, des ORM, des cadres d'entités, ou sont autrement protégées contre les attaques par injection de base de données. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 89 |
+| **5.3.5** | Vérifiez que, lorsque des mécanismes paramétrés ou plus sûrs ne sont pas présents, un encodage de sortie spécifique au contexte est utilisé pour se protéger contre les attaques par injection, comme l'utilisation de l'échappement SQL pour se protéger contre l'injection SQL. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 89 |
+| **5.3.6** | Vérifiez que l'application protège contre les attaques par injection de JavaScript ou de JSON, y compris pour les attaques d'évaluation, les includes JavaScript distants, les contournements de la politique de sécurité du contenu (CSP), les DOM XSS et l'évaluation des expressions JavaScript. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 830 |
+| **5.3.7** | Vérifiez que l'application protège contre les vulnérabilités de LDAP Injection, ou que des contrôles de sécurité spécifiques pour empêcher des injections LDAP ont été mis en place. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 90 |
+| **5.3.8** | Vérifiez que l'application protège contre l'injection de commandes du système d'exploitation et que les appels du système d'exploitation utilisent des requêtes paramétrées du système d'exploitation ou utilisent l'encodage contextuel de la sortie de la ligne de commande. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 78 |
+| **5.3.9** | Vérifiez que l'application protège contre les attaques par inclusion de fichier local (LFI) ou par inclusion de fichier distant (RFI). | ✓ | ✓ | ✓ | 829 |
+| **5.3.10** | Vérifiez que l'application protège contre les attaques par injection XPath ou par injection XML. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 643 |
+
+Note : L'utilisation de requêtes paramétrées ou l'échappement du SQL n'est pas toujours suffisant ; les noms de tables et de colonnes, ORDER BY, etc. ne peuvent pas être échappés. L'inclusion de données échappées fournies par l'utilisateur dans ces champs entraîne l'échec des requêtes ou de l'injection SQL.
+
+Note : Le format SVG autorise explicitement le script ECMA dans presque tous les contextes, de sorte qu'il peut ne pas être possible de bloquer complètement tous les vecteurs XSS SVG. Si un téléchargement SVG est nécessaire, nous recommandons fortement soit de servir ces fichiers téléchargés en tant que texte/plain, soit d'utiliser un domaine de contenu distinct fourni par l'utilisateur pour empêcher que le XSS ne prenne le relais de l'application.
+
+## V5.4 Exigences en matière de mémoire, de chaînes de caractères et de code non géré
+
+Les exigences suivantes ne s'appliquent que lorsque l'application utilise un langage système ou un code non géré.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **5.4.1** | Vérifiez que l'application utilise une chaîne de caractères à mémoire sécurisée, une copie mémoire sécurisée et l'arithmétique des pointeurs pour détecter ou empêcher les débordements de pile, de mémoire tampon ou de tas. | | ✓ | ✓ | 120 |
+| **5.4.2** | Vérifiez que les chaînes de format ne prennent pas d'entrée potentiellement hostile, et sont constantes. | | ✓ | ✓ | 134 |
+| **5.4.3** | Vérifiez que les techniques de validation des signes, des plages et des entrées sont utilisées pour éviter les débordements d'entiers. | | ✓ | ✓ | 190 |
+
+## V5.5 Exigences de prévention de la désérialisation
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **5.5.1** | Vérifiez que les objets sérialisés utilisent des contrôles d'intégrité ou sont cryptés pour empêcher la création d'objets hostiles ou la falsification de données. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 502 |
+| **5.5.2** | Vérifiez que l'application restreint correctement les analyseurs XML pour n'utiliser que la configuration la plus restrictive possible et pour s'assurer que les fonctions dangereuses telles que la résolution d'entités externes sont désactivées pour empêcher les XXE. | ✓ | ✓ | ✓ | 611 |
+| **5.5.3** | Vérifiez que la désérialisation des données non fiables est évitée ou protégée à la fois dans le code personnalisé et les bibliothèques tierces (comme les analyseurs JSON, XML et YAML). | ✓ | ✓ | ✓ | 502 |
+| **5.5.4** | Vérifiez que lors de l'analyse de JSON dans les navigateurs ou les backends basés sur JavaScript, JSON.parse est utilisé pour analyser le document JSON. N'utilisez pas eval() pour analyser JSON. | ✓ | ✓ | ✓ | 95 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html)
+
+Pour plus d'informations sur l'évasion automatique, veuillez consulter
+
+* [Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems](https://googleonlinesecurity.blogspot.com/2009/03/reducing-xss-by-way-of-automatic.html)
+* [AngularJS Strict Contextual Escaping](https://docs.angularjs.org/api/ng/service/$sce)
+* [AngularJS ngBind](https://docs.angularjs.org/api/ng/directive/ngBind)
+* [Angular Sanitization](https://angular.io/guide/security#sanitization-and-security-contexts)
+* [Angular Template Security](https://angular.io/guide/template-syntax#content-security)
+* [ReactJS Escaping](https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks)
+* [Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html)
+
+Pour plus d'informations sur la désérialisation, veuillez consulter
+
+* [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/fr/0x14-V6-Cryptography.md b/4.0/fr/0x14-V6-Cryptography.md
new file mode 100644
index 0000000000..837ece699d
--- /dev/null
+++ b/4.0/fr/0x14-V6-Cryptography.md
@@ -0,0 +1,62 @@
+# V6 : Exigences de vérification de la cryptographie stockée
+
+## Objectif de contrôle
+
+Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* Tous les modules cryptographiques échouent de manière sécurisée et que les erreurs sont traitées correctement.
+* Un générateur de nombres aléatoires approprié est utilisé.
+* L'accès aux clés est géré de manière sécurisée.
+
+## V6.1 Classification des données
+
+L'actif le plus important est constitué par les données traitées, stockées ou transmises par une application. Il faut toujours procéder à une évaluation de l'impact sur la vie privée afin de classer correctement les besoins en matière de protection des données de toute donnée stockée.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **6.1.1** | Vérifier que les données privées réglementées sont stockées sous forme cryptée pendant le repos, comme les informations d'identification personnelle (IIP), les informations personnelles sensibles ou les données considérées comme susceptibles d'être soumises à la GDPR de l'UE. | | ✓ | ✓ | 311 |
+| **6.1.2** | Vérifier que les données de santé réglementées sont stockées de manière cryptée pendant le repos, comme les dossiers médicaux, les détails des dispositifs médicaux ou les dossiers de recherche désanonymisés. | | ✓ | ✓ | 311 |
+| **6.1.3** | Vérifiez que les données financières réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, telles que les comptes financiers, les défauts ou les antécédents de crédit, les dossiers fiscaux, l'historique des salaires, les bénéficiaires ou les dossiers de marché ou de recherche désanonymisés. | | ✓ | ✓ | 311 |
+
+## V6.2 Algorithmes
+
+Les récents progrès de la cryptographie signifient que des algorithmes et des longueurs de clé auparavant sûrs ne sont plus sûrs ou suffisants pour protéger les données. Il devrait donc être possible de modifier les algorithmes.
+
+Bien que cette section ne soit pas facilement testée lors des tests d'intrusions, les développeurs devraient considérer toute cette section comme obligatoire même si la L1 est absente de la plupart des éléments.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **6.2.1** | Vérifiez que tous les modules cryptographiques échouent en toute sécurité, et que les erreurs sont traitées de manière à ne pas permettre les attaques de type "Padding Oracle". | ✓ | ✓ | ✓ | 310 |
+| **6.2.2** | Vérifiez que des algorithmes, des bibliothèques cryptographiques et des modes éprouvés par l'industrie ou approuvés par le gouvernement sont utilisés, au lieu de la cryptographie codée sur mesure. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 327 |
+| **6.2.3** | Vérifiez que le vecteur d'initialisation du chiffrement, la configuration du chiffrement et les modes de blocage sont configurés de manière sécurisée en utilisant les derniers conseils. | | ✓ | ✓ | 326 |
+| **6.2.4** | Vérifiez que les algorithmes de chiffrement ou de hachage, les longueurs de clé, le nombre de rondes, les chiffrements ou les modes, peuvent être reconfigurés, mis à niveau ou échangés à tout moment, pour se protéger contre les failles cryptographiques. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 326 |
+| **6.2.5** | Vérifiez que les modes de blocs non sécurisés connus (c'est-à-dire ECB, etc.), les modes de remplissage (c'est-à-dire PKCS#1 v1.5, etc.), les chiffrements avec des blocs de petites tailles (c'est-à-dire Triple-DES, Blowfish, etc.) et les algorithmes de hachage faibles (c'est-à-dire MD5, SHA1, etc.) ne sont pas utilisés, sauf si cela est nécessaire pour la rétrocompatibilité. | | ✓ | ✓ | 326 |
+| **6.2.6** | Vérifiez que les nonces, vecteurs d'initialisation et autres numéros à usage unique ne doivent pas être utilisés plus d'une fois avec une clé de cryptage donnée. La méthode de génération doit être appropriée à l'algorithme utilisé. | | ✓ | ✓ | 326 |
+| **6.2.7** | Vérifier que les données cryptées sont authentifiées par des signatures, des modes de chiffrement authentifiés ou le [HMAC](https://en.wikipedia.org/wiki/HMAC) pour s'assurer que le texte chiffré n'est pas altéré par une partie non autorisée. | | | ✓ | 326 |
+| **6.2.8** | Vérifiez que toutes les opérations cryptographiques sont à temps constant, sans opérations de "court-circuit" dans les comparaisons, les calculs ou les retours, afin d'éviter les fuites d'informations. | | | ✓ | 385 |
+
+## V6.3 Valeurs aléatoires
+
+La véritable génération de nombres pseudo-aléatoires (PRNG) est incroyablement difficile à réaliser. En général, les bonnes sources d'entropie au sein d'un système seront rapidement épuisées si elles sont trop utilisées, mais des sources moins aléatoires peuvent conduire à des clés et des secrets prévisibles.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **6.3.1** | Vérifiez que tous les nombres aléatoires, noms de fichiers aléatoires, GUIDs aléatoires et chaînes aléatoires sont générés en utilisant le générateur de nombres aléatoires sécurisé cryptographiquement approuvé par le module cryptographique lorsque ces valeurs aléatoires sont destinées à ne pas être devinées par un attaquant. | | ✓ | ✓ | 338 |
+| **6.3.2** | Vérifiez que les GUID aléatoires sont créés en utilisant l'algorithme GUID v4, et un générateur de nombres pseudo-aléatoires sécurisé cryptographiquement (CSPRNG). Les GUID créés à l'aide d'autres générateurs de nombres pseudo-aléatoires peuvent être prévisibles. | | ✓ | ✓ | 338 |
+| **6.3.3** | Vérifiez que les nombres aléatoires sont créés avec une entropie correcte même lorsque l'application est soumise à une forte charge, ou que l'application se dégrade gracieusement dans de telles circonstances. | | | ✓ | 338 |
+
+## V6.4 Gestion du secret
+
+Bien que cette section ne soit pas facilement testée, les développeurs devraient considérer toute cette section comme obligatoire même si la L1 est absente de la plupart des éléments.
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **6.4.1** | Vérifiez qu'une solution de gestion des secrets, telle qu'un coffre fort de clés, est utilisé pour créer, stocker, contrôler l'accès aux secrets et les détruire en toute sécurité. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 798 |
+| **6.4.2** | Vérifiez que le matériel clé ne soit pas exposé à l'application mais utilise plutôt un module de sécurité isolé comme un coffre-fort pour les opérations cryptographiques. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 320 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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/fr/0x15-V7-Error-Logging.md b/4.0/fr/0x15-V7-Error-Logging.md
new file mode 100644
index 0000000000..1a7a98b983
--- /dev/null
+++ b/4.0/fr/0x15-V7-Error-Logging.md
@@ -0,0 +1,77 @@
+# V7 : Traitement des erreurs et exigences de vérification de l'enregistrement
+
+## Objectif de contrôle
+
+L'objectif premier du traitement et de la journalisation des erreurs est de fournir des informations utiles à l'utilisateur, aux administrateurs et aux équipes de réponse aux incidents. L'objectif n'est pas de créer des quantités massives de journaux, mais des journaux de haute qualité, avec plus de signal que de bruit rejeté.
+
+Les journaux de haute qualité contiennent souvent des données sensibles et doivent être protégés conformément aux lois ou directives locales en matière de confidentialité des données. Cela devrait inclure :
+
+* Ne pas collecter ou enregistrer des informations sensibles, sauf si cela est spécifiquement requis.
+* Veiller à ce que toutes les informations enregistrées soient traitées de manière sûre et protégées conformément à leur classification.
+* Veiller à ce que les journaux ne soient pas conservés éternellement, mais qu'ils aient une durée de vie absolue aussi courte que possible.
+
+Si les journaux contiennent des données privées ou sensibles, dont la définition varie d'un pays à l'autre, les journaux deviennent parmis les informations les plus sensibles détenues par l'application et donc très attrayantes pour les attaquants en soi.
+
+Il est également important de s'assurer que l'application échoue en toute sécurité et que les erreurs ne divulguent pas d'informations inutiles.
+
+## V7.1 Exigences relatives au contenu des journaux
+
+L'enregistrement d'informations sensibles est dangereux : les journaux deviennent eux-mêmes classifiés, ce qui signifie qu'ils doivent être cryptés, faire l'objet de politiques de conservation et être divulgués lors d'audits de sécurité. Assurez-vous que seules les informations nécessaires sont conservées dans les journaux, et certainement pas les paiements, les justificatifs d'identité (y compris les jetons de session), les informations sensibles ou identifiables personnellement.
+
+V7.1 couvre le Top 10 de l'OWASP 2017:A10. Comme 2017:A10 et cette section ne sont pas testables tests d'intrusions, il est important pour :
+
+* Les développeurs de s'assurer de la conformité totale avec cette section, comme si tous les éléments étaient marqués comme L1
+* Tests de pénétration de valider la conformité totale de tous les éléments de la V7.1 par le biais d'un entretien, de captures d'écran ou d'une affirmation
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **7.1.1** | Vérifiez que la demande n'enregistre pas les références ou les détails de paiement. Les jetons de session ne doivent être stockés dans les journaux que sous une forme hachée et irréversible. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 532 |
+| **7.1.2** | Vérifiez que l'application n'enregistre pas d'autres données sensibles telles que définies par les lois locales sur la protection de la vie privée ou la politique de sécurité pertinente. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 532 |
+| **7.1.3** | Vérifiez que l'application enregistre les événements pertinents pour la sécurité, y compris les événements d'authentification réussis et échoués, les échecs de contrôle d'accès, les échecs de désérialisation et les échecs de validation des entrées. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 |
+| **7.1.4** | Vérifiez que chaque événement consigné dans le journal contient les informations nécessaires pour permettre une enquête détaillée sur la chronologie de l'événement. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 |
+
+## V7.2 Exigences de traitement des journaux
+
+Il est essentiel d'enregistrer en temps utile les événements de vérification, le triage et l'escalade. Assurez-vous que les journaux de l'application sont clairs et peuvent être facilement surveillés et analysés, soit localement, soit envoyés à un système de surveillance à distance.
+
+V7.2 couvre le Top 10 de l'OWASP 2017:A10. Comme 2017:A10 et cette section ne sont pas testables, il est important pour :
+
+* Les développeurs de s'assurer de la conformité totale avec cette section, comme si tous les éléments étaient marqués comme L1
+* Tests de pénétration de valider la conformité totale de tous les éléments de la V7.2 par le biais d'un entretien, de captures d'écran ou d'une affirmation
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **7.2.1** | Vérifiez que toutes les décisions d'authentification sont consignées, sans stocker d'identifiants de session ou de mots de passe sensibles. Cela devrait inclure les demandes avec les métadonnées pertinentes nécessaires aux enquêtes de sécurité. | | ✓ | ✓ | 778 |
+| **7.2.2** | Vérifiez que toutes les décisions de contrôle d'accès peuvent être enregistrées et que toutes les décisions qui ont échoué sont enregistrées. Cela devrait inclure les demandes avec les métadonnées pertinentes nécessaires aux enquêtes de sécurité. | | ✓ | ✓ | 285 |
+
+## V7.3 Exigences en matière de protection des journaux
+
+Les journaux qui peuvent être trivialement modifiés ou supprimés sont inutiles pour les enquêtes et les poursuites. La divulgation des journaux peut révéler des détails internes sur l'application ou les données qu'elle contient. Il convient de prendre des précautions pour protéger les journaux contre toute divulgation, modification ou suppression non autorisée.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **7.3.1** | Vérifiez que l'application encode correctement les données fournies par l'utilisateur pour éviter l'injection de logs. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 117 |
+| **7.3.2** | Vérifiez que tous les événements sont protégés contre l'injection lorsqu'ils sont visualisés dans le logiciel de visualisation des journaux. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 117 |
+| **7.3.3** | Vérifiez que les journaux de sécurité sont protégés contre tout accès et toute modification non autorisés. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 200 |
+| **7.3.4** | Vérifiez que les sources de temps sont synchronisées avec l'heure et le fuseau horaire corrects. Envisager sérieusement de n'enregistrer les données qu'en UTC si les systèmes sont globaux pour faciliter l'analyse criminalistique post-incident. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | |
+
+Remarque : L'encodage des journaux (7.3.1) est difficile à tester et à examiner à l'aide d'outils dynamiques automatisés et de tests de pénétration, mais les architectes, les développeurs et les réviseurs de code source devraient le considérer comme une exigence de niveau 1.
+
+## V7.4 Traitement des erreurs
+
+L'objectif du traitement des erreurs est de permettre à l'application de fournir des événements pertinents pour la sécurité en vue de la surveillance, du triage et de l'escalade. L'objectif n'est pas de créer des journaux. Lorsque vous enregistrez des événements liés à la sécurité, assurez-vous que le journal a un but et qu'il peut être distingué par le SIEM ou un logiciel d'analyse.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **7.4.1** | Vérifiez qu'un message générique s'affiche lorsqu'une erreur inattendue ou sensible à la sécurité se produit, éventuellement avec un identifiant unique que le personnel de soutien peut utiliser pour enquêter. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 210 |
+| **7.4.2** | Vérifiez que le traitement des exceptions est utilisé dans toute le code source pour tenir compte des conditions d'erreur prévues et imprévues. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 544 |
+| **7.4.3** | Vérifiez qu'un gestionnaire d'erreurs de "dernier recours" est défini, qui prendra en compte toutes les exceptions non traitées. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 431 |
+
+Note : Certains langages, tels que Swift et Go - et selon la pratique courante de conception - de nombreux langages fonctionnels, ne prennent pas en charge les exceptions ou les gestionnaires d'événements de dernier recours. Dans ce cas, les architectes et les développeurs doivent utiliser un modèle, un langage ou un cadre convivial pour s'assurer que les applications peuvent gérer en toute sécurité des événements exceptionnels, inattendus ou liés à la sécurité.
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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/fr/0x16-V8-Data-Protection.md b/4.0/fr/0x16-V8-Data-Protection.md
new file mode 100644
index 0000000000..adc770a39b
--- /dev/null
+++ b/4.0/fr/0x16-V8-Data-Protection.md
@@ -0,0 +1,64 @@
+# V8 : Exigences de vérification de la protection des données
+
+## Objectif de contrôle
+
+Il y a trois éléments clés pour une bonne protection des données : Confidentialité, intégrité et disponibilité (CIA). Cette norme suppose que la protection des données est appliquée sur un système fiable, tel qu'un serveur, qui a été renforcé et dispose de protections suffisantes.
+
+Les applications doivent supposer que tous les dispositifs des utilisateurs sont compromis d'une manière ou d'une autre. Lorsqu'une application transmet ou stocke des informations sensibles sur des dispositifs non sécurisés, tels que des ordinateurs, des téléphones et des tablettes partagés, l'application est chargée de s'assurer que les données stockées sur ces dispositifs sont cryptées et ne peuvent pas être facilement obtenues, modifiées ou divulguées de manière illicite.
+
+Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes en matière de protection des données :
+
+* Confidentialité : Les données doivent être protégées contre toute observation ou divulgation non autorisée, tant pendant leur transit que lors de leur stockage.
+* Intégrité : Les données doivent être protégées contre toute création, modification ou suppression malveillante par des attaquants non autorisés.
+* Disponibilité : Les données doivent être accessibles aux utilisateurs autorisés, selon les besoins.
+
+## V8.1 Protection générale des données
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **8.1.1** | Vérifiez que l'application protège les données sensibles contre la mise en cache dans des composants du serveur tels que les équilibreurs de charge et les caches d'applications. | | ✓ | ✓ | 524 |
+| **8.1.2** | Vérifier que toutes les copies en cache ou temporaires de données sensibles stockées sur le serveur sont protégées contre tout accès non autorisé ou purgées/invalidées après que l'utilisateur autorisé a accédé aux données sensibles. | | ✓ | ✓ | 524 |
+| **8.1.3** | Vérifier que l'application minimise le nombre de paramètres dans une requête, tels que les champs cachés, les variables Ajax, les cookies et les valeurs d'en-tête. | | ✓ | ✓ | 233 |
+| **8.1.4** | Vérifier que l'application peut détecter et alerter sur un nombre anormal de demandes, par exemple par IP, par utilisateur, par total par heure ou par jour, ou tout ce qui a un sens pour l'application. | | ✓ | ✓ | 770 |
+| **8.1.5** | Vérifiez que des sauvegardes régulières des données importantes sont effectuées et que des tests de restauration des données sont effectués. | | | ✓ | 19 |
+| **8.1.6** | Vérifiez que les sauvegardes sont stockées en toute sécurité pour éviter que les données ne soient volées ou corrompues. | | | ✓ | 19 |
+
+## V8.2 Protection des données côté client
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **8.2.1** | Vérifiez que l'application définit suffisamment d'en-têtes anticaching pour que les données sensibles ne soient pas mises en cache dans les navigateurs modernes. | ✓ | ✓ | ✓ | 525 |
+| **8.2.2** | Vérifiez que les données stockées dans le stockage côté client (telles que le stockage local HTML5, le stockage de session, IndexedDB, les cookies réguliers ou les cookies Flash) ne contiennent pas de données sensibles ou d'IIP. | ✓ | ✓ | ✓ | 922 |
+| **8.2.3** | Vérifiez que les données authentifiées sont effacées du stockage du client, tel que le DOM du navigateur, après la fin du client ou de la session. | ✓ | ✓ | ✓ | 922 |
+
+## V8.3 Données privées sensibles
+
+Cette section permet de protéger les données sensibles contre la création, la lecture, la mise à jour ou la suppression sans autorisation, notamment en cas de grandes quantités.
+
+Le respect de cette section implique le respect du contrôle d'accès V4, et en particulier V4.2. Par exemple, la protection contre les mises à jour ou la divulgation non autorisées d'informations personnelles sensibles nécessite le respect de la V4.2.1. Veuillez vous conformer à cette section et à V4 pour une couverture complète.
+
+Note : Les réglementations et les lois relatives à la protection de la vie privée, telles que "Australian Privacy Principles" APP-11 ou GDPR, ont une incidence directe sur la manière dont les applications doivent aborder la mise en œuvre du stockage, de l'utilisation et de la transmission des informations personnelles sensibles. Cela va de sanctions sévères à de simples conseils. Veuillez consulter vos lois et règlements locaux et, le cas échéant, un spécialiste ou un avocat qualifié en matière de protection de la vie privée.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **8.3.1** | Vérifiez que les données sensibles sont envoyées au serveur dans le corps ou les en-têtes du message HTTP, et que les paramètres de la chaîne de requête de tout verbe HTTP ne contiennent pas de données sensibles. | ✓ | ✓ | ✓ | 319 |
+| **8.3.2** | Vérifier que les utilisateurs disposent d'une méthode pour supprimer ou exporter leurs données sur demande. | ✓ | ✓ | ✓ | 212 |
+| **8.3.3** | Vérifier que les utilisateurs disposent d'un langage clair concernant la collecte et l'utilisation des informations personnelles fournies et que les utilisateurs ont donné leur consentement pour l'utilisation de ces données avant qu'elles ne soient utilisées de quelque manière que ce soit. | ✓ | ✓ | ✓ | 285 |
+| **8.3.4** | Vérifier que toutes les données sensibles créées et traitées par l'application ont été identifiées, et s'assurer qu'une politique est en place sur la manière de traiter les données sensibles. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 200 |
+| **8.3.5** | Vérifier que l'accès aux données sensibles est contrôlé (sans enregistrer les données sensibles elles-mêmes), si les données sont collectées en vertu des directives pertinentes sur la protection des données ou si l'enregistrement de l'accès est nécessaire. | | ✓ | ✓ | 532 |
+| **8.3.6** | Vérifiez que les informations sensibles contenues dans la mémoire sont écrasées dès qu'elles ne sont plus nécessaires pour atténuer les attaques de vidage de la mémoire, en utilisant des zéros ou des données aléatoires. | | ✓ | ✓ | 226 |
+| **8.3.7** | Vérifier que les informations sensibles ou privées qui doivent être cryptées, le sont à l'aide d'algorithmes approuvés qui assurent à la fois la confidentialité et l'intégrité. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 327 |
+| **8.3.8** | Vérifier que les informations personnelles sensibles font l'objet d'une classification de conservation des données, de sorte que les données anciennes ou périmées soient supprimées automatiquement, selon un calendrier ou selon la situation. | | ✓ | ✓ | 285 |
+
+Lorsqu'on envisage la protection des données, il faut avant tout tenir compte de l'extraction ou de la modification de masse ou de l'utilisation excessive. Par exemple, de nombreux systèmes de médias sociaux ne permettent aux utilisateurs que d'ajouter 100 nouveaux amis par jour, mais le système d'où proviennent ces demandes n'a pas d'importance. Une plateforme bancaire peut souhaiter bloquer plus de 5 transactions par heure en transférant plus de 1000 euros de fonds vers des institutions externes. Les exigences de chaque système sont susceptibles d'être très différentes, de sorte que la décision d'être "anormal" doit tenir compte du modèle de menace et du risque commercial. Les critères importants sont la capacité de détecter, de dissuader ou, de préférence, de bloquer ces actions anormales de masse.
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [Consider using Security Headers website to check security and anti-caching headers](https://securityheaders.io)
+* [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/fr/0x17-V9-Communications.md b/4.0/fr/0x17-V9-Communications.md
new file mode 100644
index 0000000000..f249c582ed
--- /dev/null
+++ b/4.0/fr/0x17-V9-Communications.md
@@ -0,0 +1,43 @@
+# V9 : Exigences de vérification des communications
+
+## Objectif de contrôle
+
+Assurez-vous qu'une demande vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* Le TLS ou le cryptage fort est toujours utilisé, quelle que soit la sensibilité des données transmises
+* Les conseils de configuration les plus récents et les plus importants sont utilisés pour activer et ordonner les algorithmes et les chiffres préférés
+* Les algorithmes et les chiffres faibles ou bientôt obsolètes sont commandés en dernier recours
+* Les algorithmes et les chiffres non sécurisés, dépréciés ou connus, sont désactivés.
+
+Les principaux conseils de l'industrie sur la configuration sécurisée de TLS changent fréquemment, souvent en raison de ruptures catastrophiques dans les algorithmes et les chiffres existants. Utilisez toujours les versions les plus récentes des outils de révision de la configuration TLS (tels que SSLyze ou d'autres scanners TLS) pour configurer l'ordre et la sélection d'algorithme préférés. La configuration doit être vérifiée périodiquement pour s'assurer que la configuration des communications sécurisées est toujours présente et efficace.
+
+## V9.1 Exigences de sécurité des communications des clients
+
+Toutes les communications avec les clients ne doivent avoir lieu que sur des voies de communication cryptées. En particulier, l'utilisation de TLS 1.2 ou d'une version ultérieure est pratiquement obligatoire pour les navigateurs et les moteurs de recherche modernes. La configuration doit être régulièrement revue à l'aide d'outils en ligne afin de s'assurer que les dernières pratiques de pointe sont en place.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **9.1.1** | Vérifiez que le TLS sécurisé est utilisé pour toutes les connexions des clients et ne revient pas à des protocoles non sécurisés ou non chiffrés. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 319 |
+| **9.1.2** | Vérifiez à l'aide d'outils de test TLS en ligne ou actualisés que seuls les algorithmes, les chiffrages et les protocoles puissants sont activés, les algorithmes et les chiffrages les plus puissants étant définis de préférence. | ✓ | ✓ | ✓ | 326 |
+| **9.1.3** | Vérifiez que les anciennes versions des protocoles SSL et TLS, des algorithmes, des chiffres et de la configuration sont désactivées, comme SSLv2, SSLv3, ou TLS 1.0 et TLS 1.1. La dernière version de TLS doit être la suite de chiffrement préférée. | ✓ | ✓ | ✓ | 326 |
+| **9.1.4** | Pour les applications de client lourd, vérifiez que l'application utilise son propre magasin de certificats, ou qu'elle épingle le certificat ou la clé publique du terminal, et qu'elle n'établira pas de connexion avec des terminaux qui offrent un certificat ou une clé différente, même si elle est signée par une AC de confiance. | | | ✓ | 295 |
+
+## V9.2 Exigences de sécurité des communications du serveur
+
+Les communications entre serveurs ne se limitent pas à HTTP. Des connexions sécurisées vers et depuis d'autres systèmes, tels que les systèmes de surveillance, les outils de gestion, l'accès à distance et ssh, les intergiciels, les bases de données, les ordinateurs centraux, les systèmes partenaires ou sources externes -- doivent être en place. Toutes ces connexions doivent être cryptées pour éviter "d'être difficiles à l'extérieur et trivialement faciles à intercepter à l'intérieur".
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **9.2.1** | Vérifiez que les connexions vers et depuis le serveur utilisent des certificats TLS de confiance. Lorsque des certificats générés en interne ou auto-signés sont utilisés, le serveur doit être configuré pour ne faire confiance qu'à des AC internes spécifiques et à des certificats auto-signés spécifiques. Tous les autres doivent être rejetés. | | ✓ | ✓ | 295 |
+| **9.2.2** | Vérifier que les communications cryptées telles que TLS sont utilisées pour toutes les connexions entrantes et sortantes, y compris pour les ports de gestion, la surveillance, l'authentification, les appels d'API ou de service web, les connexions de base de données, de nuage, sans serveur, d'ordinateur central, externes et de partenaires. Le serveur ne doit pas se rabattre sur des protocoles non sécurisés ou non chiffrés. | | ✓ | ✓ | 319 |
+| **9.2.3** | Vérifiez que toutes les connexions cryptées à des systèmes externes qui impliquent des informations ou des fonctions sensibles sont authentifiées. | | ✓ | ✓ | 287 |
+| **9.2.4** | Vérifiez que la révocation de certification appropriée, telle que le protocol OCSP (Online Certificate Status Protocol), est activée et configurée. | | ✓ | ✓ | 299 |
+| **9.2.5** | Vérifiez que les échecs de connexion TLS en arrière-plan sont enregistrés. | | | ✓ | 544 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [OWASP – TLS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html)
+* [OWASP - Pinning Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html)
+* Remarques sur les « modes approuvés de TLS ». Dans le passé, l'ASVS faisait référence à la norme américaine FIPS 140-2, mais en tant que norme mondiale, l'application des normes américaines peut être difficile, contradictoire ou déroutante à appliquer. Une meilleure méthode pour atteindre la conformité avec 9.1.3 consisterait à examiner des guides tels que [Mozilla's Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS) ou [generate known good configurations](https://mozilla.github.io/server-side-tls/ssl-config-generator/), et utiliser des outils d'évaluation TLS connus, tels que sslyze, divers scanners de vulnérabilité ou des services d'évaluation TLS en ligne fiables pour obtenir le niveau de sécurité souhaité. En général, nous constatons que la non-conformité de cette section est l'utilisation de chiffrements et d'algorithmes obsolètes ou non sécurisés, le manque de secret de transmission parfait, les protocoles SSL obsolètes ou non sécurisés, les chiffrements préférés faibles, etc.
diff --git a/4.0/fr/0x18-V10-Malicious.md b/4.0/fr/0x18-V10-Malicious.md
new file mode 100644
index 0000000000..744726017f
--- /dev/null
+++ b/4.0/fr/0x18-V10-Malicious.md
@@ -0,0 +1,54 @@
+# V10 : Exigences de vérification des codes malveillants
+
+## Objectif de contrôle
+
+Assurez-vous que le code satisfait aux exigences de haut niveau suivantes :
+
+* L'activité malveillante est traitée de manière sûre et appropriée pour ne pas affecter le reste de l'application.
+* Il n'y a pas de bombes à retardement ou d'autres attaques basées sur le temps.
+* Ne pas "téléphoner à la maison" vers des destinations malveillantes ou non autorisées.
+* Il n'y a pas de portes dérobées, d'oeufs de Pâques, d'attaques au salami, de rootkits ou de code non autorisé pouvant être contrôlé par un attaquant.
+
+Trouver un code malveillant est une preuve du négatif, qu'il est impossible de valider complètement. Il convient de tout mettre en œuvre pour s'assurer que le code ne comporte pas de code malveillant inhérent ou de fonctionnalité indésirable.
+
+## V10.1 Contrôles de l'intégrité du code
+
+La meilleure défense contre les codes malveillants est de "faire confiance, mais vérifier". L'introduction d'un code non autorisé ou malveillant dans un code est souvent une infraction pénale dans de nombreuses juridictions. Les politiques et les procédures doivent clairement définir les sanctions applicables aux codes malveillants.
+
+Les principaux développeurs doivent régulièrement examiner les vérifications de code, en particulier celles qui peuvent concerner le temps d'accès, les E/S ou les fonctions réseau.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **10.1.1** | Vérifiez qu'un outil d'analyse de code est utilisé pour détecter les codes potentiellement malveillants, tels que les fonctions temporelles, les opérations de fichiers et les connexions réseau non sécurisées. | | | ✓ | 749 |
+
+## V10.2 Recherche de code malveillant
+
+Les codes malveillants sont extrêmement rares et difficiles à détecter. L'examen manuel ligne par ligne du code peut aider à rechercher des bombes logiques, mais même le plus expérimenté des examinateurs de code aura du mal à trouver un code malveillant même s'il sait qu'il existe.
+
+Il n'est pas possible de se conformer à cette section sans un accès complet au code source, y compris aux bibliothèques de tiers.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **10.2.1** | Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de "téléphone à la maison" ou de capacités de collecte de données non autorisées. Lorsque de telles fonctionnalités existent, obtenez l'autorisation de l'utilisateur pour leur fonctionnement avant de collecter des données. | | ✓ | ✓ | 359 |
+| **10.2.2** | Vérifiez que l'application ne demande pas d'autorisations inutiles ou excessives pour les caractéristiques ou capteurs liés à la vie privée, tels que les contacts, les caméras, les microphones ou l'emplacement. | | ✓ | ✓ | 272 |
+| **10.2.3** | Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de portes dérobées, telles que des comptes ou des clés codées en dur ou supplémentaires non documentées, des obscurcissements de code, des blobs binaires non documentés, des rootkits, ou des fonctions de débogage anti-débogage, non sécurisées, ou encore des fonctionnalités obsolètes, non sécurisées ou cachées qui pourraient être utilisées de manière malveillante si elles étaient découvertes. | | | ✓ | 507 |
+| **10.2.4** | Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de bombes à retardement en recherchant les fonctions liées à la date et à l'heure. | | | ✓ | 511 |
+| **10.2.5** | Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de code malveillant, tel que des attaques de type salami, des contournements logiques ou des bombes logiques. | | | ✓ | 511 |
+| **10.2.6** | Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas d'œufs de Pâques ou toute autre fonctionnalité potentiellement indésirable. | | | ✓ | 507 |
+
+## V10.3 Contrôles d'intégrité des applications déployées
+
+Une fois qu'une application est déployée, un code malveillant peut encore être inséré. Les applications doivent se protéger contre les attaques courantes, telles que l'exécution de code non signé provenant de sources non fiables et les rachats de sous-domaines.
+
+La conformité à cette section est susceptible d'être opérationnelle et continue.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **10.3.1** | Vérifiez que si l'application dispose d'une fonction de mise à jour automatique du client ou du serveur, les mises à jour doivent être obtenues par des canaux sécurisés et signées numériquement. Le code de mise à jour doit valider la signature numérique de la mise à jour avant l'installation ou l'exécution de la mise à jour. | ✓ | ✓ | ✓ | 16 |
+| **10.3.2** | Vérifiez que l'application utilise des protections d'intégrité, telles que la signature de code ou l'intégrité des sous-ressources. L'application ne doit pas charger ou exécuter du code provenant de sources non fiables, comme des includes de chargement, des modules, des plugins, du code ou des bibliothèques provenant de sources non fiables ou de l'Internet. | ✓ | ✓ | ✓ | 353 |
+| **10.3.3** | Vérifiez que l'application est protégée contre les reprises de sous-domaines si elle repose sur des entrées DNS ou des sous-domaines DNS, tels que des noms de domaine expirés, des pointeurs DNS ou CNAME obsolètes, des projets expirés dans des dépôts de code source publics, ou des API de nuages transitoires, des fonctions sans serveur, ou des espaces de stockage (*autogen-bucket-id*.cloud.example.com) ou similaires. Les protections peuvent consister à s'assurer que les noms DNS utilisés par les applications sont régulièrement vérifiés pour détecter toute expiration ou modification. | ✓ | ✓ | ✓ | 350 |
+
+## Références
+
+* [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/fr/0x19-V11-BusLogic.md b/4.0/fr/0x19-V11-BusLogic.md
new file mode 100644
index 0000000000..1ad0eb8ee0
--- /dev/null
+++ b/4.0/fr/0x19-V11-BusLogic.md
@@ -0,0 +1,33 @@
+# V11 : Exigences de vérification de la logique d'entreprise
+
+## Objectif de contrôle
+
+Assurez-vous qu'une demande vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* Le flux logique de l'entreprise est séquentiel, traité dans l'ordre, et ne peut être contourné.
+* La logique métier comprend des limites pour détecter et prévenir les attaques automatisées, comme les petits transferts de fonds continus, ou l'ajout d'un million d'amis un à la fois, etc.
+* Les flux de logique commerciale de grande valeur ont pris en compte les cas d'abus et les acteurs malveillants, et disposent de protections contre l'usurpation, l'altération, la répudiation, la divulgation d'informations et les attaques par élévation de privilèges.
+
+## V11.1 Exigences de sécurité de la logique d'entreprise
+
+La sécurité de la logique commerciale est tellement individuelle à chaque demande qu'aucune liste de contrôle ne s'appliquera jamais. La sécurité de la logique d'entreprise doit être conçue pour protéger contre les menaces externes probables - elle ne peut pas être ajoutée en utilisant des pare-feu d'applications web ou des communications sécurisées. Nous recommandons l'utilisation de la modélisation des menaces lors des sprints de conception, par exemple en utilisant l'OWASP Cornucopia ou des outils similaires.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **11.1.1** | Vérifier que l'application traitera seulement les flux de logique métier pour un utilisateur dans l'ordre séquentiel des étapes et sans sauter d'étapes.| ✓ | ✓ | ✓ | 841 |
+| **11.1.2** | Vérifier que l'application traitera seulement les flux de logiques métier, toutes les étapes étant traitées en temps humain réaliste, c'est-à-dire que les transactions ne sont pas soumises trop rapidement (effectuer par un robot).| ✓ | ✓ | ✓ | 799 |
+| **11.1.3** | Vérifiez que l'application comporte des limites appropriées pour des actions ou des transactions commerciales spécifiques qui sont correctement exécutées par utilisateur. | ✓ | ✓ | ✓ | 770 |
+| **11.1.4** | Vérifiez que l'application dispose de contrôles anti-automatisation suffisants pour détecter et protéger contre l'exfiltration de données, les demandes excessives de logique métiers, les téléchargements excessifs de fichiers ou les attaques par déni de service. | ✓ | ✓ | ✓ | 770 |
+| **11.1.5** | Vérifier que l'application a des limites ou une validation de la logique métier pour se protéger contre les risques ou les menaces commerciales probables, identifiés à l'aide de la modélisation des menaces ou de méthodologies similaires. | ✓ | ✓ | ✓ | 841 |
+| **11.1.6** | Vérifiez que la demande ne souffre pas de problèmes de "temps de contrôle au moment de l'utilisation" (TOCTOU) ou d'autres situation de compétition (race condition) pour les opérations sensibles. | | ✓ | ✓ | 367 |
+| **11.1.7** | Vérifiez que les moniteurs de demande ne présentent pas d'événements ou d'activités inhabituels du point de vue de la logique métier. Par exemple, des tentatives d'effectuer des actions hors service ou des actions qu'un utilisateur normal ne tenterait jamais. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 754 |
+| **11.1.8** | Vérifiez que l'application dispose d'alertes configurables lorsque des attaques automatisées ou une activité inhabituelle sont détectées. | | ✓ | ✓ | 390 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [OWASP Testing Guide 4.0: 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/fr/0x20-V12-Files-Resources.md b/4.0/fr/0x20-V12-Files-Resources.md
new file mode 100644
index 0000000000..63a11cf48b
--- /dev/null
+++ b/4.0/fr/0x20-V12-Files-Resources.md
@@ -0,0 +1,63 @@
+# V12 : Exigences de vérification des dossiers et des ressources
+
+## Objectif de contrôle
+
+Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes :
+
+* Les données des fichiers non fiables doivent être traitées en conséquence et de manière sécurisée.
+* Les données de fichiers non fiables obtenues à partir de sources non fiables sont stockées en dehors de la racine web et avec des permissions limitées.
+
+## V12.1 Exigences pour le téléchargement de fichiers
+
+Bien que les bombes zip soient facilement testables à l'aide de techniques de test de pénétration, elles sont considérées comme L2 et au-dessus pour encourager la prise en compte de la conception et du développement avec des tests manuels minutieux, et pour éviter que les tests de pénétration manuels ou automatisés engendre une condition de déni de service.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.1.1** | Vérifiez que la demande n'accepte pas de fichiers volumineux qui pourraient remplir l'espace de stockage ou provoquer un déni de service. | ✓ | ✓ | ✓ | 400 |
+| **12.1.2** | Vérifiez que les fichiers compressés sont contrôlés pour détecter les "bombes zip" - de petits fichiers d'entrée qui se décompresseront en fichiers énormes, épuisant ainsi les limites de stockage des fichiers. | | ✓ | ✓ | 409 |
+| **12.1.3** | Vérifiez qu'un quota de taille de fichier et un nombre maximum de fichiers par utilisateur sont appliqués pour s'assurer qu'un seul utilisateur ne peut pas remplir le stockage avec trop de fichiers, ou des fichiers excessivement gros. | | ✓ | ✓ | 770 |
+
+## V12.2 Exigences en matière d'intégrité des fichiers
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.2.1** | Vérifiez que les fichiers obtenus de sources non fiables sont validés comme étant du type attendu en fonction du contenu du fichier. | | ✓ | ✓ | 434 |
+
+## V12.3 Exigences relatives à l'exécution des fichiers
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.3.1** | Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur ne sont pas utilisées directement par les systèmes de fichiers du système ou du cadre et qu'une API URL est utilisée pour protéger contre la traversée du chemin (path traversal). | ✓ | ✓ | ✓ | 22 |
+| **12.3.2** | Vérifier que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation, la création, la mise à jour ou la suppression de fichiers locaux (LFI). | ✓ | ✓ | ✓ | 73 |
+| **12.3.3** | Vérifier que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation ou l'exécution de fichiers distants (RFI), qui peuvent également conduire à des SSRF. | ✓ | ✓ | ✓ | 98 |
+| **12.3.4** | Vérifiez que l'application protège contre le téléchargement de fichiers réfléchis (RFD) en validant ou en ignorant les noms de fichiers soumis par les utilisateurs dans un paramètre JSON, JSONP ou URL, l'en-tête Content-Type de la réponse doit être défini sur text/plain, et l'en-tête Content-Disposition doit avoir un nom de fichier fixe. | ✓ | ✓ | ✓ | 641 |
+| **12.3.5** | Vérifier que les métadonnées de fichiers non fiables ne sont pas utilisées directement avec l'API système ou les bibliothèques, pour se protéger contre l'injection de commandes du système d'exploitation. | ✓ | ✓ | ✓ | 78 |
+| **12.3.6** | Vérifiez que l'application n'inclut pas et n'exécute pas de fonctionnalités provenant de sources non fiables, telles que des réseaux de distribution de contenu non vérifiés, des bibliothèques JavaScript, des bibliothèques node npm ou des DLL côté serveur. | | ✓ | ✓ | 829 |
+
+## V12.4 Exigences en matière de stockage des fichiers
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.4.1** | Vérifiez que les fichiers obtenus de sources non fiables sont stockés en dehors de la racine web, avec des permissions limitées, de préférence avec une validation forte. | ✓ | ✓ | ✓ | 922 |
+| **12.4.2** | Vérifiez que les fichiers obtenus de sources non fiables sont analysés par des scanners antivirus pour empêcher le téléchargement de contenus malveillants connus. | ✓ | ✓ | ✓ | 509 |
+
+## V12.5 Exigences de téléchargement des fichiers
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.5.1** | Vérifiez que l'application web est configuré pour ne servir que les fichiers ayant des extensions de fichier spécifiques afin d'éviter les informations involontaires et les fuites de code source. Par exemple, les fichiers de sauvegarde (par exemple .bak), les fichiers de travail temporaires (par exemple .swp), les fichiers compressés (.zip, .tar.gz, etc) et les autres extensions couramment utilisées par les éditeurs doivent être bloqués, sauf si cela est nécessaire. | ✓ | ✓ | ✓ | 552 |
+| **12.5.2** | Vérifiez que les demandes directes aux fichiers téléchargés ne seront jamais exécutées en tant que contenu HTML/JavaScript. | ✓ | ✓ | ✓ | 434 |
+
+## V12.6 Exigences de protection des SSRF
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **12.6.1** | Vérifiez que le serveur web ou d'application est configuré avec une liste d'autorisation de ressources ou de systèmes à partir desquels le serveur peut envoyer des requêtes ou charger des données/fichiers. | ✓ | ✓ | ✓ | 918 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html)
diff --git a/4.0/fr/0x21-V13-API.md b/4.0/fr/0x21-V13-API.md
new file mode 100644
index 0000000000..f3883bf171
--- /dev/null
+++ b/4.0/fr/0x21-V13-API.md
@@ -0,0 +1,72 @@
+# V13 : Exigences de vérification des API et des services Web
+
+## Objectif de contrôle
+
+Veiller à ce qu'une application vérifiée qui utilise des API de service de confiance (utilisant généralement JSON ou XML ou GraphQL) tel :
+
+* Une authentification, une gestion de session et une autorisation adéquates de tous les services web.
+* Une validation d'entrée de tous les paramètres qui passent d'un niveau de confiance inférieur à un niveau supérieur.
+* Des contrôles de sécurité efficaces pour tous les types d'API, y compris les API en nuage et les API sans serveur
+
+Veuillez lire ce chapitre en combinaison avec tous les autres chapitres à ce même niveau ; nous ne dupliquons plus les problèmes d'authentification ou de gestion de session API.
+
+## V13.1 Exigences génériques de vérification de la sécurité des services web
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **13.1.1** | Vérifiez que tous les composants de l'application utilisent les mêmes encodages et analyseurs pour éviter les attaques par analyse qui exploitent des comportements différents d'URI ou d'analyse de fichiers qui pourraient être utilisés dans les attaques SSRF et RFI. | ✓ | ✓ | ✓ | 116 |
+| **13.1.2** | Vérifiez que l'accès aux fonctions d'administration et de gestion est limité aux administrateurs autorisés. | ✓ | ✓ | ✓ | 419 |
+| **13.1.3** | Vérifier que les URL des API n'exposent pas d'informations sensibles, telles que la clé API, les jetons de session, etc. | ✓ | ✓ | ✓ | 598 |
+| **13.1.4** | Vérifier que les décisions d'autorisation sont prises à la fois à l'URI, appliquées par la sécurité programmatique ou déclarative au niveau du contrôleur ou du routeur, et au niveau des ressources, appliquées par des autorisations basées sur des modèles de permission. | | ✓ | ✓ | 285 |
+| **13.1.5** | Vérifiez que les demandes contenant des types de contenu inattendus ou manquants sont rejetées avec les en-têtes appropriés (statut de réponse HTTP 406 Inacceptable ou 415 Type de support non pris en charge). | | ✓ | ✓ | 434 |
+
+## V13.2 Exigences de védification pour les services web de type RESTful
+
+La validation du schéma JSON en est à un stade préliminaire de normalisation ([voir références](https://json-schema.org/specification.html)). Lorsque vous envisagez d'utiliser la validation de schéma JSON, qui est la meilleure pratique pour les services web RESTful, pensez à utiliser ces stratégies de validation de données supplémentaires en combinaison avec la validation de schéma JSON :
+
+* Validation de l'objet JSON, par exemple s'il y a des éléments manquants ou en trop.
+* Validation des valeurs de l'objet JSON en utilisant des méthodes de validation d'entrée standard, telles que le type de données, le format de données, la longueur, etc.
+* et validation formelle du schéma JSON.
+
+Une fois que la norme de validation du schéma JSON sera formalisée, l'ASVS mettra à jour ses conseils dans ce domaine. Surveillez attentivement toutes les bibliothèques de validation de schémas JSON utilisées, car elles devront être mises à jour régulièrement jusqu'à ce que la norme soit formalisée et que les bogues soient éliminés des implémentations de référence.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **13.2.1** | Vérifiez que les méthodes HTTP RESTful activées sont un choix valable pour l'utilisateur ou une action, comme par exemple empêcher les utilisateurs normaux d'utiliser le verbe DELETE ou PUT sur des API ou des ressources protégées. | ✓ | ✓ | ✓ | 650 |
+| **13.2.3** | Vérifiez que les requêtes HTTP utilisant le verbe HEAD, OPTIONS, TRACE ou GET ne modifient aucune structure de données dorsale ni n'effectuent aucune action de changement d'état. Ces requêtes sont des méthodes sûres et ne devraient donc pas avoir d'effets secondaires. | ✓ | ✓ | ✓ | 650 |
+| **13.2.3** | Vérifier que la validation du schéma JSON est en place et vérifiée avant d'accepter la saisie. | ✓ | ✓ | ✓ | 20 |
+| **13.2.4** | Vérifiez que les services web RESTful qui utilisent des cookies sont protégés contre la falsification des requêtes intersites par l'utilisation d'au moins un ou plusieurs des éléments suivants : modèle de cookie à triple ou double soumission (voir [références](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)), nonces CSRF ou vérification de l'en-tête de la requête d'origine. | ✓ | ✓ | ✓ | 352 |
+| **13.2.5** | Vérifiez que les services REST disposent de contrôles anti-automatisation pour se protéger contre les appels excessifs, surtout si l'API n'est pas authentifiée. | | ✓ | ✓ | 770 |
+| **13.2.6** | Vérifiez que les services REST vérifient explicitement que le type de contenu entrant est bien celui attendu, par exemple application/xml ou application/json. | | ✓ | ✓ | 436 |
+| **13.2.7** | Vérifiez que les en-têtes et la données utiles sont dignes de confiance et intègre. Exiger un cryptage fort pour le transport (TLS uniquement) peut être suffisant dans de nombreux cas, car il assure à la fois la protection de la confidentialité et de l'intégrité. Les messages signés peuvent fournir une assurance supplémentaire en plus des protections de transport pour les applications de haute sécurité, mais elles entraînent une complexité et des risques supplémentaires à comparer avec les avantages. | | ✓ | ✓ | 345 |
+
+## V13.3 Exigences de vérification du service web SOAP
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **13.3.1** | Vérifier que la validation du schéma XSD a lieu pour garantir un document XML correctement formé, suivie de la validation de chaque champ de saisie avant tout traitement de ces données. | ✓ | ✓ | ✓ | 20 |
+| **13.3.2** | Vérifier que la charge utile du message est signée en utilisant WS-Security pour assurer un transport fiable entre le client et le service. | | ✓ | ✓ | 345 |
+
+Note : En raison de problèmes liés aux attaques XXE contre les DTD, la validation des DTD ne doit pas être utilisée, et l'évaluation des DTD cadre doit être désactivée conformément aux exigences définies dans la configuration V14.
+
+## V13.4 GraphQL et autres exigences de sécurité de la couche de données des services Web
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **13.4.1** | Vérifiez qu'un méchanisme de limitation d'allocation de resource ou de limitation de complexité soit en place pour prévenir les dénis de services. | | ✓ | ✓ | 770 |
+| **13.4.2** | Vérifiez que la logique d'autorisation de GraphQL ou d'une autre couche de données doit être mise en œuvre au niveau de la couche de logique d'entreprise au lieu de la couche GraphQL. | | ✓ | ✓ | 285 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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#triple-submit-cookie)
+* [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)
diff --git a/4.0/fr/0x22-V14-Config.md b/4.0/fr/0x22-V14-Config.md
new file mode 100644
index 0000000000..dc465672b9
--- /dev/null
+++ b/4.0/fr/0x22-V14-Config.md
@@ -0,0 +1,86 @@
+# V14 : Exigences de vérification de la configuration
+
+## Objectif de contrôle
+
+Assurez-vous qu'une application vérifiée satisfait :
+
+* Un environnement de construction sécurisé, reproductible et automatisable.
+* Une gestion des dépendances étroite et une configuration renforcée, de sorte que les composants obsolètes ou non sécurisés ne soient pas inclus dans l'application.
+* Une configuration sécurisée par défaut, de sorte que les administrateurs et les utilisateurs doivent affaiblir la sécurité par défaut.
+
+La configuration de l'application "out of the box" doit être sûre pour être sur Internet, ce qui signifie une configuration "out of the box".
+
+## V14.1 Exigences sur les constructions
+
+Les pipelines de construction sont la base d'une sécurité reproductible : chaque fois qu'un élément non sécurisé est découvert, il peut être résolu dans le code source, les scripts de construction ou de déploiement, et testé automatiquement. Nous encourageons fortement l'utilisation de pipelines de compilation avec des contrôles de sécurité et de dépendance automatiques qui avertissent ou interrompent la compilation afin d'éviter que des problèmes de sécurité connus ne soient déployés en production. Les étapes manuelles effectuées de manière irrégulière conduisent directement à des erreurs de sécurité évitables.
+
+Alors que l'industrie se dirige vers un modèle DevSecOps, il est important de garantir la disponibilité et l'intégrité continues du déploiement et de la configuration pour atteindre un état "known good". Dans le passé, si un système était piraté, il fallait des jours, voire des mois, pour prouver qu'aucune autre intrusion n'avait eu lieu. Aujourd'hui, avec l'avènement des infrastructures définies par logiciel, des déploiements A/B rapides sans aucun temps d'arrêt, et des constructions automatisées conteneurisées, il est possible de construire, de durcir et de déployer automatiquement et en continu un "known good" en remplacement de tout système compromis.
+
+Si les modèles traditionnels sont toujours en place, des mesures manuelles doivent être prises pour renforcer et sauvegarder cette configuration afin de permettre le remplacement rapide des systèmes compromis par des systèmes à haute intégrité et sans compromis, et ce dans les meilleurs délais.
+
+La conformité à cette section nécessite un système de construction automatisé et l'accès à des scripts de construction et de déploiement.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.1.1** | Vérifier que les processus de construction et de déploiement des applications sont effectués de manière sûre et répétable, comme l'automatisation des CI / CD, la gestion automatisée de la configuration et les scripts de déploiement automatisés. | | ✓ | ✓ | |
+| **14.1.2** | Vérifiez que les drapeaux du compilateur sont configurés pour activer toutes les protections et les avertissements disponibles contre les débordements de mémoire tampon, y compris la randomisation de la pile, la prévention de l'exécution des données, et pour casser la compilation si un pointeur, une mémoire, une chaîne de format, un entier ou une chaîne de caractères dangereux sont trouvés. | | ✓ | ✓ | 120 |
+| **14.1.3** | Vérifiez que la configuration du serveur est durcie conformément aux recommandations du serveur d'application et des cadres utilisés. | | ✓ | ✓ | 16 |
+| **14.1.4** | Vérifier que l'application, la configuration et toutes les dépendances peuvent être redéployées à l'aide de scripts de déploiement automatisés, construites à partir d'un runbook documenté et testé dans un délai raisonnable, ou restaurées à partir de sauvegardes en temps utile. | | ✓ | ✓ | |
+| **14.1.5** | Vérifier que les administrateurs autorisés peuvent vérifier l'intégrité de toutes les configurations pertinentes pour la sécurité afin de détecter les altérations. | | | ✓ | |
+
+## V14.2 Exigences sur les dépendances
+
+La gestion des dépendances est essentielle au bon fonctionnement de toute application, quel que soit son type. L'incapacité à se tenir à jour avec des dépendances obsolètes ou peu sûres est la cause première des attaques les plus importantes et les plus coûteuses à ce jour.
+
+Remarque : au niveau 1, la conformité à la norme 14.2.1 concerne les observations ou les détections de bibliothèques et de composants côté client et autres, plutôt que l'analyse statique du code de construction ou l'analyse des dépendances, plus précise. Ces techniques plus précises pourraient être découvertes par des entretiens, le cas échéant.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.2.1** | Vérifiez que tous les composants sont à jour, de préférence en utilisant un vérificateur de dépendances pendant le temps de construction ou de compilation. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 1026 |
+| **14.2.2** | Vérifiez que toutes les fonctionnalités, la documentation, les échantillons et les configurations inutiles sont supprimés, tels que les exemples d'applications, la documentation de la plate-forme et les utilisateurs par défaut ou les exemples. | ✓ | ✓ | ✓ | 1002 |
+| **14.2.3** | Vérifier que si les actifs d'application, tels que les bibliothèques JavaScript, les feuilles de style CSS ou les polices web, sont hébergés en externe sur un réseau de diffusion de contenu (CDN) ou un fournisseur externe, l'intégrité des sous-ressources (SRI) est utilisée pour valider l'intégrité de l'actif. | ✓ | ✓ | ✓ | 829 |
+| **14.2.4** | Vérifier que les composants tiers proviennent de dépôts prédéfinis, fiables et continuellement entretenus. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 829 |
+| **14.2.5** | Vérifier qu'un catalogue d'inventaire de toutes les bibliothèques tierces en service est tenu à jour. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | |
+| **14.2.6** | Vérifiez que la surface d'attaque est réduite en mettant en bac à sable ou en encapsulant des bibliothèques tierces pour n'exposer que le comportement requis dans l'application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 |
+
+## V14.3 Exigences de divulgation involontaire de renseignements sur la sécurité
+
+Les configurations de production devraient être renforcées pour se protéger contre les attaques courantes, telles que les consoles de débogage, relever la barre pour les attaques de type "cross-site scripting" (XSS) et "remote file inclusion" (RFI), et pour éliminer les "vulnérabilités" triviales de découverte d'informations qui sont la marque indésirable de nombreux rapports de tests de pénétration. Nombre de ces problèmes sont rarement considérés comme un risque important, mais ils sont liés à d'autres vulnérabilités. Si ces problèmes ne sont pas présents par défaut, elle place la barre plus haute avant que la plupart des attaques puissent réussir.
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.3.1** | Vérifiez que les messages d'erreur du serveur web ou d'application et du cadre sont configurés pour fournir des réponses personnalisées et exploitables par l'utilisateur afin d'éliminer toute divulgation involontaire de sécurité. | ✓ | ✓ | ✓ | 209 |
+| **14.3.2** | Vérifier que les modes de débogage du serveur web ou d'application et du cadre d'application sont désactivés en production afin d'éliminer les fonctionnalités de débogage, les consoles de développement et les divulgations de sécurité non intentionnelles. | ✓ | ✓ | ✓ | 497 |
+| **14.3.3** | Vérifiez que les en-têtes HTTP ou toute partie de la réponse HTTP n'exposent pas d'informations détaillées sur la version des composants du système. | ✓ | ✓ | ✓ | 200 |
+
+## V14.4 Exigences relatives aux en-têtes de sécurité HTTP
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.4.1** | Vérifiez que chaque réponse HTTP contient un en-tête Content-Type. Les types de contenu text/*, */*+xml et application/xml doivent également spécifier un jeu de caractères sûr (par exemple, UTF-8, ISO-8859-1). | ✓ | ✓ | ✓ | 173 |
+| **14.4.2** | Vérifiez que toutes les réponses de l'API contiennent Content-Disposition : attachment ; filename="api.json" (ou tout autre nom de fichier approprié pour le type de contenu). | ✓ | ✓ | ✓ | 116 |
+| **14.4.3** | Vérifier qu'une politique de sécurité du contenu (CSP) est en place pour aider à atténuer l'impact des attaques XSS comme les vulnérabilités d'injection HTML, DOM, JSON et JavaScript. | ✓ | ✓ | ✓ | 1021 |
+| **14.4.4** | Vérifiez que toutes les réponses contiennent X-Content-Type-Options: nosniff. | ✓ | ✓ | ✓ | 116 |
+| **14.4.5** | Vérifiez que l'en-tête Strict-Transport-Security est inclus dans toutes les réponses et pour tous les sous-domaines, comme Strict-Transport-Security : max-age=15724800 ; includeSubdomains. | ✓ | ✓ | ✓ | 523 |
+| **14.4.6** | Vérifiez qu'un en-tête "Referrer-Policy" approprié est inclus, tel que "no-referrer" ou "same-origin". | ✓ | ✓ | ✓ | 116 |
+| **14.4.7** | Vérifier que le contenu d'une application web ne peut pas être intégré par défaut dans un site tiers et que l'intégration des ressources exactes n'est autorisée que si nécessaire en utilisant un en-tête approprié tel "Content-Security-Policy: frame-ancestors" ou "X-Frame-Options". | ✓ | ✓ | ✓ | 346 |
+
+## V14.5 Exigences sur la validation des en-têtes de requête HTTP
+
+| # | Description | L1 | L2 | L3 | CWE |
+| :---: | :--- | :---: | :---:| :---: | :---: |
+| **14.5.1** | Vérifiez que le serveur d'application accepte seulement les méthodes HTTP utilisées par l'application/API (incluant les requetes de type OPTIONS), et les journalise/alertes sur toutes les demandes qui sont invalades pour le contexte de l'application. | ✓ | ✓ | ✓ | 749 |
+| **14.5.2** | Vérifiez que l'en-tête Origin fourni n'est pas utilisé pour les décisions d'authentification ou de contrôle d'accès, car l'en-tête Origin peut facilement être modifié par un attaquant. | ✓ | ✓ | ✓ | 346 |
+| **14.5.3** | Vérifiez que l'en-tête "Cross-Origin Resource Sharing" (CORS) Access-Control-Allow-Origin utilise une liste d'autorisation stricte de domaines et sous-domaines de confiance pour la comparaison avec l'origine "null" et ne la prend pas en charge. | ✓ | ✓ | ✓ | 346 |
+| **14.5.4** | Vérifiez que les en-têtes HTTP ajoutés par un proxy de confiance ou des dispositifs SSO, tels qu'un jeton au porteur, sont authentifiés par l'application. | | ✓ | ✓ | 306 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [OWASP Testing Guide 4.0: 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://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://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/fr/0x90-Appendix-A_Glossary.md b/4.0/fr/0x90-Appendix-A_Glossary.md
new file mode 100644
index 0000000000..9ebebdaa16
--- /dev/null
+++ b/4.0/fr/0x90-Appendix-A_Glossary.md
@@ -0,0 +1,41 @@
+# Annexe A : Glossaire
+
+- **2FA** - L'authentification à deux facteurs(2FA) ajoute un deuxième niveau d'authentification à la connexion d'un compte.
+- **Address Space Layout Randomization (ASLR)** - Une technique pour rendre plus difficile l'exploitation des bugs de corruption de la mémoire.
+- **Sécurité des applications** - La sécurité au niveau des applications se concentre sur l'analyse des composants qui constituent la couche application du modèle de référence d'interconnexion des systèmes ouverts (modèle OSI), plutôt que de se concentrer par exemple sur le système d'exploitation sous-jacent ou les réseaux connectés.
+- **Vérification de la sécurité des applications** - L'évaluation technique d'une application par rapport à l'ASVS de l'OWASP.
+- **Rapport de vérification de la sécurité des applications** - Rapport qui documente les résultats globaux et l'analyse à l'appui produite par le vérificateur pour une application particulière.
+- **Authentification** - La vérification de l'identité déclarée d'un utilisateur d'application.
+- **Vérification automatisée** - Utilisation d'outils automatisés (soit des outils d'analyse dynamique, soit des outils d'analyse statique, soit les deux) qui utilisent les signatures de vulnérabilité pour trouver des problèmes.
+- **Test de la boîte noire** - Méthode de test de logiciels qui consiste à examiner la fonctionnalité d'une application sans examiner ses structures ou son fonctionnement internes.
+- **Composant** - unité de code autonome, avec des interfaces disque et réseau associées, qui communique avec d'autres composants.
+- **Scripting intersite** (XSS) - Faille de sécurité que l'on trouve généralement dans les applications web et qui permet l'injection de scripts côté client dans le contenu.
+- **Module cryptographique** - Matériel, logiciel et/ou microprogramme qui met en œuvre des algorithmes cryptographiques et/ou génère des clés cryptographiques.
+- **CWE** - Common Weakness Enumeration (CWE) est une liste développée par la communauté des faiblesses communes de sécurité logicielle. Elle sert de langage commun, de mesure pour les outils de sécurité des logiciels, et de base pour l'identification des faiblesses, l'atténuation et les efforts de prévention.
+- **DAST** - Les technologies de test dynamique de la sécurité des applications (DAST) sont conçues pour détecter les conditions indiquant une vulnérabilité de sécurité dans une application en cours d'exécution.
+- **Vérification de la conception** - Évaluation technique de l'architecture de sécurité d'une application.
+- **Vérification dynamique** - L'utilisation d'outils automatisés qui utilisent les signatures de vulnérabilité pour trouver des problèmes pendant l'exécution d'une application.
+- **Globally Unique Identifier** (GUID) - Numéro de référence unique utilisé comme identifiant dans un logiciel.
+- **Hyper Text Transfer Protocol** (HTTPS) - Un protocole d'application pour les systèmes d'information hypermédia distribués et collaboratifs. Il constitue la base de la communication de données pour le World Wide Web.
+- **Clé codée en dur** - Clé cryptographique qui est stockée sur le système de fichiers, que ce soit dans le code, les commentaires ou les fichiers.
+- **Validation des entrées** - La canonisation et la validation des entrées des utilisateurs non fiables.
+- **Code malveillant** - Code introduit dans une application au cours de son développement à l'insu du propriétaire de l'application, qui contourne la politique de sécurité prévue pour l'application. Ce n'est pas la même chose qu'un logiciel malveillant tel qu'un virus ou un ver !
+- **Malware** - Code exécutable qui est introduit dans une application pendant son exécution à l'insu de l'utilisateur ou de l'administrateur de l'application.
+- **Open Web Application Security Project** (OWASP) - L'Open Web Application Security Project (OWASP) est une communauté mondiale libre et ouverte qui vise à améliorer la sécurité des logiciels d'application. Notre mission est de rendre la sécurité des applications "visible", afin que les personnes et les organisations puissent prendre des décisions éclairées sur les risques liés à la sécurité des applications. Voir : [https://www.owasp.org/](https://www.owasp.org/)
+- **Informations d'identification personnelle** (IIP) - sont des informations qui peuvent être utilisées seules ou avec d'autres informations pour identifier, contacter ou localiser une seule personne, ou pour identifier un individu dans son contexte.
+- **PIE** - L'exécutable indépendant de la position (PIE) est un corps de code machine qui, placé quelque part dans la mémoire primaire, s'exécute correctement quelle que soit son adresse absolue.
+- **PKI** - Public Key Infrastructure (PKI) est un arrangement qui lie les clés publiques avec les identités respectives des entités. La liaison est établie par un processus d'enregistrement et de délivrance de certificats auprès et par une autorité de certification (CA).
+- **SAST** - Le test statique de sécurité des applications (SAST) est un ensemble de technologies conçues pour analyser le code source des applications, le code d'octet et les binaires pour le codage et les conditions de conception qui sont indicatives des vulnérabilités de sécurité. Les solutions SAST analysent une application de "l'intérieur vers l'extérieur" dans un état de non-exécution.
+- **SDLC** - Cycle de vie du développement logiciel.
+- **Security Architecture** - Une abstraction de la conception d'une application qui identifie et décrit où et comment les contrôles de sécurité sont utilisés, et identifie et décrit également l'emplacement et la sensibilité des données de l'utilisateur et de l'application.
+- **Configuration de la sécurité** - La configuration d'exécution d'une application qui affecte la manière dont la sécurité est assurée.
+- **Contrôle de sécurité** - Une fonction ou un composant qui effectue un contrôle de sécurité (par exemple, un contrôle d'accès) ou qui, lorsqu'il est appelé, produit un effet de sécurité (par exemple, en générant un enregistrement d'audit).
+- **Injection SQL (SQLi)** - Technique d'injection de code utilisée pour attaquer des applications orientées données, dans laquelle des instructions SQL malveillantes sont insérées dans un point d'entrée.
+- **SSO Authentification** - Le Single Sign On (SSO) se produit lorsqu'un utilisateur se connecte à une application et est ensuite automatiquement connecté à d'autres applications sans avoir à se ré-authentifier. Par exemple, lorsque vous vous connectez à Google, lorsque vous accédez à d'autres services Google tels que YouTube, Google Docs et Gmail, vous serez automatiquement connecté.
+- **SVG** - Graphiques vectoriels évolutifs
+- **Modélisation de la menace** - Technique consistant à développer des architectures de sécurité de plus en plus raffinées pour identifier les agents de menace, les zones de sécurité, les contrôles de sécurité et les actifs techniques et commerciaux importants.
+- **Transport Layer Security** - Protocoles cryptographiques qui assurent la sécurité des communications sur une connexion réseau
+- **URI/URL/URL fragments** - Un Uniform Resource Identifier est une chaîne de caractères utilisée pour identifier un nom ou une ressource web. Un Uniform Resource Locator est souvent utilisé comme référence à une ressource.
+- **Vérificateur** - La personne ou l'équipe qui examine une demande par rapport aux exigences de l'OWASP ASVS.
+- **liste d'autorisation** - Une liste de données ou d'opérations autorisées, par exemple une liste de caractères qui sont autorisés à effectuer une validation d'entrée.
+- **Certificat X.509** - Un certificat X.509 est un certificat numérique qui utilise la norme internationale largement acceptée d'infrastructure à clé publique (PKI) X.509 pour vérifier qu'une clé publique appartient à l'utilisateur, à l'ordinateur ou à l'identité du service contenu dans le certificat.
diff --git a/4.0/fr/0x91-Appendix-B_References.md b/4.0/fr/0x91-Appendix-B_References.md
new file mode 100644
index 0000000000..06106ddc58
--- /dev/null
+++ b/4.0/fr/0x91-Appendix-B_References.md
@@ -0,0 +1,42 @@
+# Annexe B : Références
+
+Les projets suivants de l'OWASP sont les plus susceptibles d'être utiles aux utilisateurs/adopteurs de cette norme :
+
+## Projets de base de l'OWASP
+
+1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/)
+2. OWASP 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/)
+
+## Projet OWASP Cheat Sheet Series
+
+[This project](https://cheatsheetseries.owasp.org/) has a number of cheat sheets which will be relevant for different topics in the ASVS.
+
+Vous trouverez ici une correspondance avec l'ASVS : [https://github.com/OWASP/CheatSheetSeries/blob/master/IndexASVS.md](https://github.com/OWASP/CheatSheetSeries/blob/master/IndexASVS.md)
+
+## Projets liés à la sécurité mobile
+
+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: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/)
+
+## Projets liés à l'Internet des objets de l'OWASP
+
+1. Projet OWASP "Internet of Things" : [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project)
+
+## Projets OWASP sans serveur
+
+1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/)
+
+## Autres
+
+De même, les sites web suivants sont les plus susceptibles d'être utiles aux utilisateurs/adopteurs de cette norme
+
+1. SecListes Github : [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists)
+2. MITRE Dénombrement des faiblesses communes : [https://cwe.mitre.org/](https://cwe.mitre.org/)
+3. Conseil des normes de sécurité PCI : [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org)
+4. Norme de sécurité des données PCI (DSS) v3.2.1 Exigences et procédures d'évaluation de la sécurité : [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf)
+5. PCI Software Security Framework - Exigences et procédures d'évaluation des logiciels sécurisés : [https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf)
+6. Exigences et procédures d'évaluation du PCI Secure Software Lifecycle (Secure SLC) : [https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf)
diff --git a/4.0/fr/0x93-Appendix-C_IoT.md b/4.0/fr/0x93-Appendix-C_IoT.md
new file mode 100644
index 0000000000..9ccb8da972
--- /dev/null
+++ b/4.0/fr/0x93-Appendix-C_IoT.md
@@ -0,0 +1,59 @@
+# Annexe C : Exigences de vérification de l'Internet des objets
+
+Cette section était à l'origine dans la branche principale, mais avec le travail effectué par l'équipe IoT OWASP, il n'est pas logique de maintenir deux fils de discussion différents sur le sujet. Pour la version 4.0, nous la déplaçons vers l'annexe, et nous invitons tous ceux qui le souhaitent à utiliser plutôt la branche principale [OWASP IoT project](https://owasp.org/www-project-internet-of-things/)
+
+## Objectif de contrôle
+
+Les dispositifs embarqués/implantés devraient :
+
+* Avoir le même niveau de contrôle de sécurité dans le dispositif que dans le serveur, en appliquant les contrôles de sécurité dans un environnement de confiance.
+* Les données sensibles stockées sur l'appareil doivent l'être de manière sécurisée en utilisant un stockage sauvegardé par du matériel tel que des éléments sécurisés.
+* Toutes les données sensibles transmises par le dispositif doivent utiliser la couche de transport de sécurité.
+
+## Exigences de vérification de la sécurité
+
+| # | Description | L1 | L2 | L3 | Depuis
+| :---: | :--- | :---: | :---: | :---: | :---: |
+| **C.1** | Vérifiez que les interfaces de débogage de la couche application telles que les interfaces USB, UART et autres variantes série sont désactivées ou protégées par un mot de passe complexe. | ✓ | ✓ | ✓ | 4.0 |
+| **C.2** | Vérifier que les clés et certificats cryptographiques sont uniques à chaque appareil. | ✓ | ✓ | ✓ | 4.0 |
+| **C.3** | Vérifiez que les contrôles de protection de la mémoire tels que ASLR et DEP sont activés par le système d'exploitation embarqué/OT, le cas échéant. | ✓ | ✓ | ✓ | 4.0 |
+| **C.4** | Vérifiez que les interfaces de débogage sur puce telles que JTAG ou SWD sont désactivées ou que le mécanisme de protection disponible est activé et configuré de manière appropriée. | ✓ | ✓ | ✓ | 4.0 |
+| **C.5** | Vérifiez que l'exécution de confiance est mise en œuvre et activée, si elle est disponible sur le SoC ou le CPU de l'appareil. | ✓ | ✓ | ✓ | 4.0 |
+| **C.6** | Vérifier que les données sensibles, les clés privées et les certificats sont stockés de manière sécurisée dans un élément sécurisé, TPM, TEE (Trusted Execution Environment), ou protégés par une cryptographie forte. | ✓ | ✓ | ✓ | 4.0 |
+| **C.7** | Vérifiez que les applications du microprogramme protègent les données en transit en utilisant la sécurité de la couche transport. | ✓ | ✓ | ✓ | 4.0 |
+| **C.8** | Vérifiez que les applications du microprogramme valident la signature numérique des connexions au serveur. | ✓ | ✓ | ✓ | 4.0 |
+| **C.9** | Vérifiez que les communications sans fil sont mutuellement authentifiées. | ✓ | ✓ | ✓ | 4.0 |
+| **C.10** | Vérifiez que les communications sans fil sont envoyées sur un canal crypté. | ✓ | ✓ | ✓ | 4.0 |
+| **C.11** | Vérifier que toute utilisation de fonctions C interdites est remplacée par les fonctions équivalentes sûres appropriées. | ✓ | ✓ | ✓ | 4.0 |
+| **C.12** | Vérifiez que chaque microprogramme tient à jour une nomenclature des logiciels cataloguant les composants tiers, le versionnage et les vulnérabilités publiées. | ✓ | ✓ | ✓ | 4.0 |
+| **C.13** | Vérifier que tous les codes, y compris les binaires de tiers, les bibliothèques, les cadres sont examinés pour les références codées en dur (backdoors). | ✓ | ✓ | ✓ | 4.0 |
+| **C.14** | Vérifiez que les composants de l'application et du micrologiciel ne sont pas susceptibles de recevoir l'OS Command Injection en invoquant des enveloppes de commandes shell, des scripts, ou que les contrôles de sécurité empêchent l'OS Command Injection. | ✓ | ✓ | ✓ | 4.0 |
+| **C.15** | Vérifiez que les applications du microprogramme fixent la signature numérique à un ou plusieurs serveurs de confiance. | | ✓ | ✓ | 4.0 |
+| **C.16** | Vérifier la présence de dispositifs de résistance et/ou de détection de l'altération. | | ✓ | ✓ | 4.0 |
+| **C.17** | Vérifiez que toutes les technologies de protection de la propriété intellectuelle disponibles fournies par le fabricant de la puce sont activées. | | ✓ | ✓ | 4.0 |
+| **C.18** | Vérifiez que des contrôles de sécurité sont en place pour empêcher l'ingénierie inverse des microprogrammes (par exemple, suppression des symboles de débogage verbeux). | | ✓ | ✓ | 4.0 |
+| **C.19** | Vérifiez que le périphérique valide la signature de l'image de démarrage avant le chargement. | | ✓ | ✓ | 4.0 |
+| **C.20** | Vérifiez que le processus de mise à jour du microprogramme n'est pas vulnérable aux attaques par heure de contrôle ou par heure d'utilisation. | | ✓ | ✓ | 4.0 |
+| **C.21** | Vérifiez que l'appareil utilise la signature de code et valide les fichiers de mise à jour du micrologiciel avant l'installation. | | ✓ | ✓ | 4.0 |
+| **C.22** | Vérifiez que l'appareil ne peut pas être rétrogradé vers d'anciennes versions (anti-rollback) de firmware valide. | | ✓ | ✓ | 4.0 |
+| **C.23** | Vérifier l'utilisation d'un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé sur un dispositif intégré (par exemple, en utilisant des générateurs de nombres aléatoires fournis par des puces). | | ✓ | ✓ | 4.0 |
+| **C.24** | Vérifiez que le microprogramme peut effectuer des mises à jour automatiques selon un calendrier prédéfini. | | ✓ | ✓ | 4.0 |
+| **C.25** | Vérifiez que l'appareil efface le micrologiciel et les données sensibles dès la détection d'une altération ou la réception d'un message non valide. | | | ✓ | 4.0 |
+| **C.26** | Vérifiez que seuls les microcontrôleurs qui prennent en charge la désactivation des interfaces de débogage (par exemple JTAG, SWD) sont utilisés. | | | ✓ | 4.0 |
+| **C.27** | Vérifiez que seuls les microcontrôleurs qui offrent une protection substantielle contre le décapuchonnage et les attaques des canaux latéraux sont utilisés. | | | ✓ | 4.0 |
+| **C.28** | Vérifier que les traces sensibles ne sont pas exposées aux couches extérieures du circuit imprimé. | | | ✓ | 4.0 |
+| **C.29** | Vérifiez que la communication entre les puces est cryptée (par exemple, communication de carte principale à carte fille). | | | ✓ | 4.0 |
+| **C.30** | Vérifiez que l'appareil utilise la signature de code et valide le code avant l'exécution. | | | ✓ | 4.0 |
+| **C.31** | Vérifiez que les informations sensibles conservées en mémoire sont écrasées par des zéros dès qu'elles ne sont plus nécessaires. | | | ✓ | 4.0 |
+| **C.32** | Vérifiez que les applications de microprogrammes utilisent des conteneurs de noyau pour l'isolation entre les applications. | | | ✓ | 4.0 |
+| **C.33** | Vérifiez que les drapeaux de compilateurs sécurisés tels que -fPIE, -fstack-protector-all, -Wl,-z,noexecstack, -Wl,-z,noexecheap sont configurés pour les constructions de microprogrammes. | | | ✓ | 4.0 |
+| **C.34** | Vérifiez que les microcontrôleurs sont configurés avec une protection par code (le cas échéant). | | | ✓ | 4.0 |
+
+## Références
+
+Pour plus d'informations, voir aussi :
+
+* [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/generate-all.sh b/4.0/generate-all.sh
index 5a6f43a7dc..e75a388a4f 100644
--- a/4.0/generate-all.sh
+++ b/4.0/generate-all.sh
@@ -1,10 +1,11 @@
#!/bin/bash
lang="en"
-vers="4.0.2"
+vers="4.0.3"
verslong="./docs_$lang/OWASP Application Security Verification Standard $vers-$lang"
python3 export.py --format json --language $lang > "$verslong.json"
+python3 export.py --format json_flat --language $lang > "$verslong.flat.json"
python3 export.py --format xml --language $lang > "$verslong.xml"
python3 export.py --format csv --language $lang > "$verslong.csv"
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000000..cf102ca718
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,78 @@
+# Contributing
+
+**This document applies during 2021 and may change at a future date.**
+
+
+
+### Introduction
+
+The current status of the ASVS project is as follows:
+
+> The ASVS project is planning to release a 5.0 version during 2022 which will be a significant modification, similar to the scale of changes which happened during 4.0.
+>
+> We will try, on a best efforts basis, to address issues and push changes to the "bleeding edge", master branch. For as long as possible, we will make changes to this branch **without altering current numbering** and wherever possible we will push minor, non-breaking changes to a 4.0.3 branch which may or may not be formally released.
+
+### How to make changes to the bleeding edge during this period
+
+To help those who are using the "bleeding edge" version for their tests and in order to be able to track changes made during this period, we have prepared a set of labels to be used when making changes to the "bleeding edge" version during this time. If there is enough content to make a 4.0.3 or 4.1 release, this will also make it easier to get an overview of changes in place
+
+### Standard for changes
+
+#### Keep all current numbers
+
+* New requirements must be placed at the end of sub-category
+* Deleted requirements must keep "placeholder" to avoid some other requirements to be added/moved to that number, examples:
+
+```
+| **1.2.1** | [MOVED TO 1.14.7] | | | | |
+```
+
+```
+| **5.5.1** | [DELETED] | | | | |
+```
+
+#### Use tags to describe the change
+
+The following tags should be added to any modified requirement as appropriate. These tags should all be relative to how the requirement appeared in v4.0.3.
+
+* `[ADDED]` - New requirement (should only be added at the end of a sub-section.)
+* `[ADDED, SPLIT FROM x.y.z]` - New requirement which was previously part of another requirement
+* `[MODIFIED]` - Requirement description has been modified
+* `[MOVED FROM x.y.z]` - Requirement has been moved to a different sub-section but **not** modified. (should only be added at the end of a sub-section.)
+* `[MODIFIED, MOVED FROM x.y.z]` - Requirement description has been modified **and** requirement has been moved to a different sub-section.
+* `[MOVED TO x.y.z]` - Placeholder to keep number, requirement has been moved to another category (but not modified).
+* `[DELETED]` - Placeholder to keep number, requirement has been deleted
+* `[DELETED, MERGED TO x.y.z]` - Placeholder to keep number, requirement has been merged into another requirement, e.g. to solve a duplicate
+* `[LEVEL L1 > L2]` - Requirement's level has changed
+
+CWE and/or NIST mapping changes do not require labels.
+
+Tags must be placed before verification description, example:
+
+```
+| **12.4.2** | [MODIFIED] Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | ✓ | ✓ | ✓ | 509 |
+```
+
+
diff --git a/README.md b/README.md
index 01c4a99007..173c45c047 100644
--- a/README.md
+++ b/README.md
@@ -9,22 +9,22 @@ The standard provides a basis for designing, building, and testing technical app
**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.**
-## Latest Stable Version - 4.0.2
+## Latest Stable Version - 4.0.3
-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 latest stable version is version 4.0.3 (dated October 2021), which can be found:
+* [OWASP Application Security Verification Standard 4.0.3 English (PDF)](https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf)
+* [OWASP Application Security Verification Standard 4.0.3 English (Word)](https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/docs_en/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.docx)
+* [OWASP Application Security Verification Standard 4.0.3 English (CSV)](https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/docs_en/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.csv)
+* [OWASP Application Security Verification Standard 4.0.3 (GitHub Tag)](https://github.com/OWASP/ASVS/tree/v4.0.3)
-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**.
+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 **5.0**.
-For information on changes between 4.0.1 and 4.0.2 of the standard, see [this wiki page](https://github.com/OWASP/ASVS/wiki/What-is-new-in-version-4.0.2) and for a full diff, see [this pull request](https://github.com/OWASP/ASVS/pull/780/files?file-filters%5B%5D=.md&file-filters%5B%5D=.py&file-filters%5B%5D=.sh&file-filters%5B%5D=.yml&file-filters%5B%5D=No+extension).
+For information on changes between 4.0.2 and 4.0.3 of the standard, see [this wiki page](https://github.com/OWASP/ASVS/wiki/What-is-new-in-version-4.0.3) and for a full diff, see [this pull request](https://github.com/OWASP/ASVS/pull/1104/files?file-filters%5B%5D=.md&file-filters%5B%5D=.py&file-filters%5B%5D=.sh&file-filters%5B%5D=.yml&file-filters%5B%5D=No+extension).
### 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.2 German (PDF)](4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-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))
@@ -47,11 +47,11 @@ ASVS requirement lists are made available in CSV, JSON, and other formats which
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:
+- The `` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.3 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-`.)
+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.3-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.3. (This could be summarized as `v-`.)
Note: The `v` preceding the version portion is to be lower case.