SQL Injection Edge Cases with PreparedStatement
Fast recall
Quick revision
Core answer
Whether you know PreparedStatement only protects bound values, not concatenated SQL.
Believing any use of PreparedStatement is automatically safe.
Identify identifier injection (ORDER BY/column) and the allow-list fix.
Interview-ready guide
Interview answer
If the API accepts sort=name, map it to the trusted fragment name ASC. If it accepts sort=created, map to created_at DESC. Never concatenate the raw value. For ids, build IN (?, ?, ?) from the count and bind each id; the placeholders are fixed syntax and ids remain data. Cap list size to protect query planning and database limits.
SQL Injection Edge Cases with PreparedStatement
Direct Answer
PreparedStatement protects only values bound to placeholders. It cannot bind table names, column names, operators, SQL keywords, or sort direction. Concatenating untrusted structure before prepareStatement remains injectable. Map each supported public option to a fixed internal fragment, and generate a variable IN list with one placeholder per value or a database-supported collection technique.
Common Mistakes & Pitfalls
- Concatenating any input into the SQL while using a PreparedStatement.
- Trying to bind an identifier with
?— it doesn't work; allow-list it. - Assuming PreparedStatement = safe regardless of construction.
- Building dynamic WHERE clauses from raw input instead of fixed fragments.
Check your understanding
Answer these without looking back at the article.
- What is SQL injection and how does it work?
- How does PreparedStatement prevent SQL injection in JDBC?
- What are other SQL injection prevention techniques besides PreparedStatement?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.