for each requirement - the usage of "must vs should" in the main condition of the requirement

[elarlang]

In ASVS we only have requirements - it means a "must have" situation, but we have 38 requirements that contain the word "should".

There is a need to review those:

• is it actually a requirement or is it a recommendation
• if the word "should" is in the main condition, it must be changed to "must"

https://datatracker.ietf.org/doc/html/rfc2119

---

If there is agreement, we can PR it in. If it requires a further discussion, then issue per requirement (or at least chapter).

#	Description	Level	#v5.0.be
1.2.4	[MODIFIED, COVERS 5.3.5] Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This should also be considered when writing stored procedures.	1	v5.0.be-5.3.4
1.2.9	[ADDED] Verify that the application is protected against CSV and Formula Injection. The application should follow the escaping rules defined in RFC4180 2.6 and 2.7 when exporting CSV files. The application should escape special characters including '=', '+', '-', '@' '\t' (tab) and '\00' (null character) using a single quote, if they are the first character in a field, when exporting CSV files and other spreadsheet formats such as xls, xlsx, odf.	3	v5.0.be-5.3.11

• 1.2.4 - it can stay, it can be changed, but the last part can also be removed entirely and nothing happens (PR Clarify wording of 1.2.4 #2809)
• 1.2.9 - in referenced spec, 2.6 is "should" and 2.7 is "must" (v5.0.be-5.3.11 / 1.2.9 - csv and formula injection wording #2811, PR Clarify wording in 1.2.9 #2810 )

---

#	Description	Level	#v5.0.be
2.2.1	[MODIFIED, MOVED FROM 5.1.3, SPLIT FROM 5.1.4, MERGED FROM 11.1.5, COVERS 13.2.2, 13.3.1] Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allowed list of values, patterns or ranges or alternatively be based on comparing to an expected structure or logical limit, according to pre-defined rules. For L1 this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input.	1	v5.0.be-11.3.1

• 2.2.1 - I think this "should" can stay, but the sentence itself requires some work - it is hard to understand, where some "or" starts or ends. (Clarify 2.2.1 / v5.0.be-11.3.1 wording #2812, PR update for 2.2.1 / v5.0.be-11.3.1, closes #2812 #2815)

---

#	Description	Level	#v5.0.be
3.1.1	[ADDED] Verify that application documentation states the expected security features that browsers using the application should support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms). It should also define how the application must behave when some of these features are not available (such as warning the user or blocking access).	3	v5.0.be-1.50.1

• 3.1.1 - I would say this "should" is a "must" (3.1.1, should > must #2813)

---

#	Description	Level	#v5.0.be
5.2.2	[MODIFIED, MOVED FROM 12.2.1] Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1 this can focus just on files which are used to make specific business or security decisions. For L2 and up, this should apply to all files being accepted.	1	v5.0.be-12.1.5

• 5.2.2 - it is a must (5.2.2, should > must #2814)

---

#	Description	Level	#v5.0.be
6.1.1	[ADDED, SPLIT FROM 2.2.1] Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation should make clear how these controls are configured and prevent malicious account lockout.	1	v5.0.be-1.2.6
6.1.3	[MODIFIED, SPLIT TO 2.2.11, COVERS 1.2.3] Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which should be consistently enforced across them.	2	v5.0.be-1.2.4
6.2.5	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.	1	v5.0.be-2.1.9
6.3.8	[ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection.	3	v5.0.be-2.2.8
6.5.5	[MODIFIED, MOVED FROM 2.7.2, MERGED FROM 2.8.1] Verify that out-of-band authentication requests, codes, or tokens, as well as time-based, one-time passwords (TOTPs) have a defined lifetime. For out of band this should be 10 minutes and for TOTP this should be as short as possible, usually 30 seconds.	2	v5.0.be-2.6.5
6.8.1	[ADDED] Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). Usually, the application should register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP.	2	v5.0.be-2.11.1

All in #2816

• 6.1.1 - must (from L2?)
• 6.1.3 - must?
• 6.2.5 - must (Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.)
• 6.3.8 - must?
• 6.5.5 - "should be 10 minutes" > "must be less than 10 minutes"; from TOTP remove "this should be as short as possible" and just keep "must be less than 30 seconds"?
• 6.8.1 - @randomstuff - is this "should" a "must"?

---

#	Description	Level	#v5.0.be
7.1.3	[ADDED] Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other condition that should require re-authentication.	2	v5.0.be-1.3.3
7.2.2	[MODIFIED, MOVED FROM 3.5.2, LEVEL L2 > L1] Verify that the application uses either self-contained or reference tokens for session management. Static API secrets and keys should be avoided.	1	v5.0.be-3.1.3

• 7.1.3 - must? Clarify 7.1.3 #2818
• 7.2.2 - must, I'm not sure the last sentence adds anything to the requirement or why we need it Clarify 7.2.2 (previouly v5.0.be-3.1.3, v4.0.3-3.5.2) #2817

---

#	Description	Level	#v5.0.be
8.1.3	[ADDED] Verify that authorization documentation defines controls that incorporate changes to a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization. These changes should be detected both when the consumer tries to start a new session or during an existing session.	3	v5.0.be-1.4.6
8.3.2	[ADDED] Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they should no longer be able to do so and revert the change. Note that this would be unable to mitigate information leakage.	3	v5.0.be-4.2.4
8.3.3	[ADDED] Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service should use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions.	3	v5.0.be-4.2.5

• 8.1.3 - must?
• 8.3.2 - should in this context is ok, the sentence itself is questionable
• 8.3.3 - must
• See: Clarify should > must in v8 #2819

---

#	Description	Level	#v5.0.be
9.1.2	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.	1	v5.0.be-52.1.2

• 9.1.2 - must, must, must
• v9, v10, v11 - should > must #2820

---

#	Description	Level	#v5.0.be
10.3.2	[ADDED] Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they should be part of the decision.	2	v5.0.be-51.3.3
10.7.2	[ADDED] Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application and the lifetime of these authorizations.	2	v5.0.be-51.7.2

• 10.3.2 - must
• 10.7.2 - should
• v9, v10, v11 - should > must #2820

---

#	Description	Level	#v5.0.be
11.1.2	[MODIFIED] Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It should also document where keys can and cannot be used in the system and also the types of data which can and cannot be protected using the keys.	2	v5.0.be-1.6.4
11.2.2	[MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available.	2	v5.0.be-6.2.4
11.4.2	[MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4, COVERS 2.5.3] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging.	2	v5.0.be-6.6.2
11.6.2	[ADDED] Verify that industry-proven cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This should prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks.	3	v5.0.be-6.7.1

• 11.1.2 - ?
• 11.2.2 - should?
• 11.4.2 - should?
• 11.6.2 - should?
• v9, v10, v11 - should > must #2820

---

#	Description	Level	#v5.0.be
12.1.1	[MOVED FROM 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.	1	v5.0.be-9.4.2
12.4.2	[MODIFIED, MOVED FROM 9.2.1, COVERS 1.9.2] Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.	2	v5.0.be-9.3.2
12.4.3	[MODIFIED, MOVED FROM 2.2.5] Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as mTLS, should be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security.	3	v5.0.be-9.3.3

• 12.1.1 - "should be preferred" or "must be preferred" probably are the same
• 12.4.2 - must, to be in sync with previos part
• 12.4.3 - must?
• V12, V13, V13, should > must #2822

---

#	Description	Level	#v5.0.be
13.1.1	[MODIFIED, MOVED FROM 1.1.5] Verify that all communication needs for the application are documented. This should include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect.	2	v5.0.be-1.14.7
13.1.3	[ADDED] Verify that where the application connects to separate system resources or services (such as database connections, open files and threads), each has a documented resource release and connection failure strategy which includes how fast the connection times-out and whether there is a retry strategy. This is to prevent resource exhaustion. External connections in synchronous HTTP request-response scenarios should fail fast without any retry, to avoid reaching the maximum possible connections.	3	v5.0.be-1.14.9
13.2.1	[MODIFIED, MOVED FROM 2.10.1, MERGED FROM 1.2.2] Verify that communications between backend application components which don't support the application's standard user session mechanism, including APIs, middleware and data layers, are authenticated. Authentication should use individual service accounts, short-term tokens or certificate based authentication and not unchanging credentials such as passwords, API keys or shared accounts with privileged access.	2	v5.0.be-14.7.1
13.3.1	[MODIFIED, MOVED FROM 6.4.1, MERGED FROM 1.6.2, 2.10.4, SPLIT FROM 2.9.1, COVERS 2.10.3, 2.8.2] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For a L3 application, this should involve a hardware-backed solution such as an HSM.	2	v5.0.be-14.8.1
13.4.6	[MODIFIED] Verify that deployed environments are short lived and frequently redeployed to a "known good" but updated state. Alternatively, long lived environments should use some form of "drift prevention" to ensure that deployed configurations are not changed to an insecure state.	3	v5.0.be-14.1.5
13.5.5	[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.	3	v5.0.be-14.3.5

• 13.1.1 - must
• 13.1.3 - should
• 13.2.1 - must
• 13.3.1 - ?
• 13.4.6 - "should use some form of" - is testable?
• 13.5.5 - must, grammar > modified in mapping file
• V12, V13, V13, should > must #2822

---

#	Description	Level	#v5.0.be
14.1.2	[MODIFIED, SPLIT TO 8.1.9, COVERS 8.3.7] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.	2	v5.0.be-1.8.2
14.2.4	[ADDED, SPLIT FROM 1.8.2] Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level.	2	v5.0.be-8.1.9
14.2.5	[ADDED] Verify that caching mechanisms are configured to only cache responses which have the correct content type and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when an non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks.	3	v5.0.be-8.1.7
14.2.6	[ADDED] Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the full data is absolutely required, it should be masked in the user interface unless the user specifically views it.	3	v5.0.be-8.1.10
14.3.1	[MODIFIED] Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The "Clear-Site-Data header" may be able to help with this but the client-side should also be able to clear up if the server connection is lost.	1	v5.0.be-8.2.3

• 14.1.2 - must, must

• 14.2.4 - must

• 14.2.5 - should, should

• 14.2.6 - must?

• V12, V13, V13, should > must #2822

• 14.3.1 - "without interruption the client-side must be ablo to"

• Clarify 14.3.1 #2821

---

#	Description	Level	#v5.0.be
15.1.3	[ADDED] Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This should include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application.	2	v5.0.be-1.10.6
15.1.4	[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	v5.0.be-1.10.3
15.3.10	[MODIFIED, MOVED FROM 10.3.1, LEVEL L1 > L3] Verify that, if the application has an auto-update feature, updates should be digitally signed, with the digital signature being validated before installing or executing the update.	3	v5.0.be-10.4.10

• 15.1.3 - must
• 15.1.4 - should
• 15.3.10 - it is the main condition, must
• V15, V16, should > must #2823

---

#	Description	Level	#v5.0.be
16.3.1	[MODIFIED] Verify that all authentication operations are logged including both successful and unsuccessful attempts. Additional metadata such as type of authentication or factors used should also be collected.	2	v5.0.be-7.2.1
16.5.4	[MODIFIED] Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that should go to log files and also to ensure that an error does not take down the entire application process, leading to a loss of availability.	3	v5.0.be-7.4.3

• 16.3.1 - should
• 16.5.4 - must? get rid of "both" or "also" from 2nd sentence
• V15, V16, should > must #2823

---

#	Description	Level	#v5.0.be
17.3.1	[ADDED] Verify that the signalling server is able to continue processing incoming signalling messages during a flood attack. This should be achieved by implementing rate limiting at the signalling level.	2	v5.0.be-53.3.1

• 17.3.1 - ? Josh edit: I think "should" is best here.

[elarlang]

(moved the content to initial issue)

[randomstuff]

@elarlang, For 6.8.1, this is a "should" in the sense that there are other correct implementations. This "should" is somewhat redundant with the usage of "Usually": "Usually […] must" can work as well, I guess.