Hello there, ('ω')ノ
🛡️ 1. APIドキュメントの管理
✅ 意図しない公開を防ぐ
- APIが社内用や制限された用途向けである場合、ドキュメントのアクセス制限を必ず設定。
- 例:
/swagger.json,/openapi.yamlをインターネット上に公開しない。
✅ ドキュメントは常に最新に保つ
- APIの仕様変更後は必ずドキュメントを更新。
- 正当なペンテスト担当者がすべてのエンドポイントを把握できるようにすることが、逆に防御力を高める。
🔀 2. HTTPメソッドのホワイトリスト化
- 各エンドポイントに対して、許可されているHTTPメソッドを明示的に制限する（例:
GET,POSTのみ）。 - 意図しない
PUT,DELETE,PATCHが有効になっていないかを確認。
🧾 3. コンテンツタイプの検証
- 各リクエスト・レスポンスに対して、想定されたContent-Typeだけを受け付けるように検証。
- 例:
application/jsonを期待するAPIでapplication/xmlが来た場合は拒否。
❌ 4. エラーメッセージを汎用化する
- 攻撃者にとってエラーメッセージは情報の宝庫。
- スタックトレースやDBのエラー、具体的なパラメータ名を含むエラーは表示しない。
- ユーザーには「不正なリクエストです」などの汎用エラーを返す。
🕰 5. すべてのAPIバージョンに保護対策を適用する
- 現在使っているAPIバージョン（例：
/v3/）だけでなく、旧バージョン（/v1/,/v2/）も含めて同じセキュリティポリシーを適用。 - 古いAPIが開発者の盲点になりやすく、攻撃の入り口になることが多い。
🔐 6. Mass Assignment（マスアサインメント）対策
✅ ホワイトリスト制御を実装する
- 更新可能なプロパティだけを明示的に指定してバインド：
allowed_fields = ['username', 'email'] user.update(request.only(allowed_fields))
✅ ブラックリストではなくホワイトリストが原則
isAdmin,role,password,balanceなどの重要プロパティは絶対に更新不可にする。
✅ まとめ：安全なAPIを構築するために
| 項目 | 対策 |
|---|---|
| ドキュメント管理 | 非公開APIはドキュメントも制限／常に最新状態を維持 |
| メソッド制御 | 明示的に許可されたメソッドのみ使用 |
| コンテンツタイプ | Content-Type を検証し、想定外の形式を排除 |
| エラーメッセージ | 汎用的なメッセージに統一し、内部構造を漏らさない |
| バージョン管理 | すべてのAPIバージョンに対してセキュリティ対策を適用 |
| Mass Assignment対策 | 更新可能プロパティをホワイトリストで明示 |
APIのセキュリティは、「公開する」だけで終わりではなく、継続的な管理と意図的な制限によって守られます。設計段階から「どう悪用されうるか？」という視点で構築することが、攻撃者を遠ざける最大の防御になります。
Best regards, (^^ゞ
