Rails Security Review
Use this skill when the task is to review or harden Rails code from a security perspective.
Core principle: Prioritize exploitable issues over style. Assume any untrusted input can be abused.
HARD-GATE: Authorization Findings Lead the Report
BEFORE returning your security review, verify:
1. The FIRST finding section in your output is "Authentication & Authorization"
2. SQL injection, XSS, or other findings come AFTER auth/authz — even if
they feel more severe or were discovered first
3. If no auth/authz issue exists, the report still opens with an explicit
"Authentication & Authorization: no issues found" line BEFORE any other
finding category
Quick Reference
| Area |
Key Checks |
| Auth |
Permissions on every sensitive action |
| Params |
No permit!, whitelist only safe attributes |
| Queries |
Parameterized — no string interpolation in SQL |
| Redirects |
Constrained to relative paths or allowlist |
| Output |
No html_safe/raw on user content |
| Secrets |
Encrypted credentials, never in code or logs |
| Files |
Validate filename, content type, destination |
Review Order
- Check authentication and authorization boundaries.
- Check parameter handling and sensitive attribute assignment.
- Check redirects, rendering, and output encoding.
- Check file handling, network calls, and background job inputs.
- Check secrets, logging, and operational exposure.
- Verify each finding: Confirm it is exploitable with a concrete attack scenario before reporting. Exclude false positives (e.g.,
html_safe on a developer-defined constant, not user input).
Severity Levels
High
- Missing or bypassable authorization checks
- SQL, shell, YAML, or constantization injection paths
- Unsafe redirects or SSRF-capable outbound requests
- File upload handling that trusts filename, content type, or destination blindly
- Secrets or tokens stored in code, logs, or unsafe config
Medium
- Unscoped mass assignment through weak parameter filtering
- User-controlled HTML rendered without clear sanitization
- Sensitive data logged in plaintext
- Security-relevant behavior hidden in callbacks or background jobs without guardrails
- Brittle custom auth logic where framework primitives would be safer
Review Checklist
- Are permissions enforced on every sensitive action?
- Are untrusted inputs validated before database, filesystem, or network use?
- Are redirects and URLs constrained?
- Are secrets stored and logged safely?
- Are security assumptions explicit and testable?
Examples
High-severity (unscoped redirect):
# Bad: user-controlled redirect — open redirect / phishing risk
redirect_to params[:return_to]
# Good: relative path only
redirect_to root_path
# Good: allowlist
SAFE_PATHS = %w[/dashboard /settings].freeze
redirect_to(SAFE_PATHS.include?(params[:return_to]) ? params[:return_to] : root_path)
Medium-severity (mass assignment):
# Bad: privilege escalation risk
params.require(:user).permit!
# Good: explicit whitelist — never include role, admin, or privilege fields
params.require(:user).permit(:name, :email)
Pitfalls
See PITFALLS.md for the full list. Critical anti-patterns: permit! on any parameter set, html_safe on user content, SQL string interpolation, secrets in committed files.
Output Style
Section order per the HARD-GATE. Every heading appears even when empty (write "No issues found.").
## Authentication & Authorization
## Parameter Handling & Mass Assignment
## Query Safety (SQL / NoSQL / shell injection)
## Output Encoding & Redirects
## Secrets, Logging & Operational Exposure
Each finding carries:
- Severity: High or Medium (not "Critical")
- Attack path: input → reach → impact
- Affected file: path + line, e.g.
app/controllers/documents_controller.rb:42
- Mitigation: smallest credible fix
Integration
| Skill |
When to chain |
| rails-code-review |
For full code review including non-security concerns |
| rails-architecture-review |
When security issues stem from architectural problems |
| rails-migration-safety |
When reviewing migration security (data exposure, constraints) |
1---2name: rails-security-review3description: Performs security audits and vulnerability assessments on Ruby on Rails application code. Use when reviewing Rails code for security risks, assessing authentication or authorization, auditing parameter handling, redirects, file uploads, secrets management, or checking for XSS, CSRF, SSRF, SQL injection, and other common vulnerabilities.4license: MIT5---6
7# Rails Security Review
8
9Use this skill when the task is to review or harden Rails code from a security perspective.
10
11**Core principle:** Prioritize exploitable issues over style. Assume any untrusted input can be abused.
12
13## HARD-GATE: Authorization Findings Lead the Report
14
15```
16BEFORE returning your security review, verify:
17 1. The FIRST finding section in your output is "Authentication & Authorization"
18 2. SQL injection, XSS, or other findings come AFTER auth/authz — even if
19 they feel more severe or were discovered first
20 3. If no auth/authz issue exists, the report still opens with an explicit
21 "Authentication & Authorization: no issues found" line BEFORE any other
22 finding category
23```
24
25## Quick Reference
26
27| Area | Key Checks |
28|------|------------|
29| Auth | Permissions on every sensitive action |
30| Params | No `permit!`, whitelist only safe attributes |
31| Queries | Parameterized — no string interpolation in SQL |
32| Redirects | Constrained to relative paths or allowlist |
33| Output | No `html_safe`/`raw` on user content |
34| Secrets | Encrypted credentials, never in code or logs |
35| Files | Validate filename, content type, destination |
36
37## Review Order
38
391. Check authentication and authorization boundaries.
402. Check parameter handling and sensitive attribute assignment.
413. Check redirects, rendering, and output encoding.
424. Check file handling, network calls, and background job inputs.
435. Check secrets, logging, and operational exposure.
446. **Verify each finding:** Confirm it is exploitable with a concrete attack scenario before reporting. Exclude false positives (e.g., `html_safe` on a developer-defined constant, not user input).
45
46## Severity Levels
47
48### High
49
50- Missing or bypassable authorization checks
51- SQL, shell, YAML, or constantization injection paths
52- Unsafe redirects or SSRF-capable outbound requests
53- File upload handling that trusts filename, content type, or destination blindly
54- Secrets or tokens stored in code, logs, or unsafe config
55
56### Medium
57
58- Unscoped mass assignment through weak parameter filtering
59- User-controlled HTML rendered without clear sanitization
60- Sensitive data logged in plaintext
61- Security-relevant behavior hidden in callbacks or background jobs without guardrails
62- Brittle custom auth logic where framework primitives would be safer
63
64## Review Checklist
65
66- Are permissions enforced on every sensitive action?
67- Are untrusted inputs validated before database, filesystem, or network use?
68- Are redirects and URLs constrained?
69- Are secrets stored and logged safely?
70- Are security assumptions explicit and testable?
71
72## Examples
73
74**High-severity (unscoped redirect):**
75
76```ruby
77# Bad: user-controlled redirect — open redirect / phishing risk
78redirect_to params[:return_to]
79
80# Good: relative path only
81redirect_to root_path
82# Good: allowlist
83SAFE_PATHS = %w[/dashboard /settings].freeze
84redirect_to(SAFE_PATHS.include?(params[:return_to]) ? params[:return_to] : root_path)
85```
86
87**Medium-severity (mass assignment):**
88
89```ruby
90# Bad: privilege escalation risk
91params.require(:user).permit!
92
93# Good: explicit whitelist — never include role, admin, or privilege fields
94params.require(:user).permit(:name, :email)
95```
96
97## Pitfalls
98
99See [PITFALLS.md](./PITFALLS.md) for the full list. Critical anti-patterns: `permit!` on any parameter set, `html_safe` on user content, SQL string interpolation, secrets in committed files.
100
101## Output Style
102
103Section order per the HARD-GATE. Every heading appears even when empty (write "No issues found.").
104
105```
106## Authentication & Authorization
107## Parameter Handling & Mass Assignment
108## Query Safety (SQL / NoSQL / shell injection)
109## Output Encoding & Redirects
110## Secrets, Logging & Operational Exposure
111```
112
113Each finding carries:
114- **Severity:** **High** or **Medium** (not "Critical")
115- **Attack path:** input → reach → impact
116- **Affected file:** path + line, e.g. `app/controllers/documents_controller.rb:42`
117- **Mitigation:** smallest credible fix
118
119## Integration
120
121| Skill | When to chain |
122|-------|---------------|
123| **rails-code-review** | For full code review including non-security concerns |
124| **rails-architecture-review** | When security issues stem from architectural problems |
125| **rails-migration-safety** | When reviewing migration security (data exposure, constraints) |
aibot88