Hello there, ('ω')ノ
具体的なURL例
たとえば社内ポータルでこんなURLがあったとします：
https://intra.example.co.jp/profile?id=123
この123を456や999に変えるだけで、他人のデータが見えてしまう場合はアウトです。
チェック手順① URLパラメーター変更
① ブラウザで該当URLを開く ② id= の値を手動で変えてみる
✅ 観察ポイント：
- 正しくアクセス制限されている場合 → エラーメッセージや403 Forbidden
- 脆弱な場合 → 他人の情報がそのまま表示
チェック手順② APIリクエストのパラメーター変更
① 開発者ツール（F12） → Networkタブを開く
② POSTやGETリクエストを確認
③ idやuser_id、tokenなどの項目を見つける
④ 値をコピーし、プロキシツール（Burp Suiteなど）で書き換え再送信
✅ 観察ポイント：
- 他人のデータが取得できるか？
- サーバー側からエラーや警告が返ってくるか？
よくあるパラメーター名リスト
非エンジニアでも以下のような項目を探すと効果的です。
- id
- user_id
- uid
- token
- session_id
- order_id
- file_id
特に注意すべきパターン
- 長いランダム文字列（token）があるのにチェックされていない場合
- 連番id（1, 2, 3…）の場合は特に注意！
実務での社内チェック例
① 勤怠管理システム
- https://intra.example.co.jp/attendance?user_id=1001
- → 他の番号を指定してデータが見えるか？
② 経費申請システム
- https://intra.example.co.jp/expense/receipt?id=3001
- → idを変えて他人のレシートデータが見えないか？
チェックリストまとめ
- [ ] URLパラメーターを手動で変えてテストしたか？
- [ ] APIリクエスト内のidやtokenを変更してみたか？
- [ ] 連番や予測しやすいidの扱いに注意したか？
- [ ] エラーや警告レスポンスを確認したか？
まとめ
- idやtokenの扱いは脆弱性チェックの基本ポイント
- 手動でもプロキシツール併用でもチェック可能
- 予測できる値＋アクセス制限なし＝IDORリスク大
Best regards, (^^ゞ
