RailsのStrong Parametersでやってはいけない書き方！初心者でもわかるpermit!の危険と安全な書き方

1. Strong Parametersとは？

1. Strong Parametersとは？

Strong Parameters（ストロングパラメータ）とは、Railsのコントローラで受け取る値を明示的に指定する仕組みです。

これにより、想定外の値が勝手に保存されるのを防ぐことができ、セキュリティを強化できます。

例えば、ブログ記事を保存する場合、次のようにparamsから許可するキーを指定します。

def post_params
  params.require(:post).permit(:title, :body)
end

:titleと:bodyだけを受け取るようにし、それ以外の項目はすべて無視されます。

2. permit!とは？なぜ使ってはいけない？

2. permit!とは？なぜ使ってはいけない？

permit!は、すべてのパラメータを無条件で許可するメソッドです。

次のように書くと、送られてきた全データを一気に許可してしまいます。

def post_params
  params.require(:post).permit!
end

これは非常に危険なコードです。たとえば、悪意のあるユーザーが管理者フラグ（admin）や、他人のuser_idを勝手に含めて送ってきたとしても、それらがそのまま保存されてしまいます。

3. permit!の危険性を具体例で確認

3. permit!の危険性を具体例で確認

たとえば、次のようなユーザー更新フォームがあるとします。

<form action="/users/1" method="post">
  <input name="user[name]" value="山田太郎" />
  <input name="user[admin]" value="true" />
</form>

そして、コントローラ側でpermit!を使っていた場合、

def user_params
  params.require(:user).permit!
end

悪意のあるユーザーが管理者になれてしまうという、大変な問題が起きます。

4. 安全なStrong Parametersの書き方

4. 安全なStrong Parametersの書き方

permitで明示的に受け取る項目を一つひとつ指定するのが基本です。

def user_params
  params.require(:user).permit(:name, :email)
end

このようにしておけば、:nameと:emailしか保存されないので、予期せぬ項目が登録される心配はありません。

5. ネストされたデータを扱う場合もpermitを使おう

5. ネストされたデータを扱う場合もpermitを使おう

たとえば、投稿と一緒にタグの情報を送るといった、ネストされたパラメータも、安全に扱うことができます。

def post_params
  params.require(:post).permit(:title, :body, tags: [])
end

tags: []のように配列として許可することで、指定されたデータだけが保存されるようになります。

6. 管理者だけ許可したい項目はコントローラ側で分岐

6. 管理者だけ許可したい項目はコントローラ側で分岐

「管理者だけが:adminを更新できるようにしたい」といった場合は、条件分岐で対処します。

def user_params
  if current_user.admin?
    params.require(:user).permit(:name, :email, :admin)
  else
    params.require(:user).permit(:name, :email)
  end
end

このようにすることで、一般ユーザーにはadmin項目が反映されないように防止できます。

7. Strong ParametersはRailsセキュリティの基本

7. Strong ParametersはRailsセキュリティの基本

Strong Parametersは、Railsで安全にデータを扱うための基本的なセキュリティ機構です。

面倒だからといってpermit!を使ってしまうと、アプリケーション全体が乗っ取られる危険性もあります。

初心者のうちから、明示的に項目を許可する癖をつけることで、安全なWebアプリを作る力が身につきます。

まとめ

まとめ

ここまで、Ruby on RailsにおけるStrong Parameters（ストロングパラメータ）の重要性と、安易にpermit!メソッドを使用することの危険性について詳しく解説してきました。Webアプリケーション開発において、ユーザーから送られてくるデータは「常に悪意があるかもしれない」という前提で扱う必要があります。Strong Parametersは、いわばアプリケーションの入り口に立つ「門番」のような役割を果たしており、許可されたデータのみを内部へ通すことで、データベースを不正な更新から守ってくれます。

Strong Parametersの核心：なぜ明示が必要なのか

Railsの設計思想には「設定より規約（CoC）」という言葉がありますが、セキュリティに関しては「規約」に甘えるのではなく、開発者が意図を持って「設定」することが求められます。permit!を使ってしまうと、その門番が不在の状態になり、どのようなデータも素通りさせてしまいます。これは、家の鍵をかけずに外出するのと同じくらい無防備な状態です。

具体的に、データベースの運用イメージを見てみましょう。例えば、ユーザー情報を管理するusersテーブルがあるとします。

id | name     | email              | admin
---+----------+--------------------+-------
1  | 佐藤健太 | sato@example.com   | false
2  | 鈴木美咲 | suzuki@example.com | false
3  | 高橋裕二 | taka@example.com   | true

もし、コントローラで次のような危険なコードを書いていた場合、どのようなことが起こるでしょうか。

# 危険な実装例
def update
  @user = User.find(params[:id])
  if @user.update(user_params)
    redirect_to @user, notice: '更新しました'
  else
    render :edit
  end
end

private

def user_params
  # 全てのパラメータを無条件で許可してしまう
  params.require(:user).permit!
end

悪意のあるユーザーが、ブラウザの開発者ツールなどを使い、リクエストにuser[admin]=trueという値を忍び込ませて送信したとします。すると、SQLは以下のように実行され、本来一般ユーザーであるはずの「佐藤健太」さんが管理者になってしまいます。

-- permit! によって admin フラグまで更新されてしまう
UPDATE users
SET name = '佐藤健太', admin = true, updated_at = '2026-01-30 17:00:00'
WHERE id = 1;

実行後のテーブルの状態は以下の通りです。

id | name     | email              | admin
---+----------+--------------------+-------
1  | 佐藤健太 | sato@example.com   | true  (←勝手に管理者に！)
2  | 鈴木美咲 | suzuki@example.com | false
3  | 高橋裕二 | taka@example.com   | true

これを防ぐためには、記事の中で説明した通り、許可する項目を絞り込む必要があります。

# 安全な実装例
def user_params
  params.require(:user).permit(:name, :email)
end

このように記述することで、たとえadmin=trueというデータが送られてきても、Rails側で無視され、データベースには反映されません。

配列やネストされた構造への対応

実務では、単一の値だけでなく、チェックボックスの選択値（配列）や、関連するモデルのデータ（ネストされたパラメータ）を同時に保存するケースも多々あります。その際も、permitの書き方を工夫するだけで安全性を保てます。

# 複数の役割（roles）を配列で受け取り、さらにプロフィール情報も許可する場合
def complex_user_params
  params.require(:user).permit(
    :name, 
    :email, 
    roles: [], 
    profile_attributes: [:address, :phone_number]
  )
end

このように、データ構造に合わせて正確に許可リストを作成することが、プロのエンジニアへの第一歩です。デバッグ中に「値が保存されない！」と悩んだときは、まずこのStrong Parametersで許可し忘れていないかを確認する癖をつけましょう。ログ（development.log）を見れば、Unpermitted parameterという警告が出ているはずです。