BOLA：APIに潜む、見過ごされがちな脆弱性

オンラインバンキングアプリにログインし、口座残高や取引履歴、個人情報が表示されている場面を想像してください。すべてが期待どおりに動いています。では、URLの数字（口座ID）を1つ変えただけで、突然ほかの人の金融情報が表示されたらどうでしょう。ハッキングツールは不要です。複雑なエクスプロイトチェーンも必要ありません。たった1桁変えるだけです。

これは仮定の話ではありません。まさにこの種の脆弱性が原因で、T-Mobileでは2023年に公表された情報漏えいで3,700万人の顧客データが流出し、最終的に3億5,000万ドルの集団訴訟和解に至りました。

同じ種類の欠陥により、攻撃者はAPIリクエストのユーザーIDを入れ替えるだけで、あらゆるPelotonユーザーの個人情報やワークアウト統計にアクセスできました。また、広く利用されているコンテナレジストリHarborでも、未承認のAPI呼び出しでプロジェクトのメタデータを操作することで、基本的なメンテナンスロールを持つユーザーが非公開プロジェクト全体を公開に切り替え、未検証のイメージをデプロイできるという、同じ脆弱性パターンが見られました。

これらすべてのインシデントの根底にある脆弱性には、Broken Object Level Authorization（BOLA）という名前があります。OWASP API Security Top 10の第1位にランクされており、現代のAPIセキュリティにおいて、最も広く見られ、危険で、過小評価されている欠陥と言っても過言ではありません。

BOLAとは？

Broken Object Level Authorizationとは、APIやWebアプリケーションが、リクエストを送信したユーザーに対象データオブジェクトへのアクセスや変更を正当に許可されているか確認しないことで発生する認可の欠陥です。ユーザーがデータベースレコード、ファイル、取引などのリソースを要求したとき、アプリケーションはユーザーが認証済みであること（本人であること）だけでなく、その特定のオブジェクトを操作する権限があること（閲覧や変更が許可されていること）も確認する必要があります。

この認可チェックが欠けている、弱い、あるいは一貫して適用されていない場合、攻撃者はリクエスト内のオブジェクト識別子を操作するだけで、ほかのユーザーのデータにアクセスできます。URLパラメーターの口座番号を変える。APIヘッダーのユーザーIDを入れ替える。JSONペイロードのリソースIDを変更する。サーバーがすべてのリクエストでオブジェクト単位の所有権を検証しなければ、渡すべきではないデータを渡してしまいます。

認証と混同しないことが重要です。認証では「あなたは誰ですか？」という問いに答え、認証情報、トークン、多要素認証などを使って本人確認を行います。認可では「何をすることが許されていますか？」という問いに答え、そのユーザーに許可される具体的なリソースや操作を決定します。BOLAが悪用するのは、後者のチェックの不備です。ユーザーは認証され、ログインし、本人確認も済んでいます。ただ自分に属さないオブジェクトにアクセスしているだけで、アプリケーションはそれを防げていません。

BOLAとIDOR：同じ欠陥を異なる視点から捉えたもの

アプリケーションセキュリティに携わってきた方なら、OWASPがBOLAと呼ぶものが、以前から知られている別の脆弱性Insecure Direct Object References（IDOR）とよく似ていることに気づくでしょう。これはサイバーセキュリティ業界で実際に議論のあるテーマであり、名称の重複が混乱を招くため、正面から取り上げる価値があります。

IDORの起源はOWASP Web Application Security Top 10にあり、2007年にはすでに取り上げられていました。この用語は、アプリケーションがデータベースキー、ファイル名、連番IDなどの内部オブジェクトへの直接参照を公開し、攻撃者がその参照を操作して本来アクセスできない情報にアクセスする、特定の攻撃パターンを指します。IDORは主に、攻撃者が改ざんする、予測・推測・列挙が可能な識別子という、エクスプロイトの手法に焦点を当てていました。

2019年にOWASP API Security Top 10で導入されたBOLAは、同じ根本的な欠陥を、より広い視点から表したものです。IDORが操作可能な参照に焦点を当てたのに対し、BOLAは問題の本質であるオブジェクト単位の認可チェックの不備として捉え直しています。

焦点は、攻撃経路（「参照が安全でない」）から根本原因（「認可が機能していない」）へと移ります。またBOLAは、こうした欠陥が単純なURLの改ざんにとどまらないことも明確に示しています。APIリクエストの本文やヘッダー、ネストされたオブジェクトグラフ、さらには認可ロジックが一貫して実装されていないマイクロサービス間にも現れる可能性があります。

