flawopen.com/Injection SQL en JavaScript/Knex.js

Knex.js protège-t-il contre les injections SQL ?

SÛR — bindings et liste autorisée
const query = knex.raw(
  `SELECT * FROM users WHERE id = ${userId}`
);

// L’entrée est concaténée au SQL.
const allowedSortColumns = new Set(["created_at", "name"]);

const rows = await knex("users")
  .where("id", userId)
  .orderBy(
    allowedSortColumns.has(requestedSort)
      ? requestedSort
      : "created_at",
    requestedDirection === "asc" ? "asc" : "desc"
  );

// Gardez la valeur séparée de la syntaxe SQL.
knex.raw("SELECT * FROM users WHERE id = ?", [userId]);

Comment les bindings Knex protègent les valeurs

Les méthodes comme .where(), .insert() et .select() séparent les valeurs du SQL généré. Pour le raw, transmettez les valeurs avec des bindings : knex.raw("... = ?", [value]). ? désigne une valeur et ?? un identifiant. N’interpolez pas l’entrée dans une chaîne SQL.

Les identifiants dynamiques nécessitent une liste autorisée

Un binding n’autorise pas les colonnes, tables, tris, opérateurs ou fragments SQL choisis par l’utilisateur. ?? cite un identifiant, sans décider si ce choix est permis. Associez l’option à une liste fixe avant .orderBy() ; gardez mots-clés et opérateurs fixes dans le code.

Auditer les requêtes raw

Recherchez chaque appel knex.raw() et examinez ensemble la chaîne SQL et ses bindings. Vérifiez que les valeurs sont liées et que les identifiants dynamiques proviennent d’une petite liste autorisée. Raw n’est pas automatiquement vulnérable : tout dépend de la construction du SQL et des entrées.

Questions fréquentes

Références

• Documentation Knex.js — Raw et bindings
• Documentation Knex.js — Query builder
• flawopen.com — Injection SQL en JavaScript