フレームワーク別
Ruby on Railsのセキュリティ対策 — Strong Parameters・認可・gem CVEの守り方
Railsは規約と安全な既定（CSRF保護・Strong Parameters）を多く備えますが、事故は運用で起きます。三大＝Strong Parametersの緩め過ぎ（Mass Assignment）／認可の作り込み不足（認証≠認可）／gem（依存）の既知CVE。加えてSQLの文字列連結・危険な動的メソッド。既定を活かしつつ塞ぐ方法を、攻撃手順を伏せて解説します。
対象：Ruby on Railsでアプリを運営している人。ここでは攻撃手順は扱わず、安全な既定を活かしつつ、運用で開く穴を塞ぐ方法を解説します。全体像は フレームワーク別セキュリティの入口 も参照。
三大落とし穴（既定を外すと開く）
Railsの既定は優秀ですが、次の3つは開発者が意識して守る領域です。
① Mass Assignment
Strong Parametersを広く許可し、is_admin等を想定外に上書き。
② 認可の不足
認証はあるが所有者スコープ無し。ID差し替えで他人のデータ（IDOR）。
③ gemの既知CVE
依存gemの脆弱性を放置。実稼働版で判定し即パッチ。
そのほか、where への文字列連結によるSQLi、send/constantize など危険な動的メソッドにユーザー入力を渡す、credentials/secret_key_base の漏えいも注意点です。
塞ぎ方（3ステップ）
Strong Parameters を必要最小限に絞る
is_admin のような権限フィールドはユーザー入力から代入させない。「面倒だから広く許可」をやめる。認可を明示的に作り込む
current_user のスコープでリソースを絞り、Pundit / CanCanCan 等で認可方針を明示する。取得・更新・削除のたびに所有者を確認（→ IDORとは）。gem（依存）のCVEを監視して即パッチ
whereはプレースホルダを使い文字列連結を避ける。やりがち（危険）
- Strong Parameters を広く許可（Mass Assignment）
- 認可を書かず「ログイン＝閲覧可」
- gem の既知CVEを放置
where("... #{params}")の文字列連結
正しい
- permit を必要最小限に
- 認可を明示（current_user/Pundit）
- gem をCVE監視＋即パッチ
whereはプレースホルダ
当サイトの視点：規約に守られても『認可と依存』は自分の責任
Railsの良い既定は多くのリスクを消してくれますが、「誰が・何を・してよいか」という認可と依存の鮮度だけは、フレームワークが自動で守れません。当サイトが繰り返し見る事故も、凝った攻撃より「認証はあるのに所有者チェックが無い」型が多い。だから守りの重心は、Strong Parametersを締め、認可を明示し、gemをCVE監視すること。派手さはなくても、この地味な3点がRailsの実運用事故の大半を防ぎます。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ Laravelのセキュリティ対策（同じMVC・認可の型が近い）
- 実務：脆弱性(CVE)対応の実務 ／ 依存のCVE監視
- 用語：IDORとは ／ SQLインジェクションとは
よくある質問
QRuby on Railsは安全なフレームワークですか？
Railsは『規約優先』で安全な既定を多く備えます——CSRF保護、Strong Parameters、ORMによるSQL対策などが標準です。正しく使えば堅いフレームワークですが、既定を外したり作り込みを怠ると穴になります。とくにStrong Parametersの緩め過ぎ、認可の不足、gem（依存）の放置CVEは、Rails特有というより運用の問題として繰り返し起きます。
QStrong Parameters で気をつけることは？
Strong Parameters は受け入れるフィールドを明示的に許可（permit）する仕組みで、Mass Assignment（想定外フィールドの一括代入）を防ぐためのものです。危険なのは、面倒だからと広く許可してしまうこと。permit する項目を必要最小限に絞り、is_admin のような権限フィールドは絶対にユーザー入力から代入させないでください。
Q『ログインしていれば見られる』はなぜ危険ですか？
それは認証はあるが認可が無い状態です。Railsはログイン（認証）の仕組みは提供しますが、そのデータが本当にそのユーザーのものかという認可はアプリ固有で、自分で書く必要があります。current_user のスコープでリソースを絞る、Pundit/CanCanCan などで方針を明示する、といった作り込みを怠ると、URLのID差し替えで他人のデータが見えてしまいます（IDOR）。