IDORは「バグ」ではない。それは「設計の怠慢」である
現場のコードレビューで、未だに「連番のIDをAPIの引数にそのまま投げる」設計を目にするたびに、私はセキュリティの最前線に立つ者として深い溜息をつく。IDOR（Insecure Direct Object Reference）は、OWASP Top 10の常連だが、その本質は技術的な不具合ではなく、「境界防御の論理的欠落」に他ならない。
多くの開発者が、認証（Authentication）と認可（Authorization）を混同している。ログインしているという事実だけで、そのユーザーが「リソースX」を操作する権利があると思い込む。これが、攻撃者にとっての最大の隙だ。
1. IDORの深層心理とプロトコルの脆弱性
IDORの根本原因は、RESTful APIの設計思想と認可ロジックの乖離にある。攻撃者は、`GET /api/v1/user/1001/invoice` というリクエストを投げた際、セッションIDを偽装するのではなく、単にIDを `1002` に書き換える。
ここで注目すべきは、パケットレベルの挙動だ。多くのWebフレームワークにおいて、このIDはデータベースの主キー（Primary Key）と直結している。攻撃者は、単なる連番の推測だけでなく、インクリメンタルなID構造から、システムの総レコード数や、登録の時系列までもを逆算できる。これは情報の漏洩（Information Disclosure）という、より深い脆弱性の入り口となる。
2. 「認可」のガードレイル：疎結合な認可エンジンの構築
「リソースにアクセスする前に、所有権を確認せよ」という教条は、コードのあちこちに散らばるべきではない。そんなことをすれば、修正漏れが必ず発生する。
実務レベルで推奨するのは、ポリシーベースの認可（ABAC: Attribute-Based Access Control）をミドルウェア層で強制することだ。以下に、Go言語によるセキュアな認可ロジックの設計例を示す。
// 安全な認可のアーキテクチャ例
func GetInvoiceHandler(w http.ResponseWriter, r http.Request) {
// 1. セッションからユーザーIDを抽出（認証済みの前提）
userID := getAuthenticatedUserID(r)
// 2. パスパラメータから対象リソースIDを抽出
invoiceID := mux.Vars(r)[“invoice_id”]
// 3. 【重要】データベースへの直接アクセス前に認可チェックを実行
// 単に「誰か」ではなく「誰が」「何を」所有しているかを結合してクエリを構築
allowed, err := CheckAuthorization(userID, invoiceID)
if err != nil || !allowed {
// 攻撃の予兆としてログを詳細に出力し、403を返す
log.Printf(“セキュリティ警告: ユーザー %s が権限のないリソース %s にアクセスを試行”, userID, invoiceID)
http.Error(w, “Forbidden”, http.StatusForbidden)
return
}
// 4. 認可が完了した後にのみ実データを取得
data := fetchInvoiceData(invoiceID)
json.NewEncoder(w).Encode(data)
}
このコードの肝は、認可ロジックが `Data Access Layer` に到達する前に「バリケード」を張っている点にある。さらに深掘りするなら、IDに予測不可能な `UUID v4` や `Hashids` を用いることは最低限の礼儀だ。
3. 生成AI時代のIDOR：プロンプトインジェクションとの交差点
最近の脅威トレンドとして見過ごせないのが、LLMを搭載したアプリケーションにおけるIDORだ。AIエージェントに「請求書を要約して」と指示したとき、AIがバックエンドのAPIに対して、認可チェックをバイパスして全IDを舐め回すような挙動をとるケースが散見される。
これに対する防衛策は、「最小権限のコンテキスト注入」だ。AIがAPIを叩く際、AIのセッションコンテキストに「このユーザーがアクセス可能なリソースIDリスト」を事前にフィルタリングして渡す必要がある。AIに対するガードレイルとして、入力の検証だけでなく、「AIが何を操作したか」の出力フィルタリング（出力側の認可チェック）を実装するアーキテクチャが、次世代のスタンダードとなる。
4. 監査の観点：私たちが追い求めるべき「透明性」
チーフホワイトハッカーとして、私はチームにこう要求する。「コードを見れば、どこで認可が行われているか一目で分かるようにせよ」と。
- 静的解析（SAST）のカスタマイズ: `db.Find()` のようなメソッドが、認可関数を通さずに呼び出されていないかをCI/CDパイプラインで自動検知する。
- 動的解析（DAST）の強化: 権限の異なる2つのアカウントを自動でログインさせ、AのアカウントでBのリソースを叩く「クロス権限テスト」を全APIエンドポイントで実施する。
結びに代えて
IDORを防ぐことは、単なるパッチ当てではない。それは「誰が何にアクセスできるか」というビジネスの定義を、技術という言語で厳格に記述し続ける作業だ。
世界中の攻撃者は、今日もあなたのAPIの連番を書き換え、あるいはプロンプトを注入して入り口を探している。しかし、堅牢な認可のアーキテクチャという「不可視の城壁」があれば、彼らはその壁に阻まれ、あなたのシステムの脆弱性を突くことは叶わない。
セキュリティとは、完璧を目指すことではない。「攻撃者の手間をコストに見合わないレベルまで引き上げる」という、絶え間ないエンジニアリングの積み重ねなのだ。
コメント