2026.05.01

【API・GraphQL編】エンドポイント列挙とBOLAの世界｜CTF思考フレームワーク #09

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　認証・セッション編　#09 / 公開中 10記事　→　シリーズ一覧を見る →

モダンなWebサービスは、画面の裏でAPIをモリモリ叩いてます。REST、GraphQL、gRPC…。フロントエンドが綺麗でも、APIエンドポイントが無防備だと「画面を経由しない直接攻撃」が刺さります。今回はAPI層の急所を攻撃者目線で見ていきましょう🔌

REST APIとGraphQL、それぞれの「攻撃者からの見え方」を整理していきます。

難易度：★★☆（中級）

このシリーズは「攻撃者の思考をなぞる」ことが目的。手を動かさなくても読み物として理解できるレベルです👍

画面の裏で動いてるAPIは、フロントの認可を完全にスキップできる入り口なんだよ🔌

この記事の難易度

難易度：★★☆（やさしめ）　／　所要：8〜10分　／　前提：CTF思考フレームワーク #08

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まずはNetworkタブでAPIリクエストを丸ごと観察。エンドポイント名・パラメータ・認証ヘッダがヒント！

特に「過剰な情報を返す」のはAPIあるある。画面で表示してない項目もJSONには含まれてた、というケースは本当に多いです。

/api/v1/users/123 のようなID直指定パスは要注意。GraphQLなら __schema でintrospectionが有効か確認します🔍

GraphQLってスキーマを丸ごと聞けるから、観察フェーズで攻撃マップが完成しちゃうんだ…😨

🤔 仮説フェーズ：攻撃者は何を考える？

API層の典型的な穴は4パターンあるよ。

攻撃者の仮説。

🔢 仮説①：BOLA（Broken Object Level Authorization）

/api/orders/1001のIDを1002に書き換えると他人の注文が見える。OWASP API Top10の1位の脆弱性です。

📋 仮説②：イントロスペクション開放

GraphQLで__schemaクエリが本番でも通るなら、全エンドポイント・全フィールドが丸見え。攻撃マップを自動生成できます。

💣 仮説③：ネストクエリでDoS

GraphQLはuser{posts{comments{user{posts{...}}}}}のように深いネストを投げるとサーバが爆発する。深さ制限が必須。

🪄 仮説④：マスアサインメント

POSTのbodyに"role":"admin"を勝手に追加すると、権限まで一緒に更新されるケース。サーバ側で許可フィールドのホワイトリスト化が必要。

APIはフロントを経由しない＝UI制約がない、というのが攻撃者にとっての旨味。「画面に出ない情報」も平気でJSONに混ざってます。

「画面に出るデータ＝APIが返すデータ」じゃないってことだね。フロントを信頼しないのが鉄則！

🔬 検証フェーズ：どうやって確かめる？

検証はcurlかPostmanで直接APIを叩くのが基本。画面を経由しない！

検証はこのステップで進めます。

IDを±1ずらす、roleを足す、深いネストを送る…って順番にやればいいんだね🧪

⚔️ 攻撃フェーズ：実際の手口

API攻撃の本命はこの3つ。

ここからは実戦シナリオを見ていきます。

① BOLAでデータ横断アクセス

IDをインクリメントしながらAPIを叩くだけで、全ユーザーの注文・住所・カード履歴が抜ける。実害が最も大きい。

② GraphQLイントロスペクションでスキーマ全採取

__schemaクエリで全クエリ・全ミューテーション・全引数を一気に取得。次の攻撃の精度が爆上がり。

③ マスアサインメントで権限昇格

プロフィール更新APIに"is_admin":trueを混ぜるだけで管理者になれることもある。実装の油断が命取り。

CTF{authorize_per_object_not_per_user}

共通する原則は「APIは画面の裏でも認可を毎回確認すべき」。エンドポイントごとに、リソースごとに、所有権をチェック。

🛡️ 防御フェーズ：どう守る？

守る側は3レイヤーを必ず徹底！🛡️

API層の必須対策。

🔐 オブジェクト単位の認可チェック

すべてのAPIエンドポイントで「このユーザーがこのIDのリソースにアクセスしていいか」をサーバ側で必ず検証。フロント側のフィルタリングは無意味。

🚫 GraphQL本番環境のintrospection無効化

本番では introspection: false にする。加えてクエリ深さ制限と複雑度スコア制限でDoSも防ぐ。

📋 マスアサインメント対策（ホワイトリスト）

リクエストボディから許可されたフィールドだけを抽出して処理する。strong parameters や DTO パターンを活用。

APIは「画面の裏」じゃなくて独立したアプリとして守らないとダメなんだね💪

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

現場でよく見かけるミスはこんな感じです。

「JWTで認証してる＝安全」と思い込み、認可チェックを省略。
IDを連番で発行して、攻撃者にIDを推測されやすくする。
GraphQLでイントロスペクションを本番でも有効にしたまま。
レスポンスに不要な内部フィールドを含める（password_hash、internal_notes など）。
古いAPIバージョン（v1）を放置して、新バージョン（v2）の対策が反映されない。
マイクロサービス間の内部APIを、ネットワーク的に保護せず公開。

🧰 ツール早見表

ここで使うツールを早見表にまとめました。

ツール	用途	ひと言
Postman / Insomnia	API手動テスト	正規ユーザーとしての挙動把握
Burp Suite	プロキシ・改ざん	API攻撃でも主役
GraphQL Voyager	スキーマ可視化	イントロスペクション結果を図で
ffuf / wfuzz	エンドポイント列挙	/api/v1/* のディレクトリ総当たり