Broken Access Control: 2025年に40%増加した最も悪用される脆弱性 🚧

セキュリティ失敗の常駐チャンピオン

絶え間ないサイバーセキュリティの変化の中で、トップの座を維持し続けている脆弱性があります。それが broken access control（アクセス制御の破損）です。Open Web Application Security Project (OWASP) が2025年のトップ10リストを11月に発表した際、そのメッセージは明白でした—長年の認識、セキュリティ改善、無数の予防策にもかかわらず、broken access controlは今日の組織が直面する最も深刻なアプリケーションセキュリティリスクのままです。

統計は衝撃的な現実を示しています。OWASPの最新分析によると、280万以上のアプリケーションのうち、平均3.73%がこのカテゴリーに関連する40の一般的な脆弱性（CWE）を少なくとも1つ含んでいます。さらに驚くべきは、94%のアプリケーションが何らかのbroken access controlの弱点についてテストされており、このセキュリティ課題の蔓延を浮き彫りにしています。

急激な増加：数字の理解

BreachLockの2025インテリジェンスレポートによると、broken access controlは過去1年間に行われた4200以上のペンテストのうち、32%の高重大度の発見を占めており、著しい増加を示しています。これは過去数年と比べて大きな変化であり、broken access controlが現代アプリケーションで最も一般的かつ最も重要な脆弱性であることを裏付けています。

この傾向は特定のセクターで特に顕著です。技術やSaaS環境のAPIは、重要な脆弱性が400%増加しており、アクセス制御の不備、ロジックの欠陥、不安全な露出が主な原因です。金融機関は、ITの急速な変化と進化する脅威に対応するため、ペンテストの頻度を増やし、約40%が四半期ごとまたは継続的にテストを実施しています。

broken access controlはなぜ危険なのか？

broken access controlは、アプリケーションが認可ポリシーを適切に強制しない場合に発生します。つまり、ユーザーが特定の操作やデータにアクセスできるかどうかを検証しない状態です。認証（あなたが誰かを確認すること）と異なり、認可はログイン後に何ができるかを決定します。これらの制御が失敗すると、攻撃者は弱点を悪用して、アクセスすべきでないデータの閲覧、変更、削除を行うことが可能になります。

この脆弱性は以下のような一般的な形態で現れます：

垂直権限昇格：通常のユーザーが管理者機能にアクセスできる場合。例として、標準ユーザーがURLを推測または発見して管理パネルにアクセスするケース。

水平権限昇格：同じ権限レベルの他のユーザーのリソースにアクセスする場合。例として、URLのIDパラメータを変更して他の顧客のアカウント情報を閲覧するケース。

Insecure Direct Object References (IDOR)：アプリケーションが内部オブジェクト（ファイル、データベースエントリ、ディレクトリなど）への参照を適切な認可チェックなしに公開し、攻撃者がこれらを操作できる状態。

強制ブラウジング：アクセス制御のチェックを回避し、保護されるべきURLに直接アクセスすることで、セキュリティ検証をスキップする行為。

機能レベルのアクセス制御の欠如：APIエンドポイント（POST、PUT、DELETEリクエストを扱う）に対してユーザー権限を検証しない場合。

実世界への影響：失敗のコスト

broken access controlの脆弱性は、理論的なセキュリティ問題を超えた深刻な結果をもたらします。2022年9月、Optusは約1000万人の現役および元顧客の個人情報を漏洩させる大規模な侵害を公表しました。後の法的資料では、アクセス制御のコーディングエラーによりAPIが長期間悪用され、認証されていないリクエストが顧客記録にアクセスできたことが明らかになっています。

最近では、2024年6月にKiaのウェブポータルにおいて、車両の制御をライセンスプレート番号だけで奪取できる重大な脆弱性が示されました。所有権の検証と認可チェックの弱さを悪用し、正規の所有者のアプリから制御を奪い、追跡、解錠、遠隔始動を可能にしました。この事件は、重要な操作におけるサーバー側の認可不足が実世界の物理的な結果をもたらす例です。

急速な開発サイクルの問題

broken access controlの増加に寄与している主な要因の一つは、ソフトウェア開発の加速です。組織は迅速に機能を提供するプレッシャーに直面し、セキュリティよりもスピードを優先する傾向があります。この「速く動いて壊す」精神は、ビジネスの敏捷性には有効かもしれませんが、重大なセキュリティの盲点を生み出します。

セキュリティの誤設定は、2021年の第5位から2025年のOWASP Top 10の第2位に上昇しており、急いで構築されたシステムが脆弱性を生むことを示しています。現代のソフトウェアエンジニアリングは、設定ファイル、クラウドの権限、インフラストラクチャのテンプレートに依存しており、これらの誤設定や過剰な役割、デフォルトの不安全な権限が攻撃の入り口となります。

