Removing use of "etc." from requirements to resolve #2600 (#2601)

* #2600

First try at #2600

* Further wording modifications

---------

Co-authored-by: Josh Grossman <[email protected]>

5.0/en/0x12-V3-Session-management.md

@@ -91,7 +91,7 @@ This section provides requirements to mitigate the risk posed by active sessions
 
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |
-| **3.7.1** | [MODIFIED, SPLIT TO 3.7.3, LEVEL L1 > L2] Verify that the application requires re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, other information used in account recovery, etc. | 2 | 306 |
+| **3.7.1** | [MODIFIED, SPLIT TO 3.7.3, LEVEL L1 > L2] Verify that the application requires re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery. | 2 | 306 |
 | **3.7.2** | [MODIFIED, MOVED FROM 3.3.4] Verify that users are able to view and (having re-entered login credentials) terminate any or all currently active sessions. | 2 | |
 | **3.7.3** | [ADDED, SPLIT FROM 3.7.1] Verify that the application requires re-authentication or secondary verification before performing highly sensitive transactions or operations. | 3 | 306 |
 

5.0/en/0x13-V5-Validation-Sanitization-Encoding.md

@@ -4,7 +4,7 @@
 
 This chapter focuses on the most common web application security weaknesses that are related to unsafe processing of untrusted data. This leads to a variety of technical vulnerabilities where the untrusted data gets interpreted using the syntax rules of the relevant interpreter.
 
-With modern web applications, it will always be best to use safer APIs such as parameterized queries, auto-escaping templating frameworks, etc. Otherwise, or carefully performed output encoding/escaping or sanitization will be critical to the security of the application.
+With modern web applications, it will always be best to use safer APIs such as parameterized queries, auto-escaping or templating frameworks. Otherwise, or carefully performed output encoding/escaping or sanitization will be critical to the security of the application.
 
 This chapter also talks about Input Validation which is a powerful defense in depth mechanism for protected against unexpected, dangerous content but should not be considered as a specific security control.
 
@@ -25,7 +25,7 @@ The "untrusted client" term here refers to client-side technologies that render
 
 ## V5.1 Input Validation
 
-Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases, external APIs, etc.
+Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases and external APIs.
 
 Properly implemented input validation controls, using positive allowlists and strong data typing, provide an important enforcement of business logic controls or functional expectations around the type of data that the app expects to receive. Business logic controls could be that a particular input should be a number which is less than 100. Functional expectations might be that a certain number should be below a certain threshold as the number governs how many times a particular loop should take place and a high number could lead to excessive processing and a potential denial of service condition.
 

5.0/en/0x17-V9-Communications.md

@@ -64,7 +64,7 @@ HTTP traffic between internal-facing services should also be encrypted, ideally
 
 ## V9.4 General TLS Security Guidance
 
-Use secure TLS configuration and up-to-date tools to review the configuration on a regular basis. While usage of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development, test, etc.) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and usage of separate TLS certificates in different environments should be employed if possible.
+Use secure TLS configuration and up-to-date tools to review the configuration on a regular basis. While usage of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development and test) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and usage of separate TLS certificates in different environments should be employed if possible.
 
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |

5.0/en/0x18-V10-Coding.md

@@ -14,8 +14,8 @@ This chapter also contains requirements to prevent the introduction of malicious
 | :---: | :--- | :---: | :---: |
 | **1.10.1** | [DELETED, NOT IN SCOPE] | | |
 | **1.10.2** | [MODIFIED, MOVED FROM 14.2.5, MERGED FROM 14.2.4, COVERS 12.3.6] Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | 2 | |
