SQL Injection in Modern Frameworks: What Code Reviewers Still Miss

SQL injection remains one of the most dangerous web vulnerabilities, consistently ranking in the OWASP Top 10. While modern frameworks promise protection through ORMs and prepared statements, subtle injection patterns continue to slip through code reviews. This guide reveals the advanced SQL injection techniques that reviewers often miss in Rails, Django, Spring Boot, and other popular frameworks.

Why SQL Injection Still Happens in Modern Frameworks

Modern web frameworks have significantly reduced SQL injection vulnerabilities through Object-Relational Mapping (ORM) layers and prepared statements. However, developers often need to drop down to raw SQL for performance optimization, complex queries, or features not supported by the ORM. This is where vulnerabilities creep in.

The Attack Surface in Modern Applications

Framework-Specific Injection Patterns

Each framework has its own quirks and dangerous patterns. Understanding these framework-specific vulnerabilities is crucial for effective code review.

Rails (ActiveRecord) Vulnerabilities

Ruby on Rails' ActiveRecord provides excellent protection when used correctly, but several methods can introduce vulnerabilities when user input is not properly sanitized.

# VULNERABLE - Direct user input in order clause
User.order(params[:sort_by])

# VULNERABLE - String interpolation in where clause
User.where("name = '#{params[:name]}'")

# VULNERABLE - SQL fragment injection
User.where("age > ? AND #{params[:condition]}", 18)

# SAFE - Whitelist approach for sorting
allowed_sorts = %w[name email created_at]
sort_column = allowed_sorts.include?(params[:sort_by]) ? params[:sort_by] : 'id'
User.order(sort_column)

# SAFE - Parameterized queries
User.where("name = ?", params[:name])

# SAFE - ActiveRecord methods with hash syntax
User.where(name: params[:name], age: params[:age])

Django ORM Security Issues

Django's ORM is generally secure, but certain methods and practices can introduce vulnerabilities, especially when building dynamic queries.

# VULNERABLE - Raw SQL with string formatting
User.objects.raw("SELECT * FROM users WHERE name = '%s'" % user_input)

# VULNERABLE - Extra() method with user input
User.objects.extra(where=["name = '%s'" % user_input])

# VULNERABLE - Dynamic field lookups
filter_dict = {request.GET['field']: request.GET['value']}
User.objects.filter(**filter_dict)

# SAFE - Parameterized raw queries
User.objects.raw("SELECT * FROM users WHERE name = %s", [user_input])

# SAFE - Q objects for complex queries
from django.db.models import Q
User.objects.filter(Q(name=user_input) | Q(email=user_input))

# SAFE - Field validation before dynamic lookups
ALLOWED_FIELDS = ['name', 'email', 'username']
field_name = request.GET.get('field')
if field_name in ALLOWED_FIELDS:
    User.objects.filter(**{field_name: request.GET['value']})

Spring Boot / JPA Injection Risks

Spring Boot applications using JPA are vulnerable when developers use native queries or construct JPQL dynamically with user input.

// VULNERABLE - String concatenation in native queries
@Query(value = "SELECT * FROM users WHERE name = '" + 
       "#{#userInput}" + "'", nativeQuery = true)
List<User> findByName(@Param("userInput") String name);

// VULNERABLE - Dynamic JPQL construction
String jpql = "SELECT u FROM User u WHERE u.status = '" + userStatus + "'";
return entityManager.createQuery(jpql, User.class).getResultList();

// VULNERABLE - Criteria API with string building
CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<User> query = cb.createQuery(User.class);
Root<User> root = query.from(User.class);
query.where(cb.equal(root.get(userProvidedField), value));

// SAFE - Named parameters in native queries
@Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true)
List<User> findByName(@Param("name") String name);

// SAFE - JPA Repository methods
public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByNameAndStatus(String name, String status);
}

// SAFE - Parameterized JPQL
TypedQuery<User> query = entityManager.createQuery(
    "SELECT u FROM User u WHERE u.status = :status", User.class);
query.setParameter("status", userStatus);

Advanced Injection Techniques to Watch For

Modern SQL injection attacks have evolved beyond simple quote escaping. Code reviewers need to recognize these sophisticated patterns.

Second-Order SQL Injection

Second-order injections occur when malicious input is stored in the database and later used unsafely in a different query. These are particularly dangerous because they can persist and be triggered by other users.

NoSQL and JSON Injection

Applications using PostgreSQL's JSON features, MongoDB queries, or other NoSQL databases are susceptible to similar injection attacks through malformed JSON objects.

// VULNERABLE - MongoDB query injection
db.users.find(JSON.parse(userInput));

// VULNERABLE - PostgreSQL JSON injection
SELECT * FROM users WHERE profile::json @> '${userInput}';

// SAFE - Parameterized NoSQL queries
const filter = { name: userInput, active: true };
db.users.find(filter);

Time-Based Blind Injection

Even when error messages are suppressed and data isn't returned, attackers can exploit time delays to extract information. Look for queries where user input affects performance characteristics.

Code Review Checklist for SQL Injection

Automated Detection Tools

While manual code review is essential, automated tools can help catch common SQL injection patterns and reduce reviewer workload.

Static Analysis Security Testing (SAST)

Defense in Depth Strategy

Preventing SQL injection requires multiple layers of protection. No single technique is sufficient on its own.

Multi-Layer Security Approach

Database Security Configuration

Building SQL Injection Awareness

Creating a security-conscious development culture requires ongoing education and practical training for your engineering team.

Team Training Recommendations

💡 The best defense against SQL injection is a well-trained development team that thinks security-first.