SQL Injection Explained – Java Backend Security Interview
Fast recall
Quick revision
Core answer
OR '1'='1. Bind data values with PreparedStatement, JPA parameters, or an equivalent API; allowlist any identifiers that cannot be bound. Injection is A05 in OWASP Top 10:2025 and was A03 in 2021.Interview-ready guide
Interview answer
SQL injection occurs when untrusted input becomes part of SQL syntax instead of remaining a data value. A classic example is concatenating a username inside quotes. An attacker can close the quote and add a condition such as OR '1'='1, changing what the database evaluates. The exact result depends on the query, driver, database, and account privileges.
The primary defense is parameter binding. With PreparedStatement, the SQL contains placeholders and the input is supplied through setter methods. JPA named or positional parameters provide the same separation for value positions. The input can contain quotes and SQL-looking text, but it remains the value of that parameter.
Identifiers and keywords, such as a requested sort column or direction, cannot normally be parameters. Map those from a small allowlist of supported choices rather than concatenate arbitrary request text. Server-side validation, least-privilege database accounts, safe errors, and monitoring provide extra layers. Injection is A05 in OWASP Top 10:2025; A03 is the 2021 number.
SQL Injection Explained – Java Backend Security Interview
Direct Answer
SQL injection occurs when untrusted input changes the structure or meaning of a SQL statement. String concatenation is the common cause. For example, a quoted login value can close the string and add a condition such as OR '1'='1. Bind data values with PreparedStatement, JPA parameters, or an equivalent API; allowlist any identifiers that cannot be bound. Injection is A05 in OWASP Top 10:2025 and was A03 in 2021.
Common Mistakes & Pitfalls
- Treating escaping as the fix: manually escaping quotes is fragile and misses encodings and numeric contexts. Parameterized queries are the real defense.
- Assuming numbers are safe:
WHERE id = " + idis just as injectable as a string field — an attacker can append; DROP TABLE users. - Trusting only client-side validation: a JavaScript check is bypassed by any HTTP client (curl, Postman). Validation must happen on the server.
- Thinking ORMs make you immune: native queries and string-built JPQL in Spring Data can still be injectable (covered in a separate question).
Check your understanding
Answer these without looking back at the article.
- How exactly does a PreparedStatement stop the OR 1=1 trick from working?
- If you use Spring Data JPA, are you automatically safe from SQL injection?
- What is a blind SQL injection and how does it differ from a normal one?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.