API脆弱性診断とは｜Webアプリ診断との違いとBOLA・BFLA

「Webアプリケーションの脆弱性診断は毎年受けている。だからAPIも当然カバーされているはずだ」

もしそう考えているとしたら、危険な思い込みかもしれません。多くのWebアプリ脆弱性診断は、APIを部分的にしか見ていないか、あるいは「画面から呼ばれているAPIを、画面診断のついでに通っている」だけのことが少なくないからです。

近年、攻撃者の主戦場は画面（ブラウザで見るWebページ）から、その裏で動くAPIへと移っています。スマホアプリ、SPA（モダンなWebアプリ）、システム間連携——これらはすべてAPIの上で動いており、攻撃者にとってAPIは「画面という覆いのない、むき出しの入口」だからです。

この記事では、API脆弱性診断とは何か、Webアプリ診断と何が違うのか、そして代表的なAPIの脆弱性を、専門用語をかみ砕いて解説します。

そもそもAPIとは何か（と、なぜ攻撃対象になるのか）

APIを一言でいうと、システムとシステムが直接データをやり取りするための窓口です。

私たちが普段見ているWebページは、人間向けに整形された「画面」です。一方APIは、その画面の裏側で「注文データをください」「この会員の情報を返して」といったやり取りを、システム同士が機械的に行うための入口です。スマホアプリ、SPA、外部サービス連携は、ほぼすべてこのAPIを通じて動いています。

ここに攻撃者にとっての旨みがあります。

• 画面には「ボタンを押せる順序」「入力できる文字数」といった人間向けの制約がありますが、APIを直接叩けばその制約を無視できます

• 画面は複数のデータをまとめて見やすく表示しますが、APIはリクエストの仕方次第で、本来見えるべきでないデータまで素直に返してしまうことがあります

• 開発の都合上、画面にはまだ実装されていない機能のAPIが、先に公開されてしまっていることもあります

つまりAPIは、画面という「行儀のよい利用者向けの入口」の裏にある、何でも直接要求できる入口なのです。

Webアプリ診断とAPI診断は、何が違うのか

ここが本記事の核心です。両者は重なる部分もありますが、見ているものが根本的に違います。

※「認可」とは、ログイン済みのユーザーに対して「その操作・そのデータが許されているか」を確認することです。「本人かどうか」を確かめるログイン（認証）とは別の工程で、本記事で繰り返し出てくる最重要の概念です。

整理すると、Webアプリケーション脆弱性診断は「画面を持つWebアプリケーション」を対象とし、API脆弱性診断は「APIそのもの」を対象とする、別々の診断です。

Webアプリケーション診断は、ブラウザで表示される画面を入口として、入力フォームや画面遷移、表示処理に潜む問題を検査します。一方API診断は、API仕様（どんなエンドポイントが、どんなリクエストを受け付けるか）を起点に、次のような検査を作り込みます。

• 画面には現れないエンドポイントを含めた網羅的な検査

• 権限の異なる複数アカウントを使った、データ1件単位の認可検査

• 仕様で想定されていない値・順序・組み合わせでの呼び出し

つまり両者は「深い・浅い」の関係ではなく、そもそも検査する対象が違うということです。

スマホアプリのバックエンド、SPAが呼び出すAPI、外部に公開しているAPIは、画面を持たない（あるいは画面が主役ではない）ため、Webアプリケーション診断の対象範囲とは別に、API診断として検討する必要があります。

では、API診断では何が見つかるのか — BOLAとBFLA

ここまでで「APIは画面とは別に診断する必要がある」と述べました。では、API診断では具体的にどんな問題が見つかるのか。

ここが分かると、自社にAPI診断が必要かどうかを判断しやすくなります。というのも、APIには画面とは違う種類の脆弱性が存在し、しかもその上位2つは「画面上は正常に見えるのに、APIを直接叩くと成立してしまう」タイプだからです。

画面をいくら丁寧に検査しても見つかりません。

APIのセキュリティには、OWASP API Security Top 10という国際的なリスク一覧があります（最新は2023年版）。10項目のうち、実際の被害に直結する重要な2つを、日常の言葉で説明します。

BOLA（他人のデータが見えてしまう）— APIの脆弱性の第1位

BOLA（Broken Object Level Authorization）は、OWASP API Security Top 10の第1位であり、API攻撃の約40％を占めるとされる最も一般的なAPIの脆弱性です。

何が起きるのか、具体例で説明します。あるサービスで、自分の注文履歴を見ると、APIに order_id=1023 というリクエストが送られていたとします。ここで攻撃者が order_id=1024 に書き換えて送ると——他人の注文履歴が、そのまま返ってきてしまう。

これがBOLAです。原因は「そのデータを、そのユーザーが見てよいのか」というチェックを、API側が省いていることにあります。画面上では自分の注文しか表示されないため気づきませんが、APIを直接叩くと露呈します。

なぜツールで見つけにくいのか

ツールは「order_id=1024 を見る権利が、このユーザーにあるか」という業務上のルールを知りません。判定するには、権限の異なる2つのアカウントを用意し、「Aさんのアカウントで、Bさんのデータを要求できてしまわないか」を人が実際に試す必要があります。これはWebアプリ診断でも重要な観点ですが、APIでは「データ1件ごと」に発生するため、より作り込んだ検査が要ります。

BFLA（権限のない機能が使えてしまう）

BFLA（Broken Function Level Authorization）は、Top 10の第5位。BOLAが「他人のデータ」の問題なら、BFLAは「本来使えないはずの機能」の問題です。

一般ユーザー向けのアプリなのに、管理者用のAPI（例：全ユーザー一覧の取得、他人のアカウント削除）が、一般ユーザーの認証情報でも呼べてしまう。