この問題は、マイクロサービス、多層化、API、マシンIDなどの複雑さが増すことでさらに深刻化しています。しかし、ガバナンスの枠組みは比例して拡大しておらず、分散システム全体で一貫した認可ポリシーを実施するのは困難です。これにより、外部攻撃者や内部脅威に対してギャップが生まれやすくなっています。

さらに、調査によると、67%の組織がユーザープリビレッジを四半期ごとまたはそれ以下の頻度でしか見直しておらず、長期間にわたり休眠アカウントや過剰な権限が放置されるリスクがあります。この継続的な監視の欠如は、外部攻撃者と内部者の両方にとっての攻撃機会を増やしています。

AI生成コードの危機

最も憂慮すべき要素の一つは、AIを用いたコード生成ツールの急速な普及です。これらのツールは生産性と効率性を向上させる一方で、未曾有のセキュリティリスクももたらしており、多くの組織は対応できていません。

問題の範囲

最近の学術研究では、AI生成コードのセキュリティに関する衝撃的な統計が明らかになっています。調査によると、AI生成コードの40%から62%に設計の欠陥や既知のセキュリティ脆弱性が含まれているとされます。Veracodeの包括的な調査では、全テストケースの45%で大規模言語モデル（LLMs）がOWASP Top 10に分類される脆弱性を導入していることが判明しました。

プログラミング言語別のリスク率は、Javaが最も高く70%以上、Python、C#、JavaScriptも38%から45%の範囲で重大なリスクを示しています。これらは例外的なケースではなく、AIモデルがコードを生成する際の根本的な弱点を示しています。

なぜAIはアクセス制御を誤るのか

AIコード生成モデルには、特有の制約があり、broken access controlの脆弱性を生みやすくしています：

学習データの継承：AIモデルは、GitHubやStack Overflowなどのオープンソースプロジェクトを含む膨大な既存コードリポジトリから学習します。残念ながら、この学習データには安全なコードだけでなく、不安全なパターンや古いAPI、セキュリティコントロールの不備も含まれています。これらの欠陥パターンが頻繁に登場すると、AIはそれを再現しやすくなります。

コンテキスト認識の欠如：AIモデルは、あなたのアプリケーションのリスクモデルや内部標準、脅威の状況を理解しません。ビジネスロジックや展開環境を把握できず、User AがRecord Bにアクセスすべきかどうかを判断できません。これは深いドメイン知識と具体的なビジネス要件を必要とします。

機能優先の最適化：曖昧なプロンプトに対して、LLMsは最短経路で動作する解決策を最適化します。安全性よりも動作させることを重視し、ショートカットを行うことが多く、深刻なセキュリティ脆弱性を生むことがあります。

デフォルトでのセキュリティコントロール未実装：AI生成コードは、入力検証や認証チェック、認可コントロールを明示的に促さない限り、省略されることが多いです。例えば、「データベースに接続し、ユーザー情報を表示する」ようなプロンプトは、認証をバイパスし、リクエストユーザーのアクセス権を検証しないコードを生成しがちです。

「バイブコーディング」の現象

業界内で「バイブコーディング」と呼ばれる現象の台頭は、ソフトウェア開発における根本的な変化を示しています。2025年2月、元OpenAI研究者のAndrej Karpathyは、これを「開発者が完全にバイブに委ね、指数関数的な成長を受け入れ、コードの存在すら忘れる」と表現しました。

このアプローチは問題です。なぜなら、開発者はセキュリティ要件を明示しなくても動作するコードを得られるからです。セキュアなコーディングの責任は、研究によると、ほぼ半数のケースで誤った選択をするLLMsに移行しています。Veracodeの調査では、クロスサイトスクリプティング（CWE-80）やログインジェクション（CWE-117）に関する脆弱性について、LLMsが86%と88%のケースでこれらの脅威に対して安全なコードを生成できなかったと報告しています。

信頼のパラドックス

最も懸念されるのは、AI生成コードに関する信頼のパラドックスです。Perryら（2023）の研究では、AIアシスタントを使う開発者は、より多くの不安全なコードを作成しているにもかかわらず、自分たちがより安全なコードを書いたと信じていることが判明しました。Snykの調査では、約80%の開発者がAI生成コードはより安全だと誤信していると報告しており、これは危険な誤解です。これにより、監査の軽視と脆弱なコードの迅速な展開が促進されます。

この誤った自信は、AIの意思決定の「ブラックボックス」性によってさらに悪化します。AIツールを構築する開発者さえも、モデルがどのようにコードを決定しているか完全には理解できません。この不透明性は、AI生成コードの予測性を低下させ、従来のコードレビューでは見逃されがちなバグや脆弱性を導入する可能性があります。

速度とセキュリティのジレンマ

AIツールは、人間の開発者よりもはるかに高速でコードを生成できます。最初は純粋な利点に見えますが、この速度は重大なセキュリティの課題を引き起こします。潜在的に安全でないコードが、セキュリティチームの徹底的な評価よりも早くシステムに組み込まれる可能性があるのです。

