rails-security-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Rails Security Review

Rails安全审查

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.

当需要从安全角度审查或加固Rails代码时，使用此技能。

核心原则： 优先处理可被利用的问题，而非代码风格问题。假设任何不可信输入都可能被滥用。

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

领域	关键检查项
身份验证	每个敏感操作都需验证权限
参数	禁止使用 `permit!` ，仅白名单安全属性
查询	使用参数化查询——SQL中禁止字符串插值
重定向	限制为相对路径或使用白名单
输出	对用户内容禁止使用 `html_safe` / `raw`
密钥	使用加密凭证，绝不要存放在代码或日志中
文件	验证文件名、内容类型和目标路径

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).

检查身份验证和授权边界。
检查参数处理和敏感属性赋值。
检查重定向、渲染和输出编码。
检查文件处理、网络调用和后台作业输入。
检查密钥、日志和操作暴露风险。
验证每个发现： 在报告前，通过具体攻击场景确认问题是否可被利用。排除误报（例如，对开发者定义的常量使用
```
html_safe
```
而非用户输入）。

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

缺失或可绕过的授权检查
SQL、Shell、YAML或常量注入路径
不安全的重定向或可发起SSRF的出站请求
盲目信任文件名、内容类型或目标路径的文件上传处理
密钥或令牌存储在代码、日志或不安全的配置中

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

通过弱参数过滤实现的无范围批量赋值
渲染用户控制的HTML但未明确进行清理
敏感数据以明文形式记录在日志中
安全相关行为隐藏在回调或后台作业中且无防护措施
脆弱的自定义身份验证逻辑，使用框架原生组件会更安全

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?

每个敏感操作是否都强制执行权限检查？
不可信输入在用于数据库、文件系统或网络前是否经过验证？
重定向和URL是否受到限制？
密钥的存储和日志记录是否安全？
安全假设是否明确且可测试？

Examples

示例

High-severity (unscoped redirect):

ruby

undefined

高风险（无范围重定向）：

ruby

undefined

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):**

```ruby

SAFE_PATHS = %w[/dashboard /settings].freeze redirect_to(SAFE_PATHS.include?(params[:return_to]) ? params[:return_to] : root_path)


**中风险（批量赋值）：**

```ruby

Bad: privilege escalation risk

不良示例：存在权限提升风险

params.require(:user).permit!

Good: explicit whitelist — never include role, admin, or privilege fields

良好示例：明确白名单——绝不要包含角色、管理员或权限相关字段

params.require(:user).permit(:name, :email)

undefined

params.require(:user).permit(:name, :email)

undefined

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.

完整列表请查看PITFALLS.md。关键反模式：对任何参数集使用

permit!

、对用户内容使用

html_safe

、SQL字符串插值、将密钥存储在已提交的文件中。

Output Style

输出格式

Write findings first. Order findings by review area — auth/authz always first:

Authentication and authorization findings
SQL/injection and parameter findings
Secrets, logging, and output findings

Do not reorder based on which issue looks most obvious. Even if SQL injection is more apparent, authorization findings lead the report.

For each finding include:

Severity: label it High or Medium (not "High-Severity" or "Critical")
Attack path or failure mode
Affected file (name the specific file, e.g.
```
app/controllers/documents_controller.rb
```
)
Smallest credible mitigation

先列出发现的问题。按审查领域排序——身份验证/授权始终排在第一位：

身份验证和授权相关发现
SQL/注入和参数相关发现
密钥、日志和输出相关发现

不要根据问题的明显程度重新排序。即使SQL注入问题更显眼，授权相关发现仍需放在报告开头。

每个发现需包含：

严重等级： 标记为高或中（不要使用“高风险”或“严重”）
攻击路径或失效模式
受影响文件（指定具体文件名，例如
```
app/controllers/documents_controller.rb
```
）
最简可行的修复方案

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)

技能	何时联动
rails-code-review	用于包含非安全问题的完整代码审查
rails-architecture-review	当安全问题源于架构问题时
rails-migration-safety	审查迁移安全性（数据暴露、约束）时