SQL Injection

[plexicus]

I replaced the unsafe string interpolation with a parameterized query using Sequelize’s replacements option. Instead of building the WHERE clause by concatenating user input directly into the SQL, the query now uses a named bind (:criteria) and passes the user value in the replacements object as %${criteria}%. This ensures the DB driver treats the input as data, not executable SQL, preventing injection.

Notes and additional recommendations:

• The diff shows the original interpolated query still present; remove that old call so only the parameterized query is used. Leaving both means the vulnerable call would still execute.
• Consider using Sequelize’s higher-level API (e.g., Product.findAll with a where clause using Op.like) instead of raw SQL queries—this further reduces the risk and improves readability.
• The prior regex filter is not sufficient by itself; keep server-side parameterization as the primary protection. You can still validate input length/characters as secondary checks.
• If you need literal % or _ characters to be treated literally, escape them or use appropriate escape options.
• Optionally limit returned rows (LIMIT) and use pagination to avoid excessive result sets.
• For even stronger guarantees, use prepared statements / bound parameters (replacements or bind) consistently across the codebase and avoid dynamic SQL where possible.

Created by: plexicus@plexicus.com