参画したコードで $guarded = [] になっているモデルを見つけました。どうしますか。
何も保護しない設定なので危険と認識します。ただしいきなり fillable へ切り替えると、列挙漏れした項目が静かに保存されなくなります。影響範囲を洗ってから段階的に狭めます。
面接官が見ているのは既存コードの危険を見つけた時の現実的な動き方。
これは「マスアサインメント脆弱性は、具体的にどう起きますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- まず全項目を渡している箇所があるか調べる。無ければ緊急度は下がる
危険度の判定を先にするのが正解です。$fillable の整備はテストを用意した上で別途進めます。 - すぐに $fillable に書き換えてコミットする
方向は正しいのですが、列挙漏れした項目が保存されなくなり、既存機能が静かに壊れます。順序を踏んでください。 - 危険なので、その場で該当モデルを使う機能を止める
実害の有無を確認する前に機能を止めるのは過剰です。まず調べます。 - 既存コードの方針なので、そのままにしておく
危険な設定だと認識した以上、放置は選べません。少なくとも共有はします。
面接官は何を見ているか
- $guarded = [] は全列を代入可能にする設定だと理解している
- いきなり $fillable に変えると既存機能が壊れうると指摘できた
- 実際に危険な経路があるかを先に調べる、という順序を言えた
模範解答
$guarded = [] は「何も保護しない」なので、まず危険な設定だと認識します。ただし、いきなり $fillable に切り替えると、列挙漏れした項目が保存されなくなって既存機能が静かに壊れます。「静かに」というのが厄介で、$fillable に無い属性は既定では例外にならず黙って捨てられます。エラーが出ないので気づけません。
順序としては、まずそのモデルに全項目を渡している箇所があるかを調べる。なければ緊急度は下がります。あれば、そこを validated() に直すのが先。$fillable の整備はテストを用意した上で別途進めます。
移行中の安全網として、AppServiceProvider の boot でModel::preventSilentlyDiscardingAttributes() を有効にする手があります。$fillable に無い属性を渡したら例外になるので、列挙漏れが開発中に露見します。本番で有効にすると落ちるので、環境で切り分けます。
危険度の判定と修正順序を、勢いで飛ばさないことが大事です。