Secure Coding on the JVM (Concept Bridge)

## The vulnerability **SQL injection (SQLi)** is when an attacker manipulates the SQL a program sends to its database by smuggling SQL syntax inside what was supposed to be plain data (a username, a search term). It is one of the oldest and most damaging web vulnerabilities — it can read, modify, or delete any data the app's DB account can touch. **Why it happens.** A database receives SQL as *text* and parses it into a query plan. If you build that text by string concatenation, the database cannot tell which characters came from the developer and which came from the user — it just parses the whole string. Example of the broken pattern: ```java String sql = "SELECT * FROM users WHERE name = '" + name + "'"; ``` If `name` is `x' OR '1'='1`, the executed SQL becomes `... WHERE name = 'x' OR '1'='1'`, which is always true and returns every row. If `name` is `x'; DROP TABLE users; --`, the input has injected an entirely new statement. The single quote in the input *broke out* of the string literal — this is the essence of an **injection**: data crossing a **trust boundary** (untrusted outside → trusted query) gets reinterpreted as code. ## The fix: parameterized (prepared) queries A **PreparedStatement** separates the query's *structure* from its *values*: ```java String sql = "SELECT * FROM users WHERE name = ?"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, name); // value bound separately try (ResultSet rs = ps.executeQuery()) { /* ... */ } } ``` The `?` is a **placeholder** (a *bind parameter*). The driver/database compiles the template `WHERE name = ?` *before* it ever sees `name`'s value. The value is then sent over the wire as a typed parameter, not spliced into the SQL text. Because the parsed query shape is already fixed, no quote, semicolon, or keyword inside the value can alter it — the value `x' OR '1'='1` is treated as a literal name to look up, and simply matches nothing. This is **data-vs-code separation**: the defense works at the protocol level, not by trying to clean the input. **JPA / Hibernate** give the same guarantee with **named parameters**: ```java List<User> users = em.createQuery( "SELECT u FROM User u WHERE u.name = :name", User.class) .setParameter("name", name) .getResultList(); ``` Spring Data derived queries (`findByName`) and `NamedParameterJdbcTemplate` are parameterized under the hood. The thing to *never* do is build the JPQL/SQL by concatenation. ## Important limits (so you don't get a false sense of safety) - **Identifiers are not parameterizable.** You cannot bind a table name, column name, or sort direction with `?`. If those are dynamic, validate them against a fixed **allow-list** of permitted values; never concatenate user text there. - **`LIKE` wildcards** (`%`, `_`) inside a bound value are still wildcards; escape them if the user shouldn't control matching breadth — but this is a correctness/abuse issue, not classic SQLi. - **Manual escaping is not a substitute.** Trying to escape quotes yourself is fragile (encodings, multibyte tricks) and is the wrong mental model. Parameterize. ## Bonus Parameterized queries also let the database **cache and reuse the execution plan** across calls with different values, which is a performance win, and they avoid locale/format bugs from converting values to strings yourself.