実際には、2つの用語は同じ脆弱性群を指しています。IDORと呼ぶかBOLAと呼ぶかにかかわらず、根本的な問題は同じです。アプリケーションがユーザーの入力した識別子を信頼し、要求された特定のオブジェクトに対してサーバー側で適切な認可チェックを行わないことです。対策も同じです。ビジネスへの影響も同じです。

ただし、用語の違いが重要となる理由は2つあります。

• 第一に、BOLAという捉え方は、特定の技術的パターンではなく認可ロジックを中心に据えるため、現代のAPI主導型アーキテクチャを考えるうえでより有用です。マイクロサービス、コンポーザブルアーキテクチャ、複雑化するAPIエコシステムの時代には、URLパラメーターが推測可能かどうかを考えるより、すべてのエンドポイントとすべてのオブジェクトにわたって認可を包括的に考えるほうが有効です。

• 第二に、BOLAはOWASP API Security Top 10の第1位であり、IDORはOWASP Web Application Top 10のより広い「Broken Access Control」カテゴリーに含まれます。両方の用語を正確に使うことで、WebとAPIの両方にまたがる問題の全体像を理解していることを示せます。

この記事では以降、主にBOLAという用語を使いますが、BOLAを見かけたら、IDORも同じ問題の一部だと覚えておいてください。

BOLAが特に危険な理由

脆弱性の中でもBOLAは特に厄介な位置を占めています。通常は同時に現れにくい3つの特徴、つまり悪用が容易で、検出が難しく、影響が甚大であるという特徴を併せ持つためです。

悪用が容易。

BOLA攻撃に高度なツールや技術知識、複雑なエクスプロイトチェーンは必要ありません。攻撃者はブラウザーやプロキシツール、簡単なスクリプトだけで脆弱性を探れます。パラメーターを変えて、応答を確認する。返ってきたデータが本来表示されるべきでないものなら、そのアプリケーションには脆弱性があります。参入障壁は事実上ゼロであり、ほかの多くの脆弱性クラスよりもはるかに幅広い脅威アクターが悪用できます。

テストが難しい。 

従来のセキュリティテスト手法では、BOLAの検出に苦労します。従来型の技術的な欠陥ではなく、ロジックエラーだからです。SQLインジェクションはクエリに検出可能なパターンを残します。クロスサイトスクリプティング（XSS）脆弱性では、特徴的なペイロードが使われます。一方、BOLAでは、構文的にも形式的にも完全に正しいAPIリクエストが、誤ったユーザーのデータを返します。不正な入力も、疑わしいペイロードも、異常なパターンもありません。リクエストは正当なものに見えます。応答も正当に見えます。問題はただ、リクエストを送った人がその応答を受け取るべきではなかったという点だけです。

最新の防御をすり抜ける。 

Webアプリケーションファイアウォール、APIゲートウェイ、レート制限、認証制御などを備え、成熟したセキュリティ体制を整えている組織でも、BOLAの影響を受ける可能性があります。こうした防御は、不正アクセスや不正なリクエスト、既知の攻撃パターンを検出するために設計されています。BOLAは、正常な認証済みトラフィックの範囲内で発生します。ユーザーは有効な認証情報を持ち、リクエスト形式も正しいものです。APIゲートウェイには、認証済みユーザーからの正当そうなリクエストに見えます。アラートを引き起こすものは何もありません。

ビジネスへの影響は、その深刻さに比例します。数百万件のレコードが流出するデータ侵害。規制当局による罰則。集団訴訟。回復に何年もかかる評判の低下。URLの数字を変えるだけで攻撃できるのなら、問うべきなのは攻撃者が試すかどうかではありません。試されたとき、アプリケーションが攻撃を阻止できるかどうかです。

そもそもBOLAはなぜ発生するのか？

BOLA脆弱性は、単一のエンジニアリング上のミスが原因で発生することはほとんどありません。APIの設計、構築、保守の方法に根付いた、誤った前提が積み重なって生まれる傾向があります。

開発者はクライアント側のチェックに過度に依存し、ユーザーがオブジェクトIDやトークンを改ざんしないと思い込むことがあります。これは根本的に誤った前提であり、先ほどの情報漏えい事例が繰り返し証明しています。さらに、エンドポイント間で認可ロジックが一貫して実装されていないことも少なくありません。中央集約型の認可フレームワークがなく、各エンドポイントが個別にアクセス制御チェックを実装する（あるいは実装し忘れる）場合、抜け漏れは避けられません。100個のエンドポイントのうち99個で認可が正しく適用されていても、見落とされた1つが侵入経路になります。

