SQL Injection — How It Works and JPA Prevention
Fast recall
Quick revision
Core answer
@Param), Criteria API, or Specifications for dynamic queries. Add defense in depth: input validation with @Valid, least-privilege DB users (no DDL), and SpotBugs Find Security Bugs in CI to catch concatenation patterns automatically.Whether the candidate understands the root cause of SQL injection and knows idiomatic JPA prevention techniques.
Saying 'JPA is safe by default' without understanding that native @Query with string concatenation is still vulnerable.
Mention input validation as defense-in-depth, demonstrate awareness of second-order injection, and reference OWASP A03.
Interview-ready guide
Interview answer
Safe patterns
@Query("... WHERE u.email = :email")with@Param("email")— JPQL named parameter; Hibernate uses prepared statement- Derived methods (
findByEmail(String)) — always parameterized CriteriaBuilder.equal(root.get("email"), email)— Criteria API; always parameterized
Risky patterns
@Query("... WHERE u.role = '" + role + "'")— string concatenation in JPQL; never@Query(value = "... WHERE name = '" + name + "'", nativeQuery = true)— native + concat; highest risk- Dynamic
ORDER BY " + column— parameterization doesn't apply to identifiers; whitelist columns
Second-order injection
- User submits
'; DROP TABLE orders; --as display name - Stored safely (parameterized INSERT)
- Later, admin query builds SQL via concatenation using stored name — payload executes
Defense in depth
- Parameterized queries — always
- Input validation — reject unexpected chars early
- Least privilege — app DB user has no
DROP/ALTER
Detection
- SpotBugs Find Security Bugs in CI
- Hibernate SQL logging at TRACE
- Manual grep for
nativeQuery = trueand string concatenation in queries
SQL Injection — How It Works and JPA Prevention
Direct Answer
SQL injection occurs when untrusted user input is concatenated into a SQL query, letting attackers manipulate query logic. JPA is not automatically safe — JPQL with named parameters and Spring Data derived methods are safe, but @Query(nativeQuery = true) with string concatenation is fully exploitable. Use named parameters (@Param), Criteria API, or Specifications for dynamic queries. Add defense in depth: input validation with @Valid, least-privilege DB users (no DDL), and SpotBugs Find Security Bugs in CI to catch concatenation patterns automatically.
Common Mistakes & Pitfalls
Saying 'JPA is safe by default' without understanding that native @Query with string concatenation is still vulnerable.
Check your understanding
Answer these without looking back at the article.
- Can Hibernate's JPQL be vulnerable to injection even with named parameters?
- What is second-order SQL injection and how would you detect it?
- How would you scan a Spring Boot codebase for potential SQL injection vulnerabilities?
- How do you safely parameterize dynamic ORDER BY clauses in JPA?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.