Recently I started using LAPSE+ for static code analysis and it kept on pointing java.sql.ResultSet.getString as an Information Leakage. The ResultSet is properly closed after its usage.

LAPSE+ does this only for ResultSet.getString() and ResultSet.getObject(). For example, ResultSet.getDate() is not taken as a vulnerability. This behavior confirms to this OWASP page, which indicates only those two getters in ResultSet as vulnerable.

I'm trying to figure out the reason behind this. Does it have something to do with Strings being immutable?

Though not the exact thing (due to confidentiality reasons), following is a sample code block that I'm concerned about:

ResultSet rs = null;

try {
 dbConnection = dataSource.getConnection();
 prepStmt = dbConnection.prepareStatement("SELECT NAME, DOB FROM CUSTOMERS WHERE ID=?");
 prepStmt.setInt(1, customerId);
 rs = prepStmt.executeQuery();
 //do something

 while (rs.next()) {
  String name = rs.getString(1);
  Date dob = rs.getDate(2);
  //do something
} catch (SQLException e) {
 //do something
} finally {
 if (rs != null) {
  try {
  } catch (SQLException e) {
   log.error("Database error. Could not close result set  - " + e.getMessage(), e);
  • Need more information. The linked OWASP article only indicates that you need to watch out for these methods. Could also use some code to see what you're doing with it. Commented Jan 10, 2016 at 5:12
  • Added a sample code block. I'm just trying to understand why even OWASP lists only getString and getObject methods. Thanks
    – drox
    Commented Jan 10, 2016 at 5:50
  • 8
    I haven't used LAPSE+, but any tool that reports something as vulnerable without telling or explaining why, is a piece of bantha poodoo. Commented Jan 10, 2016 at 6:13
  • 1
    I believe it's reporting that simply because those two getters are listed in the mentioned OWASP list. Then the question is why OWASP lists only those two rather than all the resultset getters.
    – drox
    Commented Jan 10, 2016 at 6:18
  • 4
    FWIW it's important to note that I would be very careful before using LAPSE+ for anything, the last release I can see is 2.8.1 from 2011 and the mailing list shows no activity since 2013 Commented Jan 10, 2016 at 11:48

2 Answers 2


The reasoning might have been that ResultSet.getString and RestulSet.getObject should return a valid result no matter what the underlying value is for the column you specify. So if there was an SQLi attack and column 1 is usually a string but is now some secret number you'll get still a valid result and thus leak information about that result. Whereas ResultSet.getDate will throw an exception if it can't parse the column as a date so no information would be leaked, other than it's an invalid value.

  • maybe prepared statements are already great for reduction in SQL Injection. Error detection in software technology is a thing & so is error correction in a very minimal data exposure. Commented Oct 26, 2016 at 6:13

In addition to jcopenha's answer, perhaps you could try using getString( "column label" ). If the table format changes and the column indexes are offset, if you use the labels (select name as n) then referencing with getString( "n" ) should ensure that you get 'n' back. More to the point, if you use a label convention that differs from table column naming convention the two should never overlap.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .