Fix SQL Injection (Legacy & Modern) in LoopBack

LoopBack's Juggler ORM is a double-edged sword. In legacy LB3 and modern LB4, developers often drop down to raw SQL via connector.execute() when the abstraction layer feels restrictive. If you are concatenating raw input into these queries, you are handing over the keys to your database. This guide targets the elimination of SQLi by enforcing parameterization across both versions.

The Vulnerable Pattern

// Legacy LB3 - Raw execution via connector
const sql = "SELECT * FROM Users WHERE id = '" + req.params.id + "'";
ds.connector.execute(sql, (err, data) => { /* pwned */ });
// Modern LB4 - String interpolation in execute()
const query = SELECT * FROM users WHERE role = '${role}';
const results = await this.dataSource.execute(query);

The Secure Implementation

The vulnerability exists because string concatenation merges untrusted input directly into the SQL command context. An attacker can inject characters like "' OR 1=1 --" to bypass authentication or dump tables. The fix involves using parameterized queries. By using placeholders (like ? or $1), the SQL engine treats the input as a literal value rather than executable code. In LoopBack 4, the Repository pattern's 'where' filters are automatically sanitized by the underlying Juggler, making it the safest default choice.

// Legacy LB3 - Use placeholders (?)
const sql = "SELECT * FROM Users WHERE id = ?";
ds.connector.execute(sql, [req.params.id], (err, data) => { /* secured */ });
// Modern LB4 - Positional parameters ($1, $2)
const query = ‘SELECT * FROM users WHERE role = $1’;
const results = await this.dataSource.execute(query, [role]);
// Modern LB4 - Preferred Repository Pattern
const results = await this.userRepository.find({ where: { role: role } });