開発の速度は、セキュリティレビューの能力を超えつつあり、脆弱性が見逃されるリスクが高まっています。AIによる迅速な展開は、セキュリティ専門家が「コンプライアンスの乖離」と呼ぶ現象を引き起こし、規制要件やセキュリティのベストプラクティスを無視した機能実装を促進します。

複合的な影響：フィードバックループと技術的負債

状況は、AIのトレーニングにおけるフィードバックループによってさらに複雑になっています。新しいAIモデルは、以前に生成されたAIコードをトレーニングデータに取り入れることがあります。そのコードに脆弱性があれば、それが次世代のモデルに伝播し、拡大し続けることになります。これにより、不安全なコードパターンの宇宙が拡大します。

この現象は、セキュリティ専門家が「セキュリティ負債」と呼ぶものに寄与します。未解決の脆弱性が蓄積し、時間とともに修復が困難かつ高コストになるのです。AI生成コードのセキュリティ検証を怠ると、この負債は持続不可能なレベルに達するリスクがあります。

業界の対応と現状

サイバーセキュリティ業界は、これらの課題に対して積極的に取り組んでいます。金融セクターは、脅威の深刻さを認識し、40%の金融企業がペンテストの頻度を四半期または継続的に増やすなど、対応を進めています。これは、定期的な評価から継続的なセキュリティ検証へのシフトを示しています。

技術リーダーも、AI生成コードの脆弱性に対処するためのソリューションを開発しています。例えば、GitHubのCopilot Autofixは、脆弱性修正を加速させ、開発者が問題を手動の3倍以上の速度で修正できることを示しています。これらのツールを使う開発者の修正率は、ほぼ50%からほぼ100%に向上しています。

しかしながら、これらの改善は全体的な傾向を逆転させていません。OWASP 2025 Top 10リストにServer-Side Request Forgery (SSRF)がbroken access controlのカテゴリーに加わったことは、アクセス制御の失敗が従来の信頼境界の違反だけでなく、より広範な範囲を含むことを示す認識の表れです。

今後の展望：多層防御戦略

broken access controlの危機に対処するには、伝統的な原因と新たなAI関連リスクの両方を認識した包括的な多層防御戦略が必要です：

ポリシーベースのアクセス制御の導入：役割チェックや複雑なif-elseロジックから、中央集権的なポリシー駆動の認可システムへ移行します。これにより、複雑なアーキテクチャに対応しやすく、ガバナンスも明確になります。

Zero Trustアーキテクチャの採用：すべてのアクセスリクエストに対して厳格な検証を行います。これには、一貫したアクセス制御、暗号化、監視が含まれます。

AI生成コードのセキュリティ強化：Static Application Security Testing (SAST)やSoftware Composition Analysis (SCA)ツールを開発フローに組み込み、AI生成コードの脆弱性を自動で検出します。CI/CDパイプラインにセキュリティフィードバックを直接組み込みます。

開発者教育の強化：AI生成コードの特有のセキュリティリスクについて、開発チームに教育します。AIコーディングアシスタントを「才能あるインターン」として扱い、初期ドラフトのレビューと改善を促します。

ガバナンス方針の策定：AIコーディングツールの使用範囲を明確に定めます。セキュリティに関わる重要なコンポーネントにはAIの使用を禁止し、低リスクの機能には奨励します。

継続的監視の実施：アクセスの定期レビューを自動化し、継続的に行います。これにより、休眠アカウントや過剰な権限を迅速に特定し、対処します。

セキュア・バイ・デフォルトの原則の徹底：システムをデフォルトでアクセス拒否に設定し、明示的な許可を必要とします。これは、人間の書いたコードとAI生成コードの両方に適用されます。

定期的なセキュリティテストの実施：ペンテストの頻度と範囲を拡大し、APIエンドポイントやアクセス制御の仕組みを重点的に評価します。自動化ツールと専門家の手動評価の両方を活用します。

今後の道筋

2025年のbroken access control脆弱性の増加は、AI生成コードによるものも含め、アプリケーションセキュリティの重要な転換点です。組織は、現代の開発の速度と性質に合わせてセキュリティ実践を適応させるか、セキュリティ負債を積み重ねて大きな侵害に至るかの選択を迫られています。

OWASP Top 10の連続トップにbroken access controlが位置し続けていることは、認識だけでは不十分であることを示しています。理解を具体的な技術的対策、包括的なガバナンス、そしてAIを活用した開発環境における認可の根本的な見直しに落とし込む必要があります。

AIが進化し、ソフトウェア開発のワークフローに深く浸透するにつれて、この課題はより深刻になり、改善には時間がかかるでしょう。これを乗り越える成功例は、セキュリティを単なるコストではなく、開発戦略の不可欠な要素と捉える企業です。リスクを生み出す技術と同じ速度で進化しなければなりません。

broken access controlの40%増加は単なる統計ではなく、2025年以降にソフトウェアを構築するすべての組織への行動喚起です。対応するかどうかではなく、どれだけ迅速かつ徹底的に必要な変革を実現できるかが問われています。