SQL Injection in Rails remains a critical vector when developers bypass ActiveRecord's abstraction layer. Whether dealing with legacy 3.x apps or modern 7.x monoliths, the root cause is the same: untrusted input concatenated directly into SQL fragments. To kill SQLi, you must enforce boundary separation between code and data.

The Vulnerable Pattern

# Legacy vulnerability: String interpolation in where clause
User.where("email = '#{params[:email]}' AND status = 'active'")
Modern vulnerability: Unsafe dynamic calculation/ordering
User.order(”#{params[:sort_column]} DESC”)
Dangerous use of find_by_sql
User.find_by_sql(“SELECT * FROM users WHERE id = #{params[:id]}“)

The Secure Implementation

ActiveRecord provides a robust protection layer, but only if you use it correctly. String interpolation (`#{}`) forces Ruby to evaluate the string before it ever reaches the database adapter, allowing an attacker to inject malicious SQL fragments. By using the Hash syntax or the Array syntax (`?` placeholders), you utilize 'Bound Variables.' This ensures the database driver treats the input strictly as data, not executable code. For dynamic fragments like ORDER BY or PLUCK, which don't support standard parameterization, you must implement strict whitelisting against a set of known-safe column names to prevent blind SQLi.

# Best Practice: Hash syntax (automatically sanitized)
User.where(email: params[:email], status: 'active')
Secure Parameterized Query: Array syntax
User.where(“email = ? AND status = ?”, params[:email], ‘active’)
Secure Dynamic Ordering: Whitelisting
allowed_columns = [‘created_at’, ‘username’, ‘id’]
sort_column = allowed_columns.include?(params[:sort]) ? params[:sort] : ‘created_at’
User.order(sort_column => :desc)
Secure find_by_sql: Bound variables
User.find_by_sql([“SELECT * FROM users WHERE id = ?”, params[:id]])