SQL Injection in Spring Boot (2026): Real Vulnerabilities, Prevention & Testing

SQL injection was first documented in 1998. It appeared on the first OWASP Top 10 in 2003. Injection remains one of the most repeatedly tested and disclosed application security classes in OWASP datasets. I audit production Spring Boot APIs regularly. It is still there. Here is why, and exactly what to do about it.

1. The Persistence of SQL Injection: 2026 Data

Before the code, sit with these numbers. They explain why this article still needs to exist.

The uncomfortable part is not the scale. It is what the numbers imply. Parameterised queries have existed since the 1990s. Every major Java framework warns against string concatenation in SQL. And the vulnerability is still in production code reviewed by experienced engineers in 2026.

The reason is not ignorance. It is that the unsafe pattern is faster to write, frequently autocompleted by AI tools trained on older codebases, and easy to miss in code review when the rest of the code looks correct.

2. How AI Coding Assistants Reintroduce SQL Injection Bugs

This is the part nobody wants to say out loud. AI coding assistants — Copilot, Cursor, ChatGPT — are trained on billions of lines of public code. A significant portion of that code predates modern security practices. When you ask an assistant to write a search endpoint in Spring Boot, there is a real chance it autocompletes a concatenated query because that pattern appears frequently in its training data.

I have seen this repeatedly in code reviews over the past year. A junior engineer accepts a suggestion, the reviewer trusts the tool, the PR merges. Nobody ran the query against a security linter. Nobody sent a payload like ' OR '1'='1 .

3. Blind SQL Injection and Second-Order SQL Injection in Java — Real Examples

The classic ' OR '1'='1 attack in a login form is mostly caught by WAFs and input scanners today. The attacks that still succeed in 2026 are subtler.

Second-Order SQL Injection in Java

The payload is stored safely during one operation. It fires during a completely different one. Input validation passes at the entry point — the value looks clean. The injection happens when another query reads it back and uses it without parameterisation.

Second-order SQLi — stored at registration, fires in audit log query

-- Step 1: User registers with username: admin'--
-- Input is correctly sanitised at insert time. No injection yet.
INSERT INTO users (username) VALUES ('admin''--');  -- stored safely
-- Step 2: Admin panel queries audit log using stored username
-- Developer writes this query without considering stored payload content:
String query = "SELECT * FROM audit_log WHERE username = '" + user.getUsername() + "'";
-- Expands to: SELECT * FROM audit_log WHERE username = 'admin'--'
-- The -- comments out everything after it. Attacker controls execution.

Blind SQL Injection Example — Boolean and Time-Based

No error message. No visible output. Attackers infer database structure from the application's behaviour — response time differences or subtle response body changes. Tools like sqlmap automate this extraction using boolean and time-based inference, reconstructing schema and data without triggering a single visible error.

Blind SQLi — no error needed, behaviour reveals the vulnerability

-- Boolean-based: attacker compares two responses
GET /api/users?id=1 AND 1=1    -- TRUE  → normal response
GET /api/users?id=1 AND 1=2    -- FALSE → different response
-- Different responses = injectable, even with no error message shown
-- Time-based: 5-second delay confirms blind injection on MSSQL
GET /api/users?id=1; IF(1=1) WAITFOR DELAY '0:0:5'--
-- Attacker then extracts data character by character using IF conditions

"We suppress error messages" is not a defence. Blind injection does not need your error messages.

OWASP continues to list injection among the most critical application security risks precisely because modern ORM layers do not eliminate unsafe query construction automatically. Source: OWASP A03:2021 — Injection · owasp.org .

4. Spring Boot SQL Injection Vulnerabilities Developers Miss

The assumption that "we use Spring Data JPA, so we are safe" is one of the most dangerous beliefs a Java team can hold. It is partially true. Partial safety breeds complacency.

In plain JDBC , the rule is clear: PreparedStatement always, Statement never. PreparedStatement compiles the query structure first, then binds the parameter separately — user input can never alter the query structure regardless of its content. Where teams go wrong is when they move to higher-level abstractions — JPA Repository , EntityManager , dynamic JPQL, QueryDSL — and assume the framework handles it unconditionally.

Real SQL Injection Example in Spring Boot — Native Query Concatenation

Java · VULNERABLE — @Query with nativeQuery=true bypasses Hibernate protection

// BAD — native query with concatenation. Hibernate does NOT protect you here.
@Query(value = "SELECT * FROM users WHERE role = '" + role + "'",
nativeQuery = true)
List<User> findByRole(String role);
// role = "admin' OR '1'='1" → full table dump
// GOOD — named parameter binding. Safe regardless of input content.
@Query(value = "SELECT * FROM users WHERE role = :role", nativeQuery = true)
List<User> findByRole(@Param("role") String role);

