Defenses Against SQL Injection – Java Backend Security Guide

Direct Answer

Use parameter binding for every data value. For query structure that cannot be bound—such as a selected column or sort direction—map the request to a small set of server-defined fragments. Add least-privilege database accounts, safe stored procedures and ORM use, restricted error details, dependency patching, monitoring, and tested backups. A WAF can detect or block some probes but is not a substitute for fixing query construction.

Code Example

// You CANNOT bind a column name with ?. Validate it against an allowlist.
private static final Set<String> SORTABLE =
    Set.of("name", "price", "created_at"); // known-good columns only

public List<Product> search(String term, String sortColumn) {
    if (!SORTABLE.contains(sortColumn)) {
        throw new IllegalArgumentException("Invalid sort column"); // reject
    }
    // term is bound; sortColumn is from a trusted allowlist, not raw input
    String sql = "SELECT * FROM products WHERE name LIKE ? ORDER BY " + sortColumn;
    try (PreparedStatement ps = connection.prepareStatement(sql)) {
        ps.setString(1, "%" + term + "%");
        // ... map ResultSet to Product ...
    }
    return List.of();
}

Values use ?; the one thing that can't be a parameter (the column name) is constrained to a fixed allowlist.

Common Mistakes & Pitfalls

• "Sanitize input" as the whole answer: parameterization is the real fix; validation is a supporting layer.
• Blocklisting characters: stripping quotes or -- is fragile and bypassable via encodings. Prefer allowlists.
• Relying on a WAF: useful for detection, but it can be evaded — never your only control.
• Over-privileged DB user: running the app as a DB admin means any injection can drop tables. Use least privilege.
• Stored procedures that concatenate: a proc that builds dynamic SQL from input is just as injectable.