/mypage 公開スケジュールAPIのリスク整理（軽量対策）

目的

/mypage の公開トークンを使って操作できる公開スケジュールAPIについて、想定リスクと被害内容を整理し、公開APIを維持したまま被害を抑える軽量対策を明文化する。

対象範囲

• GET /api/v1/public/candidates/:token
• GET /api/v1/public/candidates/:token/schedules
• POST /api/v1/public/candidates/:token/schedules
• DELETE /api/v1/public/candidates/:token/schedules/:scheduleId
• /mypage の公開URL（/mypage/<public_token>）

前提

• public_token は「知っている人がアクセス・操作できる」認可トークンである。
• 公開APIは継続する方針であり、UXを大きく変えずに対策する。

用語

• 公開トークン: URLに埋め込まれた認可情報。知っている人が操作できる。
• 変更系API: POST/DELETE のようにデータを変更する操作。
• 濫用/スパム: 大量作成・削除・連打による不正利用。
• レート制限: 一定時間内のリクエスト回数を制限する仕組み。

現状の挙動（要点）

• public_token は UUID 形式を検証している。
• scheduleId は UUID 形式を検証している。
• GET は日付範囲（92日以内）を検証している。
• POST は ISO8601（タイムゾーン必須）で start < end を必須化し、最大12時間、過去不可、90日以内を検証している。
• POST は候補者単位の「空き」総数上限（200件）と重複・重なり禁止を適用している。
• POST/DELETE は token + IP 単位のレート制限（20/min, 100/day）を適用している。
• DELETE は失敗時に同一エラーを返し、ID推測を抑制している。

リスク評価（簡易）

• 完全性: 高
  理由: トークンが漏れると第三者が「空き」を作成・削除できる。
• 可用性: 中〜高
  理由: 大量作成や連打で UI/運用が破綻しやすい。
• 機密性: 中
  理由: 公開情報前提だが、誤操作や改ざんにより二次被害が起きる。
• 検知性: 低
  理由: 正常利用と攻撃の区別が難しく、ログで発見しにくい。

具体的な被害内容

• 大量の「空き」作成により候補者のスケジュールが汚染される。
• 「空き」削除で本来の可用性が失われ、機会損失が発生する。
• 不正な日時（過去や極端な未来）でUIや集計が崩れる。
• API連打により一時的な過負荷が起き、他機能にも影響する。

典型的な濫用シナリオ

• 漏えいしたトークンを使って自動化スクリプトで大量作成。
• 同一候補者に対する短時間の DELETE 連打で空きを消す。
• 異常な時刻（例: start_time が文字列のまま）を送り続ける。

推奨する軽量対策（優先順）

• 入力検証の強化
  start_time / end_time を ISO8601（タイムゾーン必須）でパースし、start < end を必須化する。end-start の上限（12時間）や、過去/90日超の拒否を入れる。
• 候補者単位の上限制御
  「空き」総数上限（200件）と重複・重なり（overlap）禁止を追加する。
• レート制限
  token + IP 単位で POST/DELETE の回数を制限し、閾値超過は 429 を返す（20/min, 100/day）。
• 監視とアラート
  作成/削除の回数が閾値を超えたら通知する。public_token はログ上で必ずマスクする。
• エラーレスポンスの平準化
  変更系ではエラー詳細を絞り、攻撃者が手がかりを得にくくする。

残リスク

• トークン漏えいが発生した場合、一定量の不正操作は完全には防げない。
• 変更系APIを公開し続ける限り、「トークン=権限」の性質は残る。

判断ポイント

• 変更系APIを残す前提なら、最低限「入力検証・上限制御・レート制限・監視」は必須。
• これ以上の安全性が必要な場合は、署名付き短期トークンなどの中程度対策へ移行する。