Rails 3 默认开启了一些很好的保护措施，可以解决很多常见的安全问题。

特别是输出编码将有助于缓解 XSS 攻击，默认情况下，CSRF 令牌在所有应该有帮助的表单上启用，只要您正确使用它，ActiveRecord 或其他 ORM 就可以帮助缓解 SQL 注入。

在输入验证方面，显然有一些事情需要注意。默认情况下，Rails 不会为您进行输入验证，因此如果将输入到您应用程序的数据传输到其他 Web 应用程序，仍然存在发生 XSS 攻击的风险。

也就是说，Rails 确实支持模型中的验证，如果可能的话，我建议在那里对输入进行白名单验证。

在 SQL 注入方面，仍然可以将原始 SQL 与 ActiveRecord 一起使用，如果这样做，则可能会出现 SQL 注入的常见问题，因此再次对所有输入进行白名单验证很有用。

除此之外，还有几件事需要注意。基本的 Rails 安装不提供授权/身份验证，因此必须来自插件或由开发人员编写。

Rails 应用程序通常生成的 RESTful 样式 URL 的一个缺点是攻击者通常很容易通过修改 URL 来尝试破坏授权。例如，显示第一个用户的http://mysite/users/1的 URL可以轻松修改为 2 或更多。并不是说它不安全，而是它使攻击者更容易试图绕过授权控制。

Rails 安全性有几个很好的信息来源，非常值得阅读以获取更多信息。

OWASP rails 安全指南在这里，还有一本书来自 Pragmatic Programmers 的Security on Rails，虽然它侧重于 Rails 2.3，但仍有很多好的信息需要考虑（请注意，Security on Rails 现已绝版）。

在OWASP XSS小抄是一个很好的资源，了解XSS可能发生的所有方式：

• 规则 #0 - 切勿插入不受信任的数据，除非在允许的位置
• 规则 #1 - 在将不受信任的数据插入 HTML 元素内容之前进行 HTML 转义
• 规则 #2 - 在将不受信任的数据插入 HTML 通用属性之前进行属性转义
• 规则 #3 - 在将不受信任的数据插入 HTML JavaScript 数据值之前 JavaScript 转义
• 规则 #4 - 在将不受信任的数据插入 HTML 样式属性值之前进行 CSS 转义
• 规则 #5 - 在将不受信任的数据插入 HTML URL 参数值之前进行 URL 转义
• 规则 #6 - 使用 HTML 策略引擎以出站方式验证或清理用户驱动的 HTML
• 规则 #7 - 防止基于 DOM 的 XSS

并非所有上述规则都由 Rails 自动处理，这取决于版本：

Rails 3.x = "如果将纯字符串传递给 <%= %>，Rails 总是将其转义"
Rails 2.x = 您需要使用 h() 方法（或使用Cross Site Sniper或Safe Erb之类的方法）

白名单确实统治了这一天：如果您希望使用两个字母的美国邮政缩写，则使用验证来仅接受它。

一般安全指南： http: //guides.rubyonrails.org/security.html