DEV Community: Syed Ghani

Rails GuardDog: Advanced Security Scanner for Rails Applications

Syed Ghani — Sat, 06 Jun 2026 09:22:10 +0000

Rails GuardDog: Advanced Security Scanner for Rails

Introduction

Today I'm excited to announce Rails GuardDog v0.1.0 — an open-source security
scanner for Rails that goes beyond traditional tools like Brakeman.

While Brakeman is excellent for catching basic Rails vulnerabilities, Rails GuardDog
focuses on newer vulnerability classes that most tools miss: AI/LLM prompt injection,
DoS/ReDoS patterns, supply chain attacks, and more.

The Problem

Modern Rails applications face new security challenges:

AI/LLM Integration - How do you prevent prompt injection when integrating with ChatGPT, Claude, or Anthropic?
ReDoS Attacks - Catastrophic backtracking in regex can bring down your app
Supply Chain Attacks - Typosquatted gems that look like popular libraries
IDOR Gaps - Objects accessible without proper authorization checks
Advanced Secrets - Hardcoded API keys that Brakeman misses

Rails GuardDog detects all of these.

What is Rails GuardDog?

Rails GuardDog is a lightweight gem that adds comprehensive security scanning
directly to your Rails applications.

12 Security Checkers

SQL Injection - String interpolation in queries
XSS - Unescaped output in views
CSRF - Disabled protection verification
Mass Assignment - permit! vulnerabilities (fixes Brakeman #1942, #1918)
Open Redirect - User input in redirects
Hardcoded Secrets - API keys, tokens, passwords (always-on, fixes #1989)
DoS/ReDoS - Unbounded queries, dangerous regex patterns
IDOR - Object access without authorization
AI/LLM Prompt Injection - User input flowing to LLMs
Rate Limiting - Missing rack-attack configuration
Supply Chain - Typosquatted gems using Levenshtein distance
GraphQL - Missing field-level authorization

Features

📊 Multiple report formats: Console, HTML, JSON
🔍 AST-based analysis: Uses parser gem for deep code understanding
⚡ Async support: Built-in Sidekiq integration
📈 Zero dependencies: Only requires parser and ast gems
🚀 Production-ready: Tested and battle-ready
📝 CWE/OWASP mappings: Every finding includes vulnerability mappings

Installation

gem 'rails-guarddog'
bundle install

Quick Start

# Scan your Rails app
rake guarddog:scan

# Generate HTML + JSON reports
rake guarddog:report

# CI/CD integration (exits 1 if critical found)
rake guarddog:ci

Example Output

====================================================================
Rails GuardDog Security Report
CRITICAL
Mass Assignment — permit! allows ALL parameters
app/controllers/users_controller.rb:15
Fix: Use permit(:name, :email, :age)
AI Injection — User input in LLM prompt
app/services/chat_service.rb:42
Fix: Sanitize: prompt = 'Template: ' + sanitize(params[:text])
HIGH
DoS: Unbounded query without limit
app/controllers/posts_controller.rb:5
Fix: Add .limit(100) or use pagination

Comparison with Brakeman

Feature	Brakeman	Rails GuardDog
SQL Injection	✅	✅ Enhanced
XSS	✅	✅ Extended
CSRF	✅	✅ Full
Mass Assignment	✅ Partial	✅ Fixed
Secrets	⚠️ Optional	✅ Always-on
DoS/ReDoS	❌	✅ NEW
IDOR	❌	✅ NEW
AI Injection	❌	✅ ORIGINAL
Supply Chain	❌	✅ ORIGINAL
GraphQL	❌	✅ BONUS

Why I Built This

At [Your Company/Team], we encountered vulnerabilities that Brakeman couldn't catch:

A developer passed user input directly to Claude without sanitization
We found dangerous regex patterns that could cause ReDoS attacks
A typosquatted gem almost made it into production
Several GraphQL resolvers lacked authorization checks

I decided to build a tool that catches these modern vulnerabilities.

Real-World Example: AI Injection

Here's a vulnerability Rails GuardDog catches:

# ❌ DANGEROUS - User input flows directly to LLM
def summarize
  text = params[:text]
  response = OpenAI.create_message(
    model: "gpt-4",
    messages: [
      { role: "user", content: "Summarize: #{text}" }
    ]
  )
end

# ✅ SAFE - Sanitized input
def summarize
  text = sanitize(params[:text]).first(500)
  response = OpenAI.create_message(
    model: "gpt-4",
    messages: [
      { role: "system", content: "You are helpful." },
      { role: "user", content: "Summarize: #{text}" }
    ]
  )
end

Rails GuardDog would flag the first example immediately.

Configuration

# config/initializers/guarddog.rb
Rails.application.config.guarddog.enabled_checkers = %w[
  sql_injection xss csrf mass_assignment secrets
  ai_injection idor dos rate_limit
]

Rails.application.config.guarddog.fail_on_severity = :critical

CI/CD Integration

# .github/workflows/security.yml
name: Security Scan

on: [push, pull_request]

jobs:
  guarddog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.2'
          bundler-cache: true
      - name: Run GuardDog
        run: bundle exec rake guarddog:ci
      - name: Upload report
        uses: actions/upload-artifact@v3
        with:
          name: guarddog-report
          path: guarddog_report.*

Get Started

Rails GuardDog is available now on RubyGems:

gem 'rails-guarddog'

RubyGems: https://rubygems.org/gems/rails-guarddog
GitHub: https://github.com/yourusername/rails-guarddog
Issues: https://github.com/yourusername/rails-guarddog/issues
MIT License: Open source and free

Next Steps

Try it in your Rails app: gem 'rails-guarddog'
Run: rake guarddog:scan
Check the HTML report: rake guarddog:report
Add to CI: rake guarddog:ci
Share feedback: GitHub issues

Contributing

Found a bug? Have an idea? Contributions welcome!

Submit issues: https://github.com/yourusername/rails-guarddog/issues
Open PRs: https://github.com/yourusername/rails-guarddog/pulls
Star on GitHub ⭐

Questions?

Drop a comment below or reach out on GitHub!

Rails GuardDog v0.1.0 is production-ready and available now. 🐕

Rails #Security #RubyGems #WebDevelopment #AppSecurity #OpenSource

I built a gem that finds unused CSS classes in Rails apps — here's the interesting problem I had to solve

Syed Ghani — Tue, 02 Jun 2026 00:30:51 +0000

Yesterday I published my first Ruby gem — rails-persona, a behavioral analytics library that lets you track user actions directly on ActiveRecord models.

It had bugs on day one. Wrong File.expand_path depths, frozen array errors in the Railtie, a migration using jsonb that broke on SQLite. I fixed them all, one GitHub issue at a time, and learned more about how Rails gems work internally than any tutorial ever gave me.

That experience gave me the confidence to build another one.

Introducing rails-css_unused

gem 'rails-css_unused', group: :development
bundle install
bundle exec rake css_unused:report

That's it. You get a full report of every CSS class that's defined in your stylesheets but never referenced anywhere in your views, components, or JS files.

rails-css_unused v0.2.1
✔ Scanning views & components
✔ Scanning stylesheets
✔ Comparing & computing ghost classes

Ghost Class Report
Ghost classes (unused): 2
• old-card-header
• legacy-sidebar-btn

No server needed. No browser. Pure static analysis.

What it scans

ERB, HAML, Slim templates
ViewComponent and Phlex component files
Stimulus JS controllers (classList.add, classList.toggle)
Ruby component .rb files
BEM class names (block__element--modifier)

The interesting problem I had to solve in v0.2.1

When I tested the gem on my own Online Exam System project, it flagged these as ghost classes:

• status-approved
• status-cancelled
• status-requested

But they were very much in use. Here's why the scanner missed them:

<% status_label, status_class =
  if exam.cancelled?
    ["Cancelled", "status-cancelled"]
  elsif exam.active? && exam.approved?
    ["Active", "status-active"]
  elsif exam.approved?
    ["Approved", "status-approved"]
  elsif exam.request_approval?
    ["Requested approval", "status-requested"]
  else
    ["Draft", "status-draft"]
  end %>

<span class="status-pill <%= status_class %>"><%= status_label %></span>

The classes are assigned to a variable (status_class) and rendered via <%= status_class %>. The scanner only picks up string literals in class="..." attributes — it can't see through variable interpolation.

The naive fix would be to add ignore_patterns << /\Astatus-/ to the config. But that feels wrong — you're telling the tool to ignore a whole prefix forever, which masks future real ghost classes.

The elegant fix

Here's the insight that made this work cleanly:

Ruby variable names cannot contain hyphens.

status-cancelled as a variable would be a syntax error — Ruby parses it as status - cancelled (subtraction). So any quoted string containing a hyphen is unambiguously a string value, never a variable name.

This means we can safely extract hyphenated quoted strings as CSS class names:

# Pattern 1: *_class / *_classes variable assignments
DYNAMIC_CLASS_VAR = /\b\w+_(?:class(?:es)?|style|css)\s*=\s*["']([^"'\n]+)["']/

# Pattern 2: any quoted string containing a hyphen
# (unambiguously a string value in Ruby — never a variable name)
HYPHENATED_STRING = /["']([a-zA-Z][a-zA-Z0-9]*(?:-[a-zA-Z0-9]+)+)["']/

With these two patterns, the scanner now finds:

["Cancelled", "status-cancelled"]   # ✅ status-cancelled extracted
["Approved",  "status-approved"]    # ✅ status-approved extracted
status_class = "status-active"      # ✅ status-active extracted
button_classes = "btn btn-primary"  # ✅ btn-primary extracted

No ignore_patterns workarounds needed. No false positives.

Configuration

# config/initializers/css_unused.rb
Rails::CssUnused.configure do |config|
  config.ignore_classes   = %w[clearfix sr-only visually-hidden]
  config.ignore_patterns  = [/\Ajs-/, /\Ais-/, /\Ahas-/]
  config.fail_on_unused   = true   # exit 1 in CI
  config.show_source_files = true  # show which stylesheet each ghost came from
end

I open-sourced a modern acts_as_tenant alternative for Rails 7+

Syed Ghani — Mon, 01 Jun 2026 15:56:31 +0000

---
title: "Introducing rails-tenantify: Row-Level Multi-Tenancy for Rails 7+"
published: true
description: "A modern, safe, and robust row-level multi-tenancy gem for Ruby on Rails. Prevent data leaks, protect bulk writes, and preserve tenant context in background jobs."
tags: rails, ruby, opensource, saas
---

## The Problem

Every multi-tenant SaaS app eventually needs to answer the same questions:

* How do we make sure School A never sees School B's data?
* How do we scope every query to the right organization?
* How do we keep tenant context alive in background jobs and Sidekiq retries?
* How do we stop a careless `update_all` from wiping another tenant's rows?

The typical answer is *"use acts_as_tenant"* or *"switch to Apartment."* But in modern Rails development, that often means:

* Fighting unmaintained APIs on Rails 7+
* Losing tenant context when a background job retries
* Dealing with schema-per-tenant complexity (Apartment) and heavy DevOps overhead
* Rolling your own `default_scope` and crossing your fingers that nobody calls `unscoped`

For most Rails apps, you just need **row-level tenancy**: one database, one `organization_id` column, and strict scoping. The pattern is simple. Getting it **safe** in production is not.

---

## What I Built

**`rails-tenantify`** is a Ruby gem that adds row-level multi-tenancy directly to your Rails models and controllers. No external services, no extra databases per tenant—just your own PostgreSQL (or SQLite in dev).

ruby
class Project < ApplicationRecord
include Tenantify::Scoped

belongs_to_tenant :organization
end


### Set the tenant once per request

ruby
class ApplicationController < ActionController::Base
set_tenant_by :subdomain # acme.yourapp.com → Organization
end


### Everything scopes automatically

ruby
Tenantify.current_tenant = current_organization

Project.all # Only this org's projects
Project.create!(name: "Q2 Roadmap") # organization_id is set automatically


### Switch context safely for admins or scripts

ruby

Temporarily switch context

Tenantify.switch_to(other_org) do
Project.count # Scoped to other_org
end

Intentional bypass

Tenantify.without_tenant do
Project.delete_all

end


---

## How it compares to `acts_as_tenant`

While `acts_as_tenant` pioneered this pattern, many teams hit walls on modern Rails—especially around background jobs, bulk SQL, and strict safety. `rails-tenantify` was built from the ground up for Rails 7+ with those gaps in mind.

| Feature | `acts_as_tenant` | `rails-tenantify` |
| --- | --- | --- |
| **Rails 7+ Focus** | Partial | **Yes** |
| **Subdomain Resolver** | DIY | `set_tenant_by :subdomain` |
| **API Header Resolver** | DIY | `set_tenant_by :header` |
| **Sidekiq Retry + Tenant** | Known issues | **Tenant ID preserved in job payload** |
| **`update_all` / `delete_all**` | Unreliable protection | **Raises unless explicitly scoped** |
| **Cross-Tenant Associations** | Manual checks | **Built-in validation** |
| **Unsafe Tenant Swap** | No audit | Options: `:log`, `:raise`, or `:ignore` |
| **Test Helpers** | Partial | Native `with_tenant` / `without_tenant` |

---

## How it compares to `Apartment`

`Apartment` uses separate schemas or databases per tenant. That offers strong isolation, but you pay a steep price in migrations, backups, and connection management.

`rails-tenantify` keeps one database and scopes via a foreign key—the exact tradeoff most B2B SaaS products actually want.

| Feature | `Apartment` | `rails-tenantify` |
| --- | --- | --- |
| **Isolation Model** | Schema / DB per tenant | Row-level Foreign Key |
| **Migrations** | Per-tenant complexity | Standard Rails migration path |
| **Ops Overhead** | Higher | **Lower** |
| **Best Fit For** | Strict regulatory separation | Typical B2B SaaS |

---

## Key Features

### 1. Multi-Resolution Strategies

Resolve your tenant out of the box via subdomains or API headers:

ruby

Subdomain resolution (excludes common marketing/admin routes)

set_tenant_by :subdomain, exclude: %w[www admin]

API resolution for mobile or JSON clients

set_tenant_by :header, header: "X-Tenant-ID"


Or resolve manually based on the session:

ruby
before_action do
Tenantify.current_tenant = current_user.organization if user_signed_in?
end


### 2. Bulletproof Background Jobs

The tenant automatically survives enqueueing and execution via standard **ActiveJob**:

ruby
class ExportJob < ApplicationJob
def perform
Tenantify.current_tenant # Automatically set to the org that enqueued the job
Project.find_each { |p| p.update!(exported: true) }
end
end


*Note: If you use **Sidekiq**, the middleware registers automatically and injects the `tenant_id` straight into the job hash.*

### 3. Bulk-Write Protection

Avoid the ultimate multi-tenancy footgun: accidental database-wide updates.

ruby
Project.update_all(status: "archived") # Raises an error if not explicitly scoped to current tenant
Project.unscoped.update_all(...) # Raises Tenantify::TenantMismatchError

Explicitly allowed bypass:

Tenantify.without_tenant do
Project.update_all(status: "migrated")

end


### 4. Cross-Tenant Association Checks

Prevent data leaking through relationships.

ruby
task.project = project_from_other_org
task.valid? # => false (Errors: "belongs to a different tenant")


### 5. Override Auditing

Catch risky code that unexpectedly swaps tenants mid-request.

ruby
Tenantify.configure { |c| c.audit_overrides = :raise }

Tenantify.current_tenant = org_a
Tenantify.current_tenant = org_b # => Raises Tenantify::TenantOverrideError


---

## Installation & Setup

Add the gem to your `Gemfile`:

ruby
gem "rails-tenantify", "~> 0.1.2", require: "rails-tenantify"


Run `bundle install` and create an initializer at `config/initializers/tenantify.rb`:


Add the tenant foreign key to your tables:

bash
rails g model Organization name:string subdomain:string:uniq
rails g migration AddOrganizationToProjects organization:references
rails db:migrate


> ⚠️ **Note on Naming:** The gem is published as `rails-tenantify` on RubyGems but required as `"rails-tenantify"`. (The old, legacy `tenantify` name on RubyGems belongs to an unrelated, abandoned library from 2016).

### Built-In Testing Helpers (RSpec Friendly)

ruby

spec/rails_helper.rb

RSpec.configure { |c| c.include Tenantify::TestHelpers }

In your specs:

it "scopes creation automatically" do
with_tenant(org_a) do
exam = Exam.create!(title: "Midterm")
expect(exam.organization).to eq(org_a)
end
end


---

## Roadmap: Subdomains vs Custom Domains

* **Supported today:** Tenant subdomains on your primary application host (e.g., `greenwood.yourapp.com` → `Organization.find_by(subdomain: "greenwood")`).
* **Coming soon:** Full custom apex domains (e.g., `greenwood.edu` resolving via host-based lookups and custom DNS mapping).

---

## Why I Built This

I was building a multi-tenant Online Exam System in Rails—multiple schools, each with their own admins, teachers, exams, and students. I needed Greenwood School to absolutely *never* see Riverside School's data. Not in the UI, not in a background job, and definitely not via a copy-pasted `update_all` statement in a production console.

I didn't want the DevOps nightmare of managing a schema-per-school, and I didn't want to fork unmaintained tenancy gems. I wanted to run `bin/rails tenantify:verify` after my seeds ran and sleep soundly knowing data isolation was working perfectly.

So, I built `rails-tenantify`, integrated it into production, and open-sourced v0.1.2.

## Links & Feedback

* **GitHub:** [github.com/sghani001/rails-tenantify](https://www.google.com/search?q=https://github.com/sghani001/rails-tenantify)
* **RubyGems:** [rubygems.org/gems/rails-tenantify](https://www.google.com/search?q=https://rubygems.org/gems/rails-tenantify)

If you give it a try, I'd love to hear your thoughts! Open an issue, leave a comment below, or drop a ⭐ on the GitHub repository.

plaintext

I built rails-persona — behavioral analytics for Rails with zero external services

Syed Ghani — Sun, 31 May 2026 16:35:04 +0000

The problem

Every SaaS app eventually needs to answer the same questions:

Which features do my users actually use?
Who are my most active users?
When did a user last do something meaningful?
Which users are going inactive?

The typical answer is "add Mixpanel" or "set up Segment." But that means:

Sending your user data to a third party
Paying for another service
Adding a JS snippet
Learning another dashboard

For most Rails apps, this is overkill. The data you need is already in your database.

What I built

rails-persona is a Ruby gem that adds model-level behavioral analytics directly to your ActiveRecord models. No external services, no JS, no cookies — just your own database.

class User < ApplicationRecord
  include Persona::Trackable

  persona do
    track :login
    track :export_report
    track :view_dashboard
    track :upgrade_plan
  end
end

Then track actions anywhere in your app:

current_user.track!(:login)
current_user.track!(:upgrade_plan, metadata: { plan: "pro", amount: 49 })

And query behavior instantly:

user.most_frequent_action       # => :login
user.inactive_since?(30)        # => false
user.persona_summary            # => { login: 42, export_report: 5 }
user.daily_activity(7)          # => { "2024-05-28" => 4, "2024-05-29" => 7 }
user.peak_hour                  # => 14  (2pm)
User.persona_leaderboard        # => top 10 most active users

How it's different from ahoy

ahoy is a great gem but it solves a different problem — it tracks HTTP visits and page views. rails-persona tracks what users do inside your app at the model level.

	ahoy	rails-persona
Focus	HTTP visits + page views	Model actions + behavior
Needs JS	Yes	No
Async built-in	No	Yes (Sidekiq)
Bulk tracking	No	Yes (insert_all!)
Class leaderboards	No	Yes
Works on any model	Awkward	First-class

Key features

Async tracking — never slow down a request:

Persona.configure do |config|
  config.async = true  # fires a Sidekiq job
end

Bulk tracking — uses insert_all! under the hood:

user.bulk_track!([:login, :view_dashboard, :export_report])

Open tracking — skip the whitelist entirely:

persona do
  open_tracking!  # any string is valid
end

Data pruning — keep your DB clean:

Persona.configure do |config|
  config.max_events_per_record  = 500
  config.auto_prune_after_days  = 90
end

Works on any model — not just User:

class Post < ApplicationRecord
  include Persona::Trackable

  persona do
    track :viewed
    track :shared
    track :bookmarked
  end
end

Post.persona_class_summary  # => { viewed: 50_420, shared: 890 }

Installation

# Gemfile
gem "rails-persona"

bundle install
rails db:migrate

Why I built this

I was the sole engineer on a production SaaS called CinnaLab PRM — an AI-powered Partner Relationship Management platform. I kept wanting to know things like "which users are using the partner portal vs ignoring it?" and "who's about to churn based on inactivity?"

I didn't want to set up Mixpanel for an internal SaaS. I just wanted to query my own database. rails-persona is what I wish had existed.