Injection Flaws in Rails (Ruby)

Injection flaws in Ruby on Rails occur when untrusted input is concatenated into commands or queries without proper sanitization or parameterization. Ruby’s flexible metaprogramming features and Rails’ dynamic query helpers can inadvertently produce unsafe patterns when developers use string interpolation or legacy APIs. These flaws typically manifest in SQL injection, command injection, or unsafe deserialization, and they often map to the OWASP API Top 10 category for Injection.

Consider a Rails controller that builds a SQL query using string interpolation:

query = "SELECT * FROM posts WHERE user_id = #{params[:user_id]}"
results = ActiveRecord::Base.connection.execute(query)

Here, params[:user_id] is directly interpolated into the SQL string. Because Ruby evaluates the interpolation at runtime, an attacker can supply user_id such as 1; DROP TABLE posts;, leading to unintended destructive operations. Even when using ActiveRecord query methods, unsafe patterns can appear, for example:

Post.where("title = '#{params[:title]}'")

This still introduces injection risk because the string is interpolated before being passed to where. Rails encourages the use of bound parameters or sanitized SQL fragments to avoid this. Another common source is the send or eval methods in Ruby, which can enable command injection when used with unchecked input:

system("echo #{params[:message]}")

An attacker can set message to $(rm -rf /) or other shell metacharacters, leading to command injection. Even when input validation is present on the client side, server-side enforcement is required. Rails’ parameter filtering protects sensitive data in logs but does not prevent injection; developers must explicitly sanitize and parameterize.

LLM endpoints exposed in Rails applications also introduce injection concerns. For example, if user input is forwarded directly to an unauthenticated LLM endpoint, injection can manipulate prompts or extract system messages. middleBrick specifically checks for such exposures as part of its LLM/AI Security checks, detecting system prompt leakage and unsafe consumption patterns. In Ruby, failing to escape or validate input before it reaches an LLM can lead to prompt injection or data exfiltration, similar to how injection flaws affect traditional SQL or shell commands.

Because Rails often integrates with multiple data stores and services, injection flaws can span SQL, NoSQL, OS commands, and external APIs. The dynamic nature of Ruby amplifies the impact when unsafe patterns are used in models, controllers, or background jobs. middleBrick’s checks for Unsafe Consumption and Property Authorization help surface these risks by correlating runtime behavior with specification definitions, including resolved $ref paths in OpenAPI documents.

Remediation centers on using parameterized queries, avoiding string interpolation for commands, and validating input at the boundary. For SQL, always prefer ActiveRecord query methods or sanitized SQL with bind variables:

# Safe: using bind parameters
Post.where(user_id: params[:user_id])

# Safe: sanitized SQL with bind variables
Post.where("user_id = ?", params[:user_id])

# Safe: using named bind variables
Post.where("user_id = :user_id", user_id: params[:user_id])

When you need raw SQL, use sanitize_sql or Arel to construct fragments safely:

sql = ActiveRecord::Base.send(:sanitize_sql, ["title = ?", params[:title]])
Post.where(sql)

Avoid eval, send with user-controlled method names, and shell commands with interpolated input. If system commands are necessary, use parameterized forms or whitelists:

# Risky: direct interpolation
system("echo #{params[:message]}")

# Safer: using array arguments to avoid shell interpolation
system("echo", params[:message])

# Safer: strict command and whitelisted arguments
allowed_commands = { "greet" => "echo" }
if allowed_commands.key?(params[:cmd])
  system(allowed_commands[params[:cmd]], params[:message])
end

For mass assignment, always use strong parameters and avoid Model.new(params[:model]) in favor of explicit permit lists:

def post_params
  params.require(:post).permit(:title, :body, :author_id)
end

When integrating with LLM endpoints, ensure user input is never used to construct system prompts or to override instruction segments. Apply output scanning to detect accidental leakage of API keys or PII. middleBrick’s LLM/AI Security probes can validate that prompt injection and jailbreak attempts are handled safely, and its output scanning helps confirm that responses do not expose secrets.

Finally, leverage Rails’ built-in protections such as query caching and prepared statements, and validate input against strict schemas. Regular scans with tools like middleBrick can identify residual injection risks across your API surface, including in OpenAPI-defined endpoints with resolved $ref paths.