2026年になっても「不備のあるアクセス制御」がOWASP Top 10の首位を占める理由

Open Worldwide Application Security Project(OWASP)は、2回連続のリリースで、不備のあるアクセス制御(Broken Access Control:BAC)をWebアプリケーションのトップセキュリティリスクとして特定しました。同様に、認可の問題であるオブジェクトレベルの認可の不備(Broken Object Level Authorization:BOLA)も、APIの脆弱性の中で1位となっています。なぜこの問題は解消されないのでしょうか。効果的な対策を妨げる主な原因は何でしょうか。そして、この問題に対処するためのベストプラクティスを紹介します。

論理的な脆弱性の持続

2021年版において、不備のあるアクセス制御はOWASP Top 10 Webアプリケーションセキュリティリスクリストで1位にランクされました。公開されたばかりの2025年版でも、依然として首位を維持しています。

技術的脆弱性と論理的脆弱性

認可の不備が解消されない理由を理解するには、まず技術的脆弱性と論理的脆弱性を区別する必要があります。

SQLインジェクション(SQLi)やクロスサイトスクリプティング(XSS)などの技術的脆弱性は、認識可能な構文パターンに従います。現代の静的アプリケーションセキュリティテスト(SAST)ツールは、コード構造を解析して危険な連結やバッファオーバーフローを検出できるため、これらを特定するのが得意です。

対照的に、不備のあるアクセス制御やオブジェクトレベルの認可の不備は論理的な欠陥です。これらは、自動化ツールがコードの構造を理解できても、ビジネス上の意図を理解するためのコンテキストが欠落しているという「意味論的なギャップ」を表しています。

不備のあるアクセス制御とオブジェクトレベルの認可の不備

BACとBOLAとは何でしょうか。修正が困難である理由を探る前に、これらを簡潔に整理します。

不備のあるアクセス制御(BAC)は、認証されたユーザーに対して許可される操作を管理するメカニズムの失敗を指す包括的なカテゴリです。垂直方向の権限昇格(例:管理者機能へのアクセス)やメタデータの改ざんなどが含まれます。

オブジェクトレベルの認可の不備(BOLA)は、以前は不適切なオブジェクト参照(IDOR)として知られていました。アプリケーションが特定のデータオブジェクトに対するユーザーの権限検証を怠った場合に発生します(例:自身の注文ではない/api/orders/12345へのアクセス)。BACと同様に、BOLAも2019年から2023年にかけて、APIにおける最も深刻なリスクとして残り続けています。

BAC、BOLAとスキャンツール

SASTツールには、特定のリソースを現在のユーザーに制限すべきかどうかを判断するための実行時のコンテキストがありません。アクセス制御マトリックスやデータベースで定義された関係グラフへのアクセス手段を持たないため、ビジネスロジックを推測できません。

一方で、動的アプリケーションセキュリティテスト(DAST)ツールは、ユーザーのデータを含むHTTP 200 OKレスポンスを、データ漏洩ではなくリクエストの成功とみなすことがよくあります。これは、基盤となるビジネスルールを理解していないためです。

文学的な例を挙げると、SASTやDASTツールはコナン・ドイルの小説『白銀号事件』に登場する犬のような存在です。シャーロック・ホームズは「夜中に犬が吠えなかった」という不可解な出来事から事件を解決しました。犬が吠えなかったのは、侵入者が犬の知っている人物、つまり信頼された内部の人間や正当なアクセス権を持つ人物だったことを意味します。

自動セキュリティツールがBACを検出できない理由も、この犬が吠えなかった理由と同じです。システムにとって、そのリクエストは完全に「正常」に見えるからです。犬がその行動を不審だと認識するためのコンテキストを欠いていたのと同様に、これらのツールも、あるアクションが正当かどうかを判断するために必要なビジネスコンテキストを欠いています。

不備のあるアクセス制御の修正が複雑な理由

これらの脆弱性が解消されない理由として、自動スキャンへの依存が誤った安心感を生んでいるという心理的な側面も考えられます。しかし、それだけでは説明として単純すぎます。不備のあるアクセス制御がこれほどまでに根強い理由をいくつか分析します。

分散認可の複雑さ

モノリシックなアプリケーションから複雑なハイブリッドクラウドエコシステムへの移行により、従来のセキュリティ境界は消滅しました。現代のマイクロサービスアーキテクチャでは、認可ロジックが分散されることがよくあります。「在庫サービス」を担当する開発者が、「ユーザーサービス」を担当する開発者とは異なるロジックを実装し、一貫性のない適用や目に見えないギャップが生じる原因となります。

さらに、APIは設計上ステートレスです。サーバーがコンテキストを「記憶」する従来のセッションとは異なり、すべてのAPIリクエストにおいて、オブジェクトへのアクセスごとに再認可を行う必要があります。これは、開発のプレッシャーの中で頻繁に見落とされる要件です。

認証と認可の混同

BOLAの根本的な原因の一つは、認証と認可の混同です。開発者は、有効なJSON Web Token(JWT)やセッションクッキーが存在することを、あらゆるリソースへのアクセス許可の証明であると誤解しがちです。BOLAを悪用した攻撃では、攻撃者の身元は確認されますが(認証成功)、サーバーはその身元が要求されたリソースを所有しているかどうかの確認を怠ります(認可失敗)。

