A few years ago, I was reviewing a PR for a teammate who had implemented a "dynamic filter" for a reporting dashboard. To keep the code dry, they used a pattern that looked like this: @records.send(params[:sort_method]). It was elegant, it was concise, and it worked perfectly in development. It also happened to be a catastrophic security hole. By passing a different method name in the URL, an attacker could have called internal Ruby methods to leak environment variables or even trigger unintended state changes in the database. We didn't catch it in code review because we were focused on the logic, not the attack surface. We only found it when I ran Brakeman on the branch before merging. That's the power of static analysis—it sees the patterns you're too close to the code to notice.

Scanning Your Rails Application

Brakeman is a static analysis security tool specifically designed for Ruby on Rails. Unlike a vulnerability scanner that attacks your running application from the outside, Brakeman looks at the source code itself. It parses your files into an Abstract Syntax Tree (AST) and traces the flow of data from "sources" (like params, cookies, or headers) to "sinks" (like SQL queries, HTML rendering, or system calls).

Getting started is straightforward. You add it to your Gemfile in the :development and :test groups, then run it from your terminal. You don't even need to have your database migrated or your server running to get a full report.

gem 'brakeman', require: false

bundle exec brakeman

When you run this, Brakeman will output a table of warnings categorized by confidence levels: High, Medium, and Weak. A "High" confidence warning usually means Brakeman is almost certain there's a vulnerability, like a raw string interpolation inside a where clause. A "Weak" warning might be a general suggestion, like an insecure cookie configuration that might not actually be a problem given your specific infrastructure.

Managing the Noise with Ignore Files

If you run Brakeman on a legacy project for the first time, you're probably going to be greeted by a wall of red text. It can be overwhelming. The first instinct for some developers is to ignore the tool entirely because "it's just giving me false positives," but that's a dangerous road. The reality is that static analysis isn't perfect; it can't always know that you've sanitized a variable in a helper method or that a certain route is protected by a hard-coded admin check.

Instead of ignoring the tool, you use the ignore configuration. Brakeman provides an interactive wizard that lets you go through each warning and decide if it's a real threat or a false positive. If it's a false positive, you can "ignore" it, which adds the specific fingerprint of that warning to a config/brakeman.ignore file.

bundle exec brakeman -I

I always recommend checking this file into version control. This way, your entire team agrees on which risks are acceptable. More importantly, if a developer introduces a new instance of that same vulnerability elsewhere in the code, Brakeman will still flag it because the fingerprint won't match the ignored one. It keeps your CI pipeline clean while ensuring you don't regress into old habits.

📋 Practical Task

Hunting SQL Injection in the Product Search Controller

You have been handed a small Rails project where a developer attempted to implement a flexible product search. However, they used raw string interpolation in the query, creating a classic SQL Injection vulnerability.

Your Task:

1. Create a controller action ProductsController#search with the following vulnerable code:

   def search
         @products = Product.where("name LIKE '%#{params[:query]}%'")
       end

2. Install the brakeman gem and run a scan on your application.
3. Locate the warning in the Brakeman report that identifies the "SQL Injection" in the ProductsController.
4. Fix the vulnerability by using parameterized queries (the "array" or "hash" syntax provided by ActiveRecord).
5. Run Brakeman again to verify that the warning has disappeared.