Preventing SQL injection in modern frameworks: A practical guide

Last month, while performing a routine audit on a legacy service we’d inherited, I found a raw query string that made my stomach drop. It was concatenating user input directly into a WHERE clause, and it was only a matter of time before someone realized they could dump our entire user table. We fixed it in about two hours by switching to the framework's native query builder, but it reminded me that even in 2024, the basics of data sanitization are still where most systems fail.

Why SQL injection still happens

At its core, SQL injection is a failure of trust. You’re letting the database engine interpret data as code. When you build a query using string concatenation, you aren't just sending data to the database; you're sending instructions.

If you write something like this in Node.js with pg:

JAVASCRIPT
const query = "SELECT * FROM users WHERE username = CE9178">'" + req.body.username + "'";

An attacker doesn't need to be a genius. They just need to provide a username like ' OR '1'='1. Suddenly, your query becomes SELECT * FROM users WHERE username = '' OR '1'='1', and your database returns every record it has.

Preventing SQL injection in modern frameworks

The most effective way to stop this is to stop writing raw SQL strings entirely. Modern ORMs (Object-Relational Mappers) and query builders are built to handle this for you. By using parameterized queries, you force the database to treat user input strictly as data, never as executable commands.

1. Leverage your ORM’s abstraction layer

Whether you’re using Eloquent in Laravel, TypeORM in TypeScript, or Entity Framework in .NET, these tools use prepared statements under the hood. When you use their built-in methods, the ORM sends the query template to the database first, then sends the data separately.

If you find yourself writing raw SQL because you think it’s "faster," stop. You’re usually wrong. If you need to debug a slow query, don’t bypass the ORM; instead, learn Reading an EXPLAIN plan without panic: A Backend Engineer’s Guide to optimize the underlying structure without exposing your application to vulnerabilities.

2. Use parameterized queries everywhere

If your business logic requires a raw query—perhaps for a complex reporting feature—never use template literals. Use placeholders. In most PostgreSQL or MySQL drivers, this looks like $1 or ?.

JAVASCRIPT
// The secure way
const query = CE9178">'SELECT * FROM users WHERE email = $1';
const values = [req.body.email];
await client.query(query, values);

By using $1, you tell the database driver exactly what the input is before the query is parsed. The database engine maps the value to the placeholder, making it impossible for the input to change the query’s logic.

3. Validate input at the application layer

Even with parameterized queries, you shouldn't trust user input. If you're expecting an integer ID, cast it to a number. If you're expecting an email, validate the format. Many developers overlook this, thinking their ORM is a silver bullet.

When you encounter errors while refactoring your logic, check out 7 Laravel errors every beginner hits (and how to fix them) to see how common mistakes in Eloquent often lead to "lazy" security practices.

Trade-offs and the "Wrong Turn"

We once tried to write a custom "sanitization" function that stripped out ' and -- characters. It was a disaster. We ended up breaking legitimate names (like O'Connor) and still left the door open for other types of injection attacks, like numeric-based ones.

The lesson here is simple: don't roll your own security. Use the tools provided by your framework. If you find your framework is too restrictive for your architecture, you might want to revisit your REST API design choices that scale without technical debt to ensure your data handling is clean from the start.

FAQ

Q: Does using an ORM guarantee I’m safe from SQL injection? A: Not entirely. If you use "raw" or "unsafe" methods provided by your ORM (like db.raw() in some libraries), you’re right back to square one. Always look for the parameterized versions of those methods.

Q: Should I use prepared statements for every single query? A: Yes. The performance overhead is negligible, and the security benefits are massive. Modern databases are highly optimized for prepared statements.

Q: What if I need to perform a dynamic ORDER BY clause? A: This is the one place where ORMs usually struggle. Since you can't parameterize column names, use an allow-list. Check the user input against a hardcoded array of allowed columns before injecting it into your query string.

Final thoughts

I’m still not convinced that any application is 100% secure. Even with the best frameworks, a developer can accidentally expose a raw query if they aren't paying attention during a late-night refactor. The best defense isn't just a library; it's a culture of code reviews where we actively look for string concatenation in database calls.

Next time I’m reviewing a PR, I’ll be looking even harder for those raw queries. If you’re still using them, take an hour today to swap them for parameterized queries. Your future self on-call will thank you.