ドイルの小説で吠えなかった犬を覚えていますか。この場合、サーバーはその犬のように動作します。ユーザーを認識はしますが、そのユーザーがそのリソースにアクセスすべきかどうかを判断するためのコンテキストを持っていません。

アイデンティティの拡散と非人間アイデンティティ(NHI)

現代のインフラ環境は、人間のユーザー、サービスアカウント、短命なワークロードにまたがる「断片化したアイデンティティの風景」となっています。非人間アイデンティティ(NHIs)は今や人間のユーザーよりもはるかに多く、AIエージェントの普及により状況はさらに複雑化しています。

これらのアイデンティティは、本番環境のフローを止めないために過剰な権限が与えられる「権限の肥大化(privilege creep)」に陥りがちです。単一のサービスアカウントが侵害されると、権限は追加される一方で削除されることが稀であるため、被害範囲は甚大になります。

その場しのぎの制御の進化

OktaやAuth0などの標準的なプロバイダーで処理できる認証とは異なり、認可はビジネスロジックと深く結びついています。計画的に設計されることは少なく、その場しのぎで進化していくのが実態です。

ドキュメント管理システムを例に挙げます。「ユーザーがオーナーであるか」という単純なチェックは、「チーム」、「共有フォルダー」、「管理者による上書き」などの機能が追加されるにつれて、if/elseステートメントのスパゲッティコードへと変わり、コードの読みやすさやテストのしやすさが損なわれます。

設計図なしに認可システムを拡張すると、不整合な制御が入り混じり、理解が困難なウィンチェスター・ミステリー・ハウスのような状態になるリスクがあります。

適切なアクセス制御のためのガイドライン

堅牢な認可を実現するには、暗黙的でその場しのぎのチェックから、明示的で設計されたパターンへと移行する必要があります。アプリケーションのアクセス制御に関する脆弱性を改善するための提案をまとめます。

認可コードの集約

システムを構成する無数のマイクロサービスやコンポーネントに、アクセス制御ロジックを分散させないでください。

分散環境で効果的にアクセス制御を管理するには、ポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)のパターンを採用します。決定ロジック(PDP)を実行ロジック(PEP)から分離することで、認可をサービス間に散在するif/elseの羅列ではなく、一元化され監査可能なプロセスにできます。

このアーキテクチャでは、PEPはマイクロサービスやAPIゲートウェイ内に配置し、リクエストをインターセプトして最終的な決定を適用します。PDPは、OpenFGAやOPAなどの集中エンジンとして機能し、提供された実行時のコンテキストとアイデンティティ属性に基づいてポリシーを評価し、「許可」または「拒否」の判定を返します。

Policy as Code(PaC)の実装

業界は、認可ロジックをアプリケーションコードから切り離すためにPolicy as Codeへと移行しています。Auth0 FGA、OpenFGA、Open Policy Agent(OPA)などのツールを使用して、意思決定を専用エンジンにオフロードできます。このアプローチにより、セキュリティチームはアプリケーション全体を再デプロイすることなくポリシーを更新できます。

また、ポリシーをGitなどのバージョン管理システムで管理できるため、変更履歴の追跡や、問題発生時の以前の状態へのロールバックも容易になります。

さらに、PaCは自動テストを可能にし、ポリシー変更後に発生し得る脆弱性の軽減に役立ちます。例えば、Auth0 FGAでは、継続的開発・統合パイプラインに組み込める自動テストを構成できます。

Fine-Grained Authorization（FGA）の利用

ユーザーがリソースにアクセスするための適切なロールを持っているかを確認するだけでなく、その特定のリソースに対して要求されたアクションを実行するために必要な権限を持っているかを確実にすることが重要です。FGAシステムの実装は、アクセス制御の管理を向上させ、こちらの記事で述べたようなBOLAなどの脆弱性防止に役立ちます。

スコープ指定されたデータベースアクセスの実装

IDパラメータのみに依存する汎用的なクエリから脱却する必要があります。脆弱なパターンであるOrder.findById(params.id)の代わりに、所有権を暗黙的に強制するパターンを使用してください。認証されたユーザーのコンテキストにクエリのスコープを限定する(例:currentUser.Orders.findById(params.id))ことで、コントローラーでの手動チェックを忘れた場合でも、データアクセスレイヤーで認可を強制できます。

スキーマベースのバリデーションの適用

攻撃者がroleやcompany_idなどの機密フィールドを上書きしようとするマスアサインメント攻撃を防ぐために、JSON SchemaやZodなどのツールを使用して入力スキーマを厳格に適用してください。APIエンドポイントがusernameのみを期待している場合、スキーマによってidやroleを含むリクエストを自動的に拒否するようにします。

より安全な未来を築くために

不備のあるアクセス制御が2026年になっても最大の脅威である理由は、複雑化するシステムにおける管理性の欠如にあります。自動スキャナーではビジネス上の意図を解釈するのが困難なため、BACやBOLAに対する防御はアーキテクチャに組み込まなければなりません。FGAを採用し、「デフォルト拒否」ポリシーを適用し、データアクセスをユーザーコンテキストに制限することで、アイデンティティと権限のギャップを埋める、回復力のあるシステムを構築できます。

これらのパターンの実装に関する詳細は、OWASP Top 10:2025ガイドおよびAuth0 FGAドキュメントを参照してください。