Thanks, @Alexandre_Gigleux ,
Thanks for the list. Ok, looks like input validation is only supported where lack of would lead to a vulnerability, correct?
We do have a standard requirement to validate all input, thus checking for vulnerabilities only is not sufficient. Avoiding errors in subsequent process steps is also a clear goal. I think this is best practice, also looking at Input Validation - OWASP Cheat Sheet Series (and yes, injection errors are not just a matter of input validation but also of improper output encoding matching the target interface requirements.).
In other words, how can I enforce input validation practices with SonarQube? I noticed Code smells regarding "Validation" methods and Help SonarCloud with understanding the usage of untrusted and tainted input - #4 by Alexandre_Gigleux, but I am not looking for customization yet but for default behaviour. I created a ZipController in my test code, but it doesn´t yield a violation, even though both the path and zip are declared as input of a method marked [HttpGet].
What exactly are you using to tag data as untrusted input? And I´d definitley think, using non-validated data for any other interface should be considered bad practice, no matter whehter the other interface is towards user output, framework, operating system, database or some other interface.
Thanks, Joachim