テストの実践方法も問題を深刻化させます。手動のセキュリティテストやカバレッジの低い自動テストでは、パターンベースの脆弱性ではないBOLAをほとんど検出できません。既知のシグネチャをスキャンしても見つけられません。BOLAを効果的に検出するには、ビジネスロジック、データの所有権、各リクエストのコンテキストを理解する必要があります。こうした能力は、これまで自動化ツールでは実現が困難でした。

そして、現代のソフトウェア開発の現実もあります。何よりもスピードが優先されるのです。開発チームはビジネスニーズに応えるため、APIを迅速にリリースするよう常に求められ、機能の提供を優先して認可の検証が後回しになりがちです。このトレードオフで生じたBOLA脆弱性は、攻撃者に発見されるまで何カ月、何年も検出されないまま残る可能性があります。

検出の難しさ

BOLAを大規模に特定することは、アプリケーションセキュリティにおける最も難しい課題の1つです。その理由を理解しておく価値があります。

最大の課題は、BOLAを効果的に検出するにはコンテキストを理解する必要があることです。スキャナーは、APIがデータを返すことだけでなく、リクエストを送った特定のユーザーがそのデータにアクセスできるべきかどうかも把握しなければなりません。このリソースは公開か非公開か。リクエストしたユーザーはこのオブジェクトの所有者か。このロールのユーザーはこのフィールドを閲覧できるのか。これらはアプリケーションのビジネスロジックと認可ルールに全面的に依存する問いであり、パターンマッチングやシグネチャベースの検出では答えられません。

IDを変更して異なるデータが返るか確認するなど、BOLA検出の単純な手法では、許容できないほど多くの誤検知が発生します。多くのAPIは、認証済みユーザーなら誰でもアクセスできる公開リソースを意図的に提供しています。商品カタログ、公開プロフィール、共有ドキュメントなどは、ユーザーをまたいでアクセスできるようにするものです。2人のユーザーが同じリソースにアクセスできる例をすべてBOLAの可能性として警告すれば、ノイズが本当の検出結果を埋もれさせます。すでに手一杯のアプリケーションセキュリティチームには、数百件の誤検知を調査して、わずかな実際の認可不備を見つける余裕はありません。

BOLAを検出できるとうたう一部の競合製品が、表面的な結果しか出せないのはこのためです。アクセス対象のコンテキストや、アクセスを制限すべきかどうかを理解できなければ、検出の仕組みは単純なままで、シグナルとノイズの比率も改善されません。

これまで以上に重要な理由

BOLA検出の緊急性は、机上の空論ではありません。複数の要因が重なり、この種の脆弱性はこれまでになく広がり、危険性を増しています。

1. APIの攻撃対象領域が拡大している。 

現代のアプリケーションは、もはやモノリシックなコードベースではありません。マイクロサービスがAPIを介して連携し、従来の巨大なコードベースに代わって、組み合わせ可能なアーキテクチャが主流になっています。新しいマイクロサービスやAPIエンドポイント、インテグレーションが追加されるたびに、BOLAの潜在的な発生箇所も増えます。一般的な企業環境におけるAPIエンドポイントの数は桁違いに増加しており、そのすべてで認可ロジックを正しく実装する必要があります。

2. AIが生成するコードが問題を加速させている。 

開発者の76%がAIコーディングツールを現在利用しているか、今後利用する予定です（Stack Overflow、2024年）。また、主要なAIモデル5つを対象とした調査では、生成されたコードスニペットの少なくとも48%に脆弱性が含まれていることがわかりました。コードが機械の速度で生成されると、認可エラーが発生する可能性もそれに応じて増加します。AIコーディングアシスタントを使う開発者は、より多くのコードをより速くリリースできますが、そのコードの認可ロジックは、プロンプトとレビュー体制の質に左右されます。多くの場合、生成されたコードは機能上は正しく動作しても、セキュリティを意識した開発者なら実装していた認可チェックが抜けています。

3. AIエージェントが新たな攻撃経路を生み出している。 

APIを介して社内のデータやサービスとやり取りする自律型AIエージェントの台頭により、問題はさらに複雑になっています。こうしたエージェントは人間のユーザーと同じAPIエンドポイントを通じて通信しますが、機械の速度で動作し、人間の利用パターンにはない形で複数のAPI呼び出しを連鎖させることがあります。APIエンドポイントにBOLAの脆弱性があれば、エージェントが悪用される可能性があります。また、攻撃者がエージェントと同じエンドポイントを悪用して、データを大量に窃取したり、リソースを改ざんしたりするおそれもあります。

