Clarification: 1.3.2 "Sanitized"

1.3.2 Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed.

• Sanitization can lower the chances of an attack succeeding, but it rarely removes the risk completely. Trying to sanitize executable logic is especially risky and often doesn’t work well. In such cases, validation and strict allowlists are the safer choice.
• The requirement mixes client-side JavaScript concerns with server-side Java expression evaluation into one vague rule, without clarifying the execution context, programming language, or threat model.
• Sanitization means removing or modifying dangerous input, but it doesn’t guarantee the input will be interpreted safely. AS the application cannot safely “sanitize” arbitrary user input and then pass it to a code interpreter. In dynamic code execution contexts, sanitization can give a false sense of security. A safer approach is to use strict allowlists or context-limited variables.
• If the term “sanitized” here actually means strict, context-specific allowlisting and tokenization (and not just generic escaping or string cleaning), that needs to be stated clearly, because it’s not obvious to everyone.

Start by reading the raw .md source for requirement 1.3.2 in the ASVS 5.0 tree, rather than its derived formats. Review how the requirement describes JavaScript, Spring Expression Language, sanitization, and allowlisting; it is done when the wording clearly defines the execution context, threat model, and intended safety guidance.