目次
プロフィール画面には名前と自己紹介しかないのに、送信内容へ別の項目を加えると権限まで変わる。マスアサインメントは、入力を便利にモデルへ渡す処理が、変更してよい項目の境界まで広げてしまう問題です。画面に入力欄がないことは、サーバー側でその値を受け付けない証拠にはなりません。
本記事は2026年10月18日にOWASPとLaravelの一次資料を確認した実装解説です。特定のサービスで新たな被害が起きたという速報ではありません。会員サイトと申請処理は仮想例で、点検表と改修の進め方は本サイトの提案です。
スポンサーリンク
操作の許可と項目の許可を分ける
既存のAPI認可の記事では、誰がどの対象へ操作できるかを扱いました。今回は対象を正しく選べていても、その中のどの値を更新してよいかという、入力から保存への境界を掘り下げます。自分のプロフィールを更新できる利用者でも、自分の役割や契約先を自由に変更してよいわけではありません。
OWASPは、要求の値をオブジェクトへ自動的に結び付ける仕組みが、意図しない属性の更新につながることを説明しています。攻撃者がソースコードを読めなければ安全という問題ではなく、項目名が知られても制限が機能する設計が必要です。
レビューでは、呼び出した人、対象の所有関係、実行する操作、変更する項目を分けます。正しいログインやCSRFトークンを確認できたことを、要求に含まれる全項目を信頼する理由にはしません。
出典：OWASP Mass Assignment Cheat Sheet。
要求全体をモデルへ渡す箇所から探す
フォームやJSONを受け取った後、要求全体をモデルの生成・更新メソッドへ渡していないかを探します。共通の更新関数があるなら、どの画面とAPIから使われるかも確認します。名前にsaveやupdateが含まれるかだけでなく、入力を内部オブジェクトへ移す処理を追うことが重要です。
モデルに列を追加した後、古い汎用の保存処理が新しい列も受け付けるようになる場合があります。禁止する項目を列挙する方式だけだと、新しい機微な項目を禁止し忘れる可能性があります。本サイトは、通常の入力では更新してよい項目を明示的に選ぶ方式を勧めます。
アプリの管理用モデルを、外部入力を受ける器としてそのまま兼用しないことも有効です。DBの内部構造と公開APIの入力構造を一対一にしなければ、内部の機能追加がそのまま外部の更新権限へ波及するのを抑えられます。
スポンサーリンク
用途別のDTOと許可リストを使う
DTOは処理間で受け渡すデータの形を定める方法です。プロフィール更新には名前と自己紹介、管理者の権限変更には別の入力というように、用途ごとの受け取り方を用意します。DTOという名前のクラスを作るだけで安全になるのではなく、内部モデルへ渡す項目を限定することが目的です。
文字列の長さや形式を検証する処理と、更新を許可する項目を選ぶ処理も区別します。値が正しい形式の管理者フラグであっても、一般会員へ変更を許可していなければ保存すべきではありません。型の検証に合格した項目を全部通す設計にしないでください。
所有者や組織のID、課金額、作成者、承認状態などは、認証情報や業務処理からサーバー側で決める候補です。ただし、すべてのサービスで同じ項目が変更禁止とは限りません。業務で変更が必要なものは、その操作と承認を別に定義します。
入れ子のJSONと配列も同じ粒度で選ぶ
最上位の設定項目だけを許可しても、その中へ権限や連携情報を自由に入れられるなら境界が粗過ぎます。設定オブジェクト全体を保存する前に、許可する子項目と値の型を定義します。配列の各要素についても、本人が変更できる対象かを別に確認します。
Laravelの公式資料は、Eloquentの一括代入の保護と、JSON列への代入での指定を説明しています。利用している版の機能を確認し、ある設定方法の例を別の版へそのまま当てはめないでください。保護を解除する設定を採用する場合も、渡す配列を自分で限定する責任が残ります。
未知の項目を拒否するか、無視するかもAPIの契約として決めます。無視する方式は互換性に役立つ場合がありますが、開発者が「保存できた」と誤解しやすくなります。開発環境で検知し、本番では秘密を出さずに運用上の原因を追えるようにします。
関連する公式仕様：Laravel EloquentのMass Assignment。
スポンサーリンク
一般画面と管理画面で保存処理を混在させない
管理者だけが使う編集画面では、一般会員より多くの項目を変更する必要があります。それでも、管理者かどうかの確認を画面表示だけに置かず、保存する側で実施します。管理用の広い許可リストを、一般のプロフィール更新で使い回さないようにします。
仮想の申請システムなら、申請者による本文修正と、担当者による承認を別の操作にします。本文を直す要求に承認状態が含まれても、それだけで承認は完了しません。承認時には権限、現在の状態、必要な業務条件を検証します。
一括インポート、外部連携、管理バッチも例外ではありません。送信元が社内にあるという理由だけで、入力全体へ内部モデルの全権限を与えないことが重要です。自動化の利便性と、書き換えてよい項目の範囲を分けて設計してください。
仮想の会員編集を使った確認手順
テスト用の一般会員と管理者を用意し、一般会員が自分の名前だけを更新する正常系を先に確かめます。次に、その要求へ管理用の項目、他組織のID、想定外の入れ子の項目を追加します。いずれも自分が管理する隔離環境の架空データだけで試します。
確認するのは応答コードだけではありません。名前の変更が成功したときに、権限、所有者、承認状態が変わっていないかをDBや正規の参照機能で照合します。要求全体を拒否する仕様なら、許可された項目も部分的に保存されていないことを確かめます。
更新対象の同時変更にも注意します。承認処理の直前に、別画面で所有者や重要な値が変わる可能性があるなら、保存時の状態を確かめる条件が必要です。マスアサインメントを防いだだけで、業務の順序や競合まで自動で解決するわけではありません。
| 入力例 | 設計する扱い | 保存後の確認 |
|---|---|---|
| 名前と自己紹介 | 定めた型と範囲で受け付ける | 本人の許可された項目だけが変わる |
| 管理用の権限項目 | 通常の更新では受け付けない | 権限と認証手段が変わらない |
| 別組織の所有者ID | 外部入力だけで決定しない | 所属とデータの境界が維持される |
| 未知の子項目 | 仕様に従い拒否または無視 | 設定全体の上書きが起きない |
既存コードを段階的に直す
まず外部から到達できる更新処理を列挙し、権限や金額に影響するものから優先します。次に用途別の入力と許可リストを作り、保存直前に渡る値を限定します。公開する入力項目を急に削る場合は、利用中のクライアントと連携先への影響も確認します。
移行中の監視では、拒否した項目名や操作の種別を必要な範囲で記録します。パスワードや個人情報を含む要求本文を丸ごと残さないようにします。問い合わせには時刻と安全な相関情報を使い、秘密を送らせない手順を用意します。
古い入口を残す場合、その入口にも同じ保護が届いているかを確認してください。新しいAPIだけを修正しても、旧フォームやバッチ経由で同じモデルが自由に更新できれば、境界は閉じていません。
列の追加とAPI変更を同じレビューで扱う
運用後に重要なのは、新しいDB列が増えたときの確認です。その列を誰が変更できるか、入力へ公開する必要があるか、既存の許可リストへ加えるべきかを、スキーマ変更のレビューに含めます。列を追加するだけの変更でも、入力と保存の関係は再確認します。
自動生成されたAPIや管理画面を採用する場合は、生成結果がどの項目を公開するかを確認します。便利な足場として使っても、業務上の許可条件まで正しく補ってくれると決め付けないでください。生成設定と、手で追加した例外処理を同じ基準で点検します。
権限のテストは、ボタンが表示されないことの確認だけで終わらせません。入力を直接変えたときにも許可していない項目が保存されないことを、回帰テストの条件にします。項目を追加しても検査が維持される構造が、安全な変更を続ける助けになります。
スポンサーリンク
許可リストに載っていても毎回変更できるとは限らない
項目の許可リストは、業務上の条件をすべて表すものではありません。たとえば配送先は注文確定前なら本人が変更できても、出荷後は別の手続きが必要かもしれません。項目の選別と、現在の状態で変更できるかの確認を分けて実装します。
同じ入力モデルを利用しても、承認の段階や担当者の役割で条件が違う場合は、その判断を保存処理へ明示します。型が正しく、項目名が既知であることを、業務上の変更を許可したことへ読み替えないようにします。
受け入れ条件を項目単位で書く
改修完了の条件は、すべての要求がエラーにならないことではありません。正規の入力が正常に保存され、不正な項目が内部状態を変えず、管理者向けの操作には必要な認可が残ることです。これらを別々に確認します。
未知の項目が大量に送られた場合の処理量や、エラーメッセージの内容も点検します。保存できない内部項目を細かく列挙して返す必要はありません。一方で、運用者が入力仕様の不一致を調べられる最低限の記録は必要です。
入力モデル、更新する項目、業務の認可を分けると、画面やAPIが増えても変更範囲を説明しやすくなります。汎用の一括保存に任せていた判断を、用途ごとの明示的な契約へ戻すことが、マスアサインメント対策の中心です。
スポンサーリンク
参考資料
以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。
