APIの「玄関」に鍵をかけよう：Mass Assignment（過剰なデータ割り当て）を防ぐための基本
こんにちは。セキュリティの世界へようこそ。今日は、API開発において非常に重要で、かつ「ついやってしまいがち」な落とし穴、Mass Assignment（過剰なデータ割り当て）についてお話しします。
「API」と聞くと難しく感じるかもしれませんが、私たちの身近な「家の防犯」に例えると、その怖さと対策が驚くほどクリアに見えてきますよ。
—
1. 「Mass Assignment」って、何が怖いの？
例えば、あなたが自分の家の「住所変更届」を役所に郵送すると想像してください。
本来なら「新しい住所」だけを書けばいいはずなのに、もしその書類に「この家の合鍵の持ち主リスト」や「家の資産価値」まで書き込める欄があったらどうでしょう？
悪意のある人物が、その書類の隙間に「合鍵の持ち主に俺の名前を追加しておくか…」とこっそり書き込んだら、役所の担当者がそれをそのままシステムに登録してしまう。これが、APIにおけるMass Assignmentの正体です。
なぜこれが起きてしまうのか？
開発者が「ユーザーが入力したデータを、そのままデータベースのモデルに保存する」という楽な実装をしてしまうからです。
// 危険なコードの例（絶対にやっちゃダメ！）
// リクエストの全データをそのまま保存してしまっている
const user = await User.findById(req.params.id);
user.update(req.body); // これが「住所変更届に合鍵リストも書き込める」状態
await user.save();
これだと、攻撃者は {"name": "田中", "is_admin": true} のようなリクエストを送るだけで、勝手に自分を「管理者（is_admin）」に昇格させてしまう可能性があるんです。
—
2. 防御の鉄則：DTO（Data Transfer Object）を使おう
では、どうすればいいのでしょうか？ 答えはシンプルです。「必要な情報以外は受け取らない」こと。
家で言えば、住所変更専用の「小さな窓口」を通すイメージです。その窓口には「住所」を書く欄しかないので、どんなに悪意のあるメモを書いても、そこには一切書けないようになっています。
この「住所変更専用の窓口」にあたるのが、DTO（データ転送オブジェクト）という考え方です。
実装のヒント（DTOによるフィルタリング）
リクエストから直接モデルを更新せず、あらかじめ許可した項目だけを抜き出す仕組みを作りましょう。
// 良い実装の例
// 更新を許可する項目だけを明示的に指定する
const updateData = {
address: req.body.address,
phone: req.body.phone
};
// これなら、もしリクエストに ‘is_admin’ が含まれていても無視される！
await User.update(updateData, { where: { id: req.params.id } });
たったこれだけのことですが、セキュリティの強固さは段違いになります。
—
3. 「見えない場所」を守るための3つのステップ
これから開発現場で気をつけるべきポイントを、3つのステップにまとめました。
1. 「丸投げ」を禁止する
req.body をそのままデータベースの保存メソッドに渡すコードを、今すぐ検索してみましょう。もし見つかったら、それがあなたのシステムの「鍵の開けっ放し」です。
2. DTOで「許可リスト」を作る
受け取ってもいい項目だけをホワイトリスト化しましょう。ブラックリスト方式（これはダメ、あれもダメ）だと、後から新しい項目が増えた時に防ぎきれません。
3. バリデーション（入力チェック）を厳格に
「住所」の欄には住所らしい文字数や形式以外は受け付けない、という門番を置いてください。
—
最後に：セキュリティは「泥棒とのいたちごっこ」ではなく「習慣」
セキュリティ対策は、何か特別な魔法を使うことではありません。「自分の書いたコードが、悪意ある人の手に渡ったらどう使われるか？」と、一度立ち止まって考える。その「想像力」こそが、最強の防犯ツールです。
最初は面倒に感じるかもしれませんが、一度この「DTOによるフィルタリング」を習慣化してしまえば、あなたはもう「セキュリティに穴を作らないエンジニア」の仲間入りです。
一歩ずつ、着実に。あなたの書くコードが、誰かの大切な情報を守る強力な盾になることを応援しています。
また次回の記事で、より深い「現場の知恵」をお伝えしますね！
コメント