SQL Injection Risk with JDBC Statement
Fast recall
Quick revision
Core answer
Whether you understand SQL injection from concatenation and the PreparedStatement fix.
Building SQL by string concatenation and trusting input is harmless.
Explain that parameters are bound as data, so the query structure can't be altered.
Interview-ready guide
Interview answer
Building WHERE username = ' + input + ' lets a quote close the literal and add a new predicate. Writing WHERE username = ? and calling setString gives the input one value position, so ' OR '1'='1 cannot become an OR expression. The driver can implement binding through different protocols; the JDBC semantic boundary is what matters.
SQL Injection Risk with JDBC Statement
Direct Answer
When untrusted text is concatenated into SQL, it can change the query grammar. PreparedStatement fixes value positions with placeholders and binds values through setter methods, so quotes/operators in those values remain data. This protection does not require a literal promise that the driver sends two separate network messages, and it does not cover table names or other concatenated structural fragments.
Common Mistakes & Pitfalls
Building SQL by string concatenation and trusting input is harmless.
Check your understanding
Answer these without looking back at the article.
- What are the three types of statements in JDBC?
- What is the performance benefit of PreparedStatement over Statement?
- How does PreparedStatement's precompilation improve performance?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.