SQL Injection Prevention Techniques

Direct Answer

Bind every data value through PreparedStatement, JdbcTemplate parameters, or ORM query parameters. For SQL structure that cannot be bound—table names, column names, sort direction—map a small allow-list of public choices to fixed SQL fragments. Add least-privilege database roles, safe error handling, code review, and query tests as defense in depth. Escaping and WAF filtering are not substitutes for parameterization.

Code Example

// ? cannot parameterize a column name, so validate against an allow-list
String sortCol = request.getParameter("sort");      // e.g. "name"
List<String> allowed = List.of("name", "created_at", "email");
if (!allowed.contains(sortCol)) throw new IllegalArgumentException("bad sort");

String sql = "SELECT id, name FROM users ORDER BY " + sortCol;  // safe: from allow-list
try (PreparedStatement ps = con.prepareStatement(sql)) {
    ResultSet rs = ps.executeQuery();
}
// values still use ? + setXxx; only validated identifiers are concatenated

Common Mistakes & Pitfalls

• Blacklisting bad words: attackers encode/bypass — use allow-lists instead.
• Manual escaping as primary defense: fragile; parameterize instead.
• Over-privileged DB account: one injection then becomes catastrophic.
• Concatenating inside a stored procedure: dynamic SQL there is still vulnerable.