-| **1.10.3** | [ADDED, SPLIT FROM 14.2.6] Verify that application documentation highlights "risky" third party libraries which should include: libraries which perform operations which are dangerous from a security perspective, libraries which are poorly maintained, unsupported, or end of life, libraries which have historically had several significant vulnerabilities, etc. | 3 | 1061 |
-| **1.10.4** | [ADDED, SPLIT FROM 1.14.5] Verify that application documentation highlights parts of the application where "risky" operations are being performed. "Risky" in this context means those with a high likelihood of being dangerously exploited such as: deserialization of untrusted data, raw file parsing, direct memory manipulation, etc. | 3 | |
+| **1.10.3** | [ADDED, SPLIT FROM 14.2.6] Verify that application documentation highlights "risky" third party libraries which should include: libraries which perform operations which are dangerous from a security perspective, libraries which are poorly maintained, unsupported, or end of life and libraries which have historically had several significant vulnerabilities. | 3 | 1061 |
+| **1.10.4** | [ADDED, SPLIT FROM 1.14.5] Verify that application documentation highlights parts of the application where "risky" operations are being performed. "Risky" in this context means those with a high likelihood of being dangerously exploited such as: deserialization of untrusted data, raw file parsing or direct memory manipulation. | 3 | |
 | **1.10.5** | [ADDED, SPLIT FROM 14.2.1, COVERS 1.14.3] Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | 1 | |
 
 ## V10.1 Code Integrity

5.0/en/0x20-V12-Files-Resources.md

@@ -78,7 +78,7 @@ Applications must release system resources like database connections, open files
 
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |
-| **12.7.1** | [ADDED] Verify that the application proactively releases system resources, such as database connections, open files, threads, etc, when it finishes using them to prevent resource exhaustion. | 2 | 404 |
+| **12.7.1** | [ADDED] Verify that the application proactively releases system resources, such as database connections, open files and threads when it finishes using them to prevent resource exhaustion. | 2 | 404 |
 
 ## References
 

5.0/en/0x22-V14-Config.md

@@ -68,7 +68,7 @@ For example, hiding the version of server-side components does not fix the need
 | **14.3.3** | [MODIFIED] Verify that the application does not expose detailed version information of server-side components. | 1 | 200 |
 | **14.3.4** | [ADDED, SPLIT FROM 4.3.2] Verify that directory browsing is disabled unless deliberately desired. | 1 | 548 |
 | **14.3.5** | [ADDED, SPLIT FROM 4.3.2] Verify that the application does not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. | 1 | |
-| **14.3.6** | [GRAMMAR, MOVED FROM 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. | 1 | 552 |
+| **14.3.6** | [GRAMMAR, MOVED FROM 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 (.bak), temporary working files (.swp), compressed files (.zip, .tar.gz) and other extensions commonly used by editors should be blocked unless required. | 1 | 552 |
 
 ## V14.4 HTTP Security Headers
 

5.0/en/0x50-V50-Web-Frontend-Security.md

@@ -46,7 +46,7 @@ HTTP responses must include security headers to set rules to how browsers can se
 
 When accepting a request to sensitive functionality on the server side, we need to be sure it is initiated by the application itself or by a trusted party and has not been forged by an attacker.
 
-Sensitive functionality in this context could include accepting form posts for authenticated and non-authenticated users (such as an authentication request), state changing operations,  resource-demanding functionality (such as data export), etc.
+Sensitive functionality in this context could include accepting form posts for authenticated and non-authenticated users (such as an authentication request), state changing operations or resource-demanding functionality (such as data export).
 
 The key protections here are browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies. Another common protection is the CORS preflight mechanism. This mechanism will be critical for endpoints designed to be called from a different origin, but it can also be a useful request forgery prevention mechanism for endpoints which are not designed to be called from a different origin.
 
@@ -77,7 +77,7 @@ Rendering content or functionality in an incorrect context can lead to a wide va
 
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |
-| **50.6.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-\*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | 1 | |
+| **50.6.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-\*, indicate it is the correct context, using the "Content-Security-Policy: sandbox" header or using the "Content-Disposition: attachment header". | 1 | |
 | **50.6.2** | [ADDED, SPLIT FROM 5.3.3] Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | 1 | |
 
 ## V50.7 External Resource Integrity