APIの不適切な認可（BOLA等）を初心者でも分かりやすく解説

2025年10月16日作成

用語

あなたのAPIは、IDを1つ変えるだけで全ユーザーのデータが丸見えになっていませんか？APIの不適切な認可（BOLA）は、「誰がどのデータを見られるか」のチェックが甘い、極めて危険な脆弱性です。Webサイト・APIの弱点の第1位に挙げられるこの問題は、URLの数字を変えるだけで他人の個人情報、医療記録、金融データにアクセスできてしまう恐ろしい状態を作り出します。本記事では、なぜこんな単純な攻撃が成功するのか、どんな被害が発生するのか、そして適切な認可を実装するための実践的な対策について、専門知識がなくても理解できるように解説します。

APIの不適切な認可（BOLA等）とは？

APIの不適切な認可（BOLA：Broken Object Level Authorization）とは、APIが「誰がどのデータにアクセスできるか」を適切にチェックしていない脆弱性のことです。Webサイト・APIの弱点の中でも最も頻繁に悪用される脅威の一つで、URLやAPIリクエストのIDパラメータを変更するだけで、他のユーザーのデータにアクセスできてしまいます。例えば、自分のユーザーID「123」を「124」に変えるだけで、他人の個人情報、注文履歴、医療記録などが見えてしまう危険な状態です。OWASPのAPIセキュリティTop10で第1位に挙げられる深刻な脆弱性です。

APIの不適切な認可（BOLA等）を簡単に言うと？

ホテルの部屋に例えると、フロントで「301号室の鍵をください」と言った時、本当に301号室の宿泊客かを確認せずに鍵を渡してしまうようなものです。悪い人が「302号室」「303号室」と順番に言っていけば、全ての部屋の鍵がもらえてしまいます。APIも同じで、「ユーザー123のデータをください」というリクエストに対して、「あなたは本当にユーザー123ですか？」という確認をせずにデータを渡してしまいます。IDを1つずつ変えていけば、全員分のデータが見放題になってしまう。まるで、名札を付け替えるだけで他人になりすませるような、信じられないほど単純な穴なのです。

APIの不適切な認可（BOLA等）で発生する被害は？

APIの不適切な認可により、大規模な個人情報漏洩、プライバシー侵害、企業機密の流出などが発生します。Webサイト・APIの弱点を突かれることで、攻撃者は簡単なスクリプトで数百万件のデータを自動収集でき、被害は瞬時に拡大します。特に、医療情報、金融情報、位置情報などの機密性の高いデータが扱われるAPIでは、取り返しのつかない被害につながります。

APIの不適切な認可（BOLA等）で発生する直接的被害

全ユーザーデータの一括窃取: APIのIDを総当たりで変更し、数百万人分の個人情報、購入履歴、クレジットカード情報などを自動的に収集されて闇市場で売買される
競合他社への情報流出: 企業の顧客リスト、価格情報、在庫データなどがAPIから抜き取られ、競合他社に渡って競争優位性を完全に失う
プライベート情報の暴露: SNSのプライベートメッセージ、医療記録、位置情報履歴などが不正に取得され、恐喝や嫌がらせに利用される

APIの不適切な認可（BOLA等）で発生する間接的被害

法的責任と巨額の制裁金: GDPRや個人情報保護法違反により、売上高の数％に相当する制裁金を科され、集団訴訟で数十億円の賠償責任を負う
APIサービスの信頼崩壊: 開発者やパートナー企業がAPIの利用を停止し、エコシステム全体が崩壊して、ビジネスモデルが成立しなくなる
監査コストの増大: 一度の事故により、定期的なセキュリティ監査が義務付けられ、年間数千万円の追加コストが恒久的に発生する

APIの不適切な認可（BOLA等）の対策方法

APIの不適切な認可への対策は、オブジェクトレベルでの認可チェック、最小権限の原則、適切なアクセス制御の実装が基本となります。Webサイト・APIの弱点を補強するために、すべてのAPIエンドポイントで「誰が」「何に」アクセスしているかを確認し、ユーザーが所有するリソースのみにアクセスを制限することが重要です。また、UUID等の推測困難なIDの使用、レート制限の実装、包括的なログ記録により、攻撃を防ぎ早期発見することができます。

APIの不適切な認可（BOLA等）の対策を簡単に言うと？

銀行の貸金庫システムに例えると、まず「貸金庫123番を開けたい」と言われたら、必ず「あなたは123番の契約者ですか？身分証明書を見せてください」と確認します（認可チェック）。番号を推測されないよう、連番ではなくランダムな番号（UUID）を使い、「手当たり次第に開けようとする人」を見つけたらすぐに止めます（レート制限）。誰が、いつ、どの貸金庫にアクセスしようとしたか全て記録し（ログ）、不審な動きがあればすぐに警報を鳴らします。「ログインしているから大丈夫」ではなく、「一つ一つの操作で本人確認する」という徹底した管理が、APIを守る基本姿勢です。

APIの不適切な認可（BOLA等）に関連した攻撃手法

Webサイト・APIの弱点において、APIの不適切な認可（BOLA等）と密接に関連する3つの攻撃手法を解説します。

IDOR（Insecure Direct Object Reference）: BOLAとIDORは密接に関連しており、多くの場合同じ意味で使われます。IDORは直接的なオブジェクト参照の脆弱性を指し、BOLAはその結果として起こる認可の破綻を指します。両者は表裏一体の関係にあり、同じ対策で防ぐことができます。
レート制限なし: APIの不適切な認可と組み合わさると、致命的な被害をもたらします。BOLAの脆弱性があっても、レート制限があれば大量のデータ窃取は困難ですが、レート制限がないと数分で全データが盗まれてしまいます。
SSRF（Server-Side Request Forgery）: BOLAで取得した内部APIのエンドポイント情報を使って、SSRF攻撃を実行することができます。APIの認可不備により内部構造が露呈し、それを利用してより深刻な攻撃へと発展する可能性があります。