具体的にはこうです。一般ユーザーの画面には管理者メニューが表示されません。そのため運営側は「一般ユーザーは管理機能を使えない」と思い込みます。しかし管理機能のAPIそのものは動いており、一般ユーザーの認証情報のまま「全ユーザー一覧を取得するAPI」を直接呼ぶと、全会員の情報がそのまま返ってきてしまう——これがBFLAです。

つまり「メニューを隠す」ことと「機能そのものを保護する」ことは別物なのに、前者だけで済ませてしまっているケースで起こります。攻撃者は画面のメニューを経由せず、APIを直接叩きます。

2つの違いを一言で

• BOLA ＝ 他人のデータを見られる／変えられる

• BFLA ＝ 権限のない機能を使えてしまう

どちらも、「画面では制限されているが、APIでは制限されていない」という共通構造を持ちます。

だからこそ、画面診断だけでは取りこぼしやすいのです。

こんな場合はAPI診断を検討すべき

自社にAPI診断が必要かどうかの判断材料です。次のいずれかに当てはまる場合、Webアプリ診断とは別に、API層の診断を検討する価値があります。

• スマホアプリを提供している — スマホアプリは画面の裏で必ずAPIと通信しています。アプリ本体の解析に加え、通信先のAPIの検査が必要です

• SPA（React / Vue / Angular等）でサービスを作っている — SPAは表示と処理が分離しており、処理の大半がAPI側にあります

• 外部の企業・サービスにAPIを公開している — パートナー連携、Webhook、公開APIは、社外から直接叩かれる前提の入口です

• 決済・個人情報・課金を扱うAPIがある — BOLA／BFLAが起きた場合の被害が大きい領域です

• マイクロサービス構成 — 内部API同士の認可が緩くなりがちです

逆に、ログイン機能のない静的なコーポレートサイトのように、そもそも本格的なAPIを持たないサイトでは、API診断の優先度は低くなります。

よくあるご質問

Q. Webアプリ診断を受けていれば、API診断は不要ですか？

A. 別の診断とお考えください。Webアプリケーション脆弱性診断は画面を持つWebアプリケーションを対象とし、API脆弱性診断はAPIそのものを対象とします。検査の起点も手法も異なるため、一方を受けていれば他方が不要になる、という関係にはありません。

特にスマホアプリのバックエンドAPI、SPAが呼び出すAPI、外部に公開しているAPIをお持ちの場合は、Webアプリケーション診断とは別にAPI診断をご検討ください。BOLAのようなAPI固有の脆弱性は、画面側の検査では発見できません。

Q. API仕様書（OpenAPI / Swagger）がないと診断できませんか？

A. 仕様書があると、エンドポイントやパラメータを網羅的に検査でき、精度と効率が上がります。仕様書がない場合でも、通信の観察や画面解析から診断は可能ですが、網羅性の担保のためにも仕様書のご用意を推奨します。

Q. GraphQLやgRPC（一般的なREST API以外のAPI方式）も診断できますか？

A. 技術的には対応可能な領域ですが、検査手法がREST APIと異なります。対象のAPI形式を事前にお知らせいただければ、対応可否と方法をご案内します。

Q. 診断でAPIに負荷はかかりますか？

A. 低負荷・非破壊を基本としますが、APIは1つのエンドポイントに多数のリクエストを送る検査があるため、本番環境ではなく検証環境での実施、または業務影響の少ない時間帯の指定を推奨します。状態を変更する操作（データの作成・削除）を伴う検査は、事前に対象と手順を取り決めて実施します。

Q. BOLAは自社で確認できますか？

A. 簡易的には、「2つのアカウントを作り、片方のアカウントで、もう片方のデータのID（URLやリクエストの中の番号）を指定して要求してみる」ことで兆候は掴めます。ただし網羅的な確認には、全エンドポイント×権限パターンの検査が必要で、専門的な診断が実務的です。

まとめ

• APIは「画面という覆いのない、むき出しの入口」。攻撃者の主戦場は画面からAPIへ移っている

• Webアプリケーション診断とAPI診断は対象そのものが違う別の診断。「深い・浅い」ではなく、画面を検査するか、APIを検査するかの違い

• 最重要のAPI脆弱性はBOLA（他人のデータが見える・APIリスク第1位）とBFLA（権限外の機能が使える）。どちらも「画面では制限、APIでは無制限」という共通構造を持つ

• スマホアプリ・SPA・外部公開API・決済／個人情報を扱うAPIを持つなら、Webアプリ診断とは別にAPI診断を検討すべき

APIのセキュリティにお悩みの方へ

当社ではWebアプリケーション診断に加え、API層の脆弱性診断にも対応しています。「Webアプリ診断は受けているが、APIまで見られているか不安」「スマホアプリのバックエンドを検査したい」といったご相談を承っています。対象のAPI形式や規模をお知らせいただければ、最適な診断範囲をご提案します。

※ご相談はサイト上部の「お問い合わせ」よりお気軽にどうぞ。

この記事の監修

竹花 樹 — 株式会社ranryu ／ 情報処理安全確保支援士（登録セキスペ）　登録番号 019507

本資格の登録情報は、IPAが運営する情報処理安全確保支援士検索サービスにてどなたでもご確認いただけます。

株式会社ranryuは、経済産業省が策定した「情報セキュリティサービス基準」に適合し、独立行政法人情報処理推進機構（IPA）が公開する「情報セキュリティサービス基準適合サービスリスト」の脆弱性診断サービスに登録されています（登録番号 021-0017-20）。

参考にした公開情報（2026年8月時点）

OWASP API Security Top 10（2023）　https://owasp.org/API-Security/editions/2023/en/0x11-t10/

API1:2023 Broken Object Level Authorization　https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/