👑 OWASP 1位！壊れたアクセス制御 (Broken Access Control) を徹底解説

11月 5, 2026

—

こんにちは！ 👋 今日は、開発者とセキュリティ担当者なら必ず知っておくべきOWASP Top 10 2021の堂々たる1位、壊れたアクセス制御 (Broken Access Control) について、分かりやすく詳しく解説します。2017年の5位から1位に急上昇しただけに、本当に重要で頻繁に発見される脆弱性ですので、ぜひ集中してご覧ください！

🤔 アクセス制御？それは何ですか？

最も簡単に例えるなら、「鍵」のようなものです。🔑

家主: すべての部屋に入れるマスターキーを持っています。(管理者)
家族: 自分の部屋とリビング、トイレの鍵を持っています。(一般ユーザー)
部外者: どの鍵も持っていないため、家に入ることができません。(認証されていないユーザー)

このように、アクセス制御(Access Control)は、ユーザーが誰であるか、そしてそのユーザーがどのような権限を持っているかを確認し、許可された作業のみを実行するように制御するセキュリティの核心原則です。つまり、「あなたはこのドアを開けることができます」または「あなたはこのボタンを押すことはできません」を決定するシステムなのです。

「壊れたアクセス制御」は、まさにこの鍵システムが故障した状態を指します。部外者が私の部屋に勝手に入ったり、一般ユーザーが管理者のみがアクセスすべき秘密の空間に入ったりする恐ろしい状況が発生するのです。😱

🚨 なぜ1位になったのでしょうか？

OWASPによると、分析されたアプリケーションの94%で何らかの形で壊れたアクセス制御の脆弱性が発見されたとのことです。これは、ほぼすべてのWebアプリケーションがこの問題にさらされていることを意味します。ユーザー認証(ログイン)機能はうまく作られていても、ログイン後に各ユーザーの権限をページごとに細かく確認するロジックを見落とすケースが多いためです。

🕵️‍♀️ 壊れたアクセス制御の代表的なタイプ

どのような場合にアクセス制御が「壊れた」と言えるのでしょうか？代表的な事例を通して見ていきましょう。

1. 不安定な直接オブジェクト参照 (IDOR – Insecure Direct Object References)

最も一般的で直感的なタイプです。URLアドレスやパラメータにある単純な数字(ID)を変更して、他の人の情報にアクセスする攻撃です。

攻撃シナリオ 🧑‍💻

ハッカーが自分の投稿を確認します。URLはです。
好奇心を持ったハッカーは、URLのid値を101に変更してリクエストします。 ()
サーバーがこのリクエストが正当なユーザーからのリクエストであるかを確認しないと、101番の投稿(他の人の非公開記事)がそのまま公開されてしまいます！

2. 権限昇格 (Privilege Escalation)

ユーザーが元々持っていた権限よりも高い権限を獲得する場合です。大きく二つに分けられます。

垂直的権限昇格 (Vertical Privilege Escalation) 👩‍💼 ➡️ 👑
一般ユーザーが管理者(Admin)権限を得る場合です。
例: 管理者ページURL()を見つけて直接アクセスしたところ、権限チェックが行われず、管理者ページがそのまま開いてしまう状況です。
水平的権限昇格 (Horizontal Privilege Escalation) 👤 ➡️ 👤
同じ等級の他のユーザー情報にアクセスする場合です。
例: 上で説明したIDORが代表的な水平的権限昇格攻撃です。user/123からuser/124にアクセスして他のユーザーの情報を閲覧するものです。

3. 機能レベルのアクセス制御の欠落

ユーザーインターフェース(UI)では特定のボタンやメニューを隠してアクセスを阻止したが、サーバーでは該当機能へのアクセスを阻止していない場合です。

攻撃シナリオ 😈

一般ユーザーには「ユーザー削除」ボタンが表示されません。
しかし、ハッカーは開発者ツールを通じて「ユーザー削除」機能のAPIアドレス()を突き止めます。
このアドレスを直接呼び出した際、サーバーがリクエストしたユーザーが管理者であるかを確認しないと、50番のユーザーはそのまま削除されてしまいます。

🛡️ どうすれば防げるでしょうか？ (防御方法)

壊れたアクセス制御を防ぐための核心原則は簡単です。「誰も信じるな、すべてのリクエストを疑え！」

デフォルトで全て拒否 (Deny by Default) 🔒 最も重要な原則です。特定の権限を明示的に許可するまでは、すべてのアクセスをデフォルトで遮断する必要があります。ホワイトリスト方式と考えると分かりやすいです。
集中化されたアクセス制御ロジックの実装 ⚙️ 権限チェックロジックをあちこちに散らばらせると、ミスが発生しやすくなります。一箇所で権限を管理し、すべてのリクエストがこの集中化されたロジックを通過するように設計する必要があります。
サーバーで！すべてのリクエストに対して！権限チェック 🖥️✔️ ユーザーの目に見える画面(クライアント)で何かを隠すことは何の意味もありません。すべてのリクエストがサーバーに到達した際、該当ユーザーがこの作業を実行する資格があるかを必ずサーバー側で再度確認する必要があります。
最小権限の原則 (Principle of Least Privilege) ユーザーには必要最小限の権限のみを付与してください。一般ユーザーに管理者機能にアクセスする権限を与える必要は全くありません。
推測しにくいIDの使用 1, 2, 3のような順次的な数字IDの代わりに、a1b2c3d4-e5f6-….のような複雑で推測しにくいUUID(Universally Unique Identifier)を使用すると、IDOR攻撃をはるかに困難にすることができます。

✨ 終わりに

壊れたアクセス制御は、ごく些細なミスから生じますが、その結果は個人情報漏洩からシステム掌握まで非常に致命的となる可能性があります。「これくらいなら大丈夫だろう」という安易な考えが最大の敵です。

今日からでも、自分が作る機能について「このリクエストを送ったユーザーは本当にこの作業を行う権限があるのか？」と常に自問自答する習慣をつけてみてはいかがでしょうか？それが安全なウェブ世界を築く第一歩となるでしょう！