IDORは「認証の成功」という甘い罠に潜んでいる：設計で叩き潰す認可の鉄則
「ログインできているから大丈夫」。もしチームのメンバーがそんなことを口にしたら、すぐにそのコードを止めてください。
多くのエンジニアが陥る罠、それが IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照） です。これは単なるバグではなく、設計思想の欠陥です。認証（Authentication）を通過したユーザーが、本来アクセス権のない他人のリソースを「IDを書き換えるだけ」で盗み見たり、操作したりできてしまう。この脆弱性は、今も昔もサイバー攻撃者が最も好む「金脈」の一つです。
1. なぜIDORは「認証」をすり抜けてしまうのか？
IDORの本質は、アプリケーションが「誰が操作しているか（認証）」はチェックしていても、「その人がそのリソースを触る権利があるか（認可/Authorization）」を確認していない点にあります。
【攻撃のPoC：IDを書き換えるだけの単純作業】
例えば、ユーザーAが自身の請求書を閲覧するAPIがあるとします。
`GET /api/v1/invoices/1001`
攻撃者は、この `1001` というIDを `1002` に書き換えてリクエストを送ります。もしサーバー側が「ログイン中か？」だけを確認し、「1002番の請求書はユーザーAのものか？」を確認しなければ、攻撃者は他人の請求書を無限にダウンロードできてしまうわけです。
これは非常に低コストで、かつ自動化もしやすく、WAFをすり抜けることも多いため、非常に危険です。
—
2. IDORを完全に封じ込める実装パターン
IDORを防ぐ唯一の道は、「すべてのリソースアクセスにおいて、クエリのたびに認可チェックを強制する」ことです。これをフロントエンドやフロントコントローラーに任せてはいけません。DBへクエリを投げる直前のモデル層（サービス層）で担保します。
【Python (FastAPI) による実装例】
認可ロジックをデコレータや依存関係注入（Dependency Injection）で強制するのが現代的な設計です。
from fastapi import Depends, HTTPException, status
from sqlalchemy.orm import Session
認可ロジックを分離したセキュアな関数
def get_invoice_if_authorized(
invoice_id: int,
current_user: User = Depends(get_current_user),
db: Session = Depends(get_db)
):
# 【重要】ID検索時に必ず「所有者ID」を条件に加える
invoice = db.query(Invoice).filter(
Invoice.id == invoice_id,
Invoice.owner_id == current_user.id # ここで認可を強制する
).first()
if not invoice:
# 存在しない場合、404にするか403にするかは設計次第だが、
# IDORを隠蔽するために「存在しない」と見せるのが定石
raise HTTPException(status_code=404, detail=”Resource not found”)
return invoice
@app.get(“/invoices/{invoice_id}”)
def read_invoice(invoice: Invoice = Depends(get_invoice_if_authorized)):
return invoice
【JavaScript (Node.js/Express) でのポイント】
Expressの場合、ミドルウェアでリクエストIDを検証する際、必ずDBの所有者カラムと照合してください。
// 認可チェック用ミドルウェア
const authorizeOwner = (model) => async (req, res, next) => {
const resourceId = req.params.id;
const userId = req.user.id;
// リソースを特定しつつ、所有者を確認
const resource = await model.findOne({
where: { id: resourceId, ownerId: userId }
});
if (!resource) {
return res.status(403).json({ error: “アクセス権限がありません” });
}
req.resource = resource;
next();
};
// ルート定義
app.get(‘/api/v1/invoices/:id’, authenticate, authorizeOwner(Invoice), (req, res) => {
res.json(req.resource);
});
—
3. 実践的な運用のための3つの防衛線
コードレベルの修正に加えて、インフラと設計思想で多層防御を固めます。
1. 推測困難なID（UUID）の採用
連番ID（1, 2, 3…）は攻撃者に次を推測させます。公開IDには `UUID v4` や `ULID` を使用し、リソースの存在を外部から推測不能にしてください。ただし、UUIDを使っても「認可ロジック」の代わりにはなりません（あくまで防御の二重化です）。
2. 「暗黙の認可」を禁止するコードレビュー
レビュー時には「このDBクエリに `user_id` または `owner_id` の条件は含まれているか？」を必ず確認します。`WHERE id = ?` だけで引いている箇所があれば、即座に修正対象です。
3. IDORスキャンをパイプラインに組み込む
開発ステージにおいて、Burp SuiteやZAPなどのツールを用い、異なるユーザーのトークンを使用して他のリソースへアクセスする自動テストをCI/CDに組み込んでください。「動けばいい」ではなく「権限外は絶対に動かない」を自動テストで保証するのです。
最後に：エンジニアとしての誇り
IDORは、システムがどれだけ複雑になっても、「開発者が権限管理を面倒くさがった時に発生する」という点で、極めて人間臭い脆弱性です。
「面倒な認可処理を共通化し、DBクエリに強制的に所有者条件を付与する」。この泥臭い積み重ねこそが、最高峰のセキュリティを支えるエンジニアの矜持です。明日からのコードレビューで、ぜひ「このIDへのアクセス、本当にそのユーザーの権限内か？」と問いかけてみてください。それだけで、あなたのプロダクトの安全性は一段階引き上がります。
コメント