Fix SQL Injection (Legacy & Modern) in Spring Boot

SQLi remains the king of critical vulnerabilities. In Spring Boot, it typically manifests in legacy JDBC implementations or 'creative' JPQL queries. If you are building strings to query your database, you are doing it wrong. Stop trusting user input and start using the framework's built-in protections to enforce a strict boundary between code and data.

The Vulnerable Pattern

// Legacy JDBC Vulnerability (String Concatenation)
public List> getInsecureUser(String id) {
    String sql = "SELECT * FROM users WHERE id = '" + id + "'";
    return jdbcTemplate.queryForList(sql);
}
// Modern JPA Vulnerability (Dynamic JPQL)
@Query(“SELECT u FROM User u WHERE u.username = ’” + username + ”’”)
User findByUsernameUnsafe(String username);

The Secure Implementation

The vulnerability stems from the execution of user-controlled strings as SQL commands. By concatenating input, an attacker can break out of the string literal using characters like ' or -- to manipulate logic (e.g., ' OR 1=1). The fix is 'Parameterization'. PreparedStatements (underlying JDBC) and Named Parameters (JPA) send the query template and the data to the database engine separately. The engine treats the input strictly as data, never as executable code. For modern Spring development, rely on Spring Data Repository method naming conventions (findByX), which are parameterized and safe by design.

// Legacy JDBC Fix (Parameterized Query)
public List> getSecureUser(String id) {
    String sql = "SELECT * FROM users WHERE id = ?";
    return jdbcTemplate.queryForList(sql, id);
}
// Modern JPA Fix (Named Parameters)
@Query(“SELECT u FROM User u WHERE u.username = :username”)
User findByUsernameSafe(@Param(“username”) String username);
// The Pro Way (Spring Data Derived Queries)
Optional findByUsername(String username);