BOLAの脆弱性があるAPIを利用するエージェントは、単なる脆弱性ではありません。データを自動的に窃取するマシンです。

OWASP API Security Top 10の上位5項目のうち4つは、認可と認証に関する問題です。BOLAは単独の問題ではなく、現代のアプリケーションにおけるアクセス制御の課題が最も顕著に表れたものです。BOLAの検出を解決することは、重大なAPIセキュリティリスクの大半を占める、より広範な認可の不備への対処につながります。

新たなアプローチ：AIを活用したBOLA検出

BOLAが長年なくならない要因となっている検出の難しさは、根本的にはコンテキストの理解に関する問題です。そしてまさにこの点で、AIや大規模言語モデル（LLM）の近年の進歩が状況を変えつつあります。

Snyk API & Webが先駆けるアプローチでは、LLMを使ってAPIリクエストと認可ロジックのコンテキストを分析します。従来のDAST手法を超えて、コンテンツの所有者を特定し、リクエストしたユーザーがレスポンスにアクセスできるかどうかを判断します。誤検知を生む単純なIDの置き換えに頼るのではなく、AIを活用した検出エンジンが、データが公開か非公開か、リクエストしたユーザーが正当な所有者か、認可境界が実際に侵害されているかを推論できます。

これは、動的アプリケーションセキュリティテストの基本を置き換えるものではありません。DASTは引き続き不可欠です。攻撃者と同じように、外部からアプリケーションをテストし、ペイロードを使って攻撃対象領域を大規模に調査します。AIがもたらすのは、こうしたテスト手法にコンテキストを理解するインテリジェンスを重ね合わせ、パターンマッチングでは見つけられない脆弱性を検出する能力です。その結果、誤検知を大幅に抑えたBOLA検出が可能になり、AppSecチームはノイズをふるいにかけるのではなく、すぐに対応できる実用的な検出結果を受け取れます。

そして、BOLAは始まりにすぎません。同じAI主導のアプローチは、OWASP API Security Top 10に含まれるほかの認可や認証の不備にも拡張されています。ビジネスロジックのコンテキストを理解するという技術的な課題は、アクセス制御の脆弱性全体に共通するからです。BOLA検出の解決は、APIセキュリティテストを根本からよりスマートにするための基盤となります。

セキュリティリーダーが問うべきこと

組織のアプリケーションセキュリティプログラムを担う立場であれば、リスク評価の最優先事項にBOLAを含めるべきです。次の点を確認してください。

APIエンドポイント全体で認可がどのように実装されているかを把握できていますか。また、その実装に一貫性はありますか。一貫性の欠如は、BOLAが発生しやすい状況を生みます。すべてのサービスに適用される一元的な認可フレームワークが、最も効果的なアーキテクチャ上の防御策です。

現在利用しているテストツールは、本当にBOLAを検出できますか。それとも検出できるとうたいながら、誤検知ばかりを出していませんか。BOLA検出の品質は一様ではありません。誤検知率や検出手法、実環境での成果など、精度を裏付ける証拠を求めましょう。

AIが生成したコードの認可への影響をどのように考慮していますか。開発者がAIコーディングアシスタントを使っている場合、リリースされるコードは機能上正しくても、認可の実装が不十分な可能性があります。コードレビューで見落とされる問題も検出できるテスト手法が必要です。

最後に、外部からのテストを実施していますか。BOLAのような認可の不備は、攻撃者と同じようにアプリケーションをテストして初めて、その全容が明らかになります。実際に稼働しているAPIやWebアプリケーションに対し、実際のリクエストやペイロードを送り、本来アクセスできない情報へのアクセスを試みる視点で調査するのです。静的解析では、コード内の潜在的な問題を特定できます。動的テストでは、それらが実際に悪用可能かどうかを検証できます。

BOLAがOWASP API Security Top 10の最も重大なリスクとされるのには理由があります。広く存在し、発見が難しく、悪用されれば数百万ドルの損失や数百万件のレコードの侵害につながります。しかし、検出の問題はもはや解決不可能ではありません。AIを活用したアプローチにより、従来のツールではできなかった精度とコンテキスト理解を備えた検出が可能になっています。攻撃者より先に自組織の脆弱性を見つけられるかどうかが問われています。