マスアサインメント脆弱性は、具体的にどう起きますか。
フォームに無い項目、たとえば is_admin=1 を攻撃者が付け足して送信できるからです。画面に入力欄が無くても関係ありません。HTTPリクエストは自由に組み立てられます。
面接官が見ているのは名前だけでなく攻撃の流れを説明できるか。
これは「Laravel が標準で守ってくれるものと、自分で書く必要があるものの区別として正しいのはどれですか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- User::create($request->all()) のように、リクエストの中身をそのまま渡している
その通りです。画面に入力欄が無くても、HTTPリクエストは自由に組み立てられます。 - パスワードをハッシュ化せずに保存している
それも問題ですが別の脆弱性です。 - 大量のレコードを一括で insert している
「マス」は件数ではなく「まとめて代入する」の意味です。 - バリデーションを書いていない
関連はします。validated() を渡せば防げるので、対策としては同じ方向です。ただし脆弱性の本体は一括代入の方です。
面接官は何を見ているか
- リクエストの全項目をそのまま保存する形が原因だと言えた
- 画面に無い項目（is_admin 等）を送り込まれる例を出せた
- $fillable / $guarded による防御を説明できた
模範解答
User::create($request->all()) のように、リクエストの中身をそのまま渡す実装が原因です。攻撃者はフォームに無い項目、たとえば is_admin=1 を勝手に付け足して送信できます。画面上に入力欄が無くても、HTTPリクエストは自由に組み立てられるからです。防御は、モデルの $fillable に代入を許す列だけを列挙すること。あるいは $request->all() ではなく validated() を渡して、検証を通った項目だけに絞ります。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
参画したコードで $guarded = [] になっているモデルを見つけました。どうしますか。