Fix SQL Injection (Legacy & Modern) in Helidon

SQLi in Helidon is a classic sink-source failure. Whether you're running SE's reactive streams or MP's Jakarta stack, concatenating user input into queries is an invitation for a database takeover. Even in modern reactive environments, the database engine doesn't know the difference between your logic and attacker-controlled data unless you use parameterized queries. Let's harden the persistence layer.

The Vulnerable Pattern

// Helidon SE - RAW String Interpolation (FATAL)
dbClient.execute(exec -> exec
    .createQuery("SELECT * FROM users WHERE id = '" + userId + "'")
    .execute());
// Helidon MP - Jakarta Persistence String Concatenation (FATAL)
String jpql = “SELECT u FROM User u WHERE u.username = ’” + username + ”’”;
List users = em.createQuery(jpql, User.class).getResultList();

The Secure Implementation

The vulnerable examples allow an attacker to break out of the SQL data literal using a single quote ('), enabling them to append arbitrary SQL logic (e.g., OR '1'='1). The secure code utilizes Helidon's DbStatement and Jakarta's EntityManager to bind parameters. This ensures that the DB driver treats the input as a literal value rather than executable code, effectively neutralizing the injection vector at the protocol level.

// Helidon SE - Named Parameters (Secure)
dbClient.execute(exec -> exec
    .createQuery("SELECT * FROM users WHERE id = :id")
    .addParam("id", userId)
    .execute());
// Helidon MP - TypedQuery with Bound Parameters (Secure)
TypedQuery query = em.createQuery(“SELECT u FROM User u WHERE u.username = :name”, User.class);
query.setParameter(“name”, username);
List users = query.getResultList();