Ruby on Railsのセキュリティ対策 — 本番ハードニング実務リファレンス

対象：Ruby on Railsでアプリを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの入口 も参照。

優先度つきハードニング・チェックリスト

まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用衛生です。

1. 秘密と credentials（P0）

• Railsの暗号化 credentials を使い、master key（復号鍵）をリポジトリにコミットしない（環境変数などで注入）。
• secret_key_base は署名/暗号化Cookieやセッションの土台。漏洩したら速やかにローテーション（既存の署名/暗号化が無効化される点に注意）。
• .env やダンプ・バックアップを公開ディレクトリに置かない（→ 公開ディレクトリに秘密を置かない）。

2. 本番設定（P0）

• 本番では例外の詳細を外部に出さない（consider_all_requests_local を本番で有効にしない等）。内部構造の露出を減らす。
• config.force_ssl でHTTPSを強制し、Cookie を secure に。開発用の web console 等を本番で有効にしない。
• ログに機微が残らないよう filter_parameters でパスワード等をフィルタする。

3. 依存（gem）のCVE（P0）

• bundler-audit や osv-scanner で gem の既知CVEを機械監視し、実稼働版（Gemfile.lock）で判定して即パッチ（→ 依存のCVE監視 ／ CVE対応の実務）。
• Rails と Ruby をサポート対象バージョンに保ち、EOL版を放置しない。

4. Strong Parameters と Mass Assignment（P1）

• permit する項目を必要最小限にし、permit!（全許可）を避ける。
• is_admin のような権限フィールドをユーザー入力から代入させない。「面倒だから広く許可」をやめる。

5. 認可（P1・最多の事故源）

用語は IDORとは。認証と認可は別物で、認可はデータに近い場所で確認します。

6. インジェクションと危険な動的メソッド（P2）

• SQL：where はプレースホルダでバインドし、文字列連結でクエリを組まない（where("... #{params}") を避ける）（→ SQLインジェクションとは）。
• 危険な動的メソッド：send/public_send/constantize にユーザー入力を渡さない。渡すなら許可リストで厳しく限定する。
• デシリアライズ：信頼できない YAML/Marshal の読み込みは条件次第でコード実行に繋がり得るため避ける。

7. セッション・Cookie・CSRF（P2）

• **CSRF保護（protect_from_forgery）**を全体無効化しない。フォームのトークンを活かす（→ CSRFとは）。
• Cookie/セッションに secure/httponly/samesite を設定し、ログイン時にセッションを再生成する。

8. SSRF・アップロード・ヘッダ（P2）

• サーバーがユーザー指定URLを取得する処理は許可先を限定し、内部IP/メタデータへの到達を遮断する（→ SSRFとは）。
• アップロードは種別・サイズを検証し、public/ 外に保存して実行権限を与えない。
• セキュリティヘッダを付与（自サイトは セキュリティヘッダ診断 で確認）。

検証：自分のRailsは固められているか

作ったら終わりでなく、点検して初めて完了です。以下は自分の環境に対する防御的な自己チェックです。

次に読む

• 入口：フレームワーク別セキュリティ（入口） ／ Laravelのセキュリティ対策（同じMVC・認可の型が近い）
• 実務：脆弱性(CVE)対応の実務 ／ 依存のCVE監視 ／ 公開ディレクトリに秘密を置かない
• 用語：IDORとは ／ SQLインジェクション ／ CSRF ／ SSRF
• ツール：セキュリティヘッダ診断