Fix SQL Injection (Legacy & Modern) in Cuba

SQL Injection remains the most reliable way to dump data in legacy CUBA (now Jmix) applications. If you are concatenating strings in your middleware or using raw SQL without sanitization, you are handing attackers the keys to the kingdom. In CUBA, the attack surface usually exists in custom Service beans or Screen controllers where developers bypass the standard DataManager API to execute native queries.

The Vulnerable Pattern

/* VULNERABLE: Direct string concatenation in Native SQL */
@Inject
private EntityManager entityManager;
public List<Object[]> getLegacyUserData(String username) {
// DANGER: Attacker can input ‘admin’ OR ‘1’=‘1’
String sql = “SELECT id, login FROM sec_user WHERE login = ’” + username + ”’”;
return entityManager.createNativeQuery(sql).getResultList();
}

The Secure Implementation

The exploit vector relies on the database engine's inability to distinguish between executable commands and user-provided data. By using the DataManager with named parameters (:login) or the EntityManager with positional parameters (?1), you utilize 'Prepared Statements'. This forces the database driver to treat the input as a literal value rather than part of the SQL command. In the CUBA/Jmix ecosystem, using DataManager is the gold standard because it not only prevents SQLi but also automatically enforces platform-level security roles and ACLs.

/* SECURE: Using DataManager with Parameterized JPQL (Modern) */
@Inject
private DataManager dataManager;
public List getSecureUserData(String username) {
return dataManager.load(User.class)
.query(“select u from sec$User u where u.login = :login”)
.parameter(“login”, username)
.list();
}
/* SECURE: Using Parameterized Native Query (Legacy Fix) */
public List<Object[]> getSecureNativeData(String username) {
return entityManager.createNativeQuery(“SELECT id, login FROM sec_user WHERE login = ?1”)
.setParameter(1, username)
.getResultList();
}