Rule java:S2095 (“Resources should be closed”) is parameterizable and allows one to add an exception list: a set of classes that won’t trigger the rule.
I’d like something similar for rule java:S2077 or whatever its equivalent is. (I saw old messages saying it was deprecated so don’t know if it’s been replaced by something else, but S2077 is the only thing that comes up when I type SQL into the rule search box while the language filter has been set to Java.)
We have a bunch of code where there’s a line like:
String stmt = “SELECT " + Foo.bar() + " FROM ?”;
and then stmt is used in a preparedStatement. SonarQube can’t tell that foo.bar() is safe so flags the line as a potential injection path.
(At least I assume that’s what’s going on – correct me if I’m wrong. I’ve determined experimentally that the hotspot isn’t triggered if the parameter to preparedStatement() is a String constant – even if it is made by adding a few literals or static String constants together. Does SQ go beyond that in trying to determine whether a given prepared statement is safe?)
So if we know that class Foo is immune to injection pathways (because all its strings are internal) then it would be great to add Foo to an exception so it won’t mark this statement a hotspot.
Of course, this exceptioning should work on an “and” basis, so even if we add Foo to the exception list, we’d still want something like
String stmt = "SELECT " + Foo.bar() + " FROM " + couldBeUserInput;
to be flagged.
Now, like I said above, SQ is clearly doing some flow analysis, because, while it is flagging a call to preparedStatement(), it is tracking the String parameter to that constructor back to the statement that creates that String.
I called api/hotspots/show to see what I could find about a particular hotspot, and it only gives the line number of the call to preparedStatement(). If it would also give the line number of the statement that creates the String, I could do the analysis in a script, in lieu of the feature I’m requesting here.