How to Prevent SQL Injection in Hibernate — Dynamic JPQL

Java · VULNERABLE — dynamic JPQL string building

// BAD — JPQL is also injectable when built dynamically
public List<User> search(String field, String value) {
String jpql = "SELECT u FROM User u WHERE u." + field + " = '" + value + "'";
return em.createQuery(jpql, User.class).getResultList();
}
// GOOD — JpaSpecificationExecutor (type-safe, no string building)
// GOOD — QueryDSL BooleanExpression (injection structurally impossible)
// BooleanExpression expr = user.name.eq(value); // QueryDSL — cannot inject

Criteria API Misuse — How cb.literal() Reintroduces Injection

Java · Criteria API — cb.literal() inlines value as string literal

// BAD — cb.literal() with user input inlines the value directly
Predicate p = cb.equal(root.get("status"), cb.literal(userInput));
// GOOD — cb.parameter() binds separately, same as PreparedStatement
ParameterExpression<String> param = cb.parameter(String.class, "status");
Predicate p = cb.equal(root.get("status"), param);
query.setParameter("status", userInput);

PreparedStatement vs Statement — SQL Injection Side-by-Side Fix

@GetMapping("/users")
public List<User> getUsers(
@RequestParam String role) {
String q = "SELECT * FROM users"
+ " WHERE role = '"
+ role + "'";
return em
.createNativeQuery(q, User.class)
.getResultList();
// role="admin' OR '1'='1"
// → dumps entire table
// → no error shown to caller
}

@GetMapping("/users")
public List<User> getUsers(
@RequestParam
@Pattern(regexp="^[A-Z_]{3,20}$")
String role) {
TypedQuery<User> q = em.createQuery(
"SELECT u FROM User u "
+ "WHERE u.role = :role",
User.class);
return q
.setParameter("role", role)
.getResultList();
// Two layers: validation first,
// then parameterised binding.
}

5. SQL Injection Prevention Checklist for Java Teams

Use this as a PR review checklist. Every item maps to a real vulnerability pattern from the sections above.

• Zero string concatenation in SQL, JPQL, or native queries — named parameters everywhere Core rule
• Plain JDBC code uses PreparedStatement exclusively — no Statement with user input JDBC
• Bean Validation ( @Pattern , @Size , @NotBlank ) on every user-supplied query parameter JSR 380
• Native @Query(nativeQuery=true) uses :namedParams — never string building Hibernate
• Dynamic JPQL built only via Criteria API or JpaSpecificationExecutor — no manual string construction Spring Data
• Sort/filter parameters validated against an explicit field allowlist before query construction Dynamic queries
• Stored data treated as untrusted when read back — prevents second-order injection Second-order
• Database user has minimum permissions: SELECT / INSERT / UPDATE only — no DROP / TRUNCATE Least privilege
• Semgrep ( java.sql.injection family) or SonarQube in CI — catches AI autocomplete regressions automatically CI/CD
• Error responses never include raw SQL error text or stack traces Error handling
• WAF rules applied at gateway — as a third layer, never as the only layer Defence in depth

6. SQL Injection Testing Payloads You Should Run Before Release

Reading about SQL injection vulnerabilities is not the same as knowing your endpoints are clean. This is the testing sequence I run before any new API endpoint reaches production.

Step 1 — Format the query, inspect for concatenation

Before sending payloads, format the raw SQL. Concatenation risks that are invisible in compressed one-liners become obvious when the query is structured. A + operator next to a variable is a red flag that deserves investigation before any payload test.

Step 2 — SQL Injection Testing Payloads for REST Endpoints

Send these as JSON field values via any REST client. Watch response codes and bodies carefully. A 500 with SQL error text is a confirmed vulnerability. A 400 with a validation message means your input layer is working. A 200 with an unexpectedly large result set is a red flag.

SQL injection testing payloads — send as JSON body fields

// Test 1 — basic quote (confirms the field reaches SQL)
{ "userId": "1'" }
// Test 2 — tautology (classic table dump attempt)
{ "username": "admin' OR '1'='1" }
// Test 3 — comment injection (bypasses trailing WHERE conditions)
{ "id": "1; --" }
// Test 4 — time-based blind (MSSQL — confirms injectable without error output)
{ "ref": "1'; WAITFOR DELAY '0:0:5'--" }
// Test 5 — URL-encoded variant (bypasses naive text-filter WAFs)
// %27 = '  %20 = space  %4F%52 = OR
{ "ref": "1%27%20OR%20%271%27%3D%271" }

Step 3 — Decode suspicious encoded strings from your logs

Attackers URL-encode payloads specifically to bypass text-matching WAF rules. A rule blocking ' will not block %27 . When you see unusual percent-encoded strings in your access logs, decode them before deciding whether they are benign.

7. FAQ — SQL Injection in Spring Boot