OWASP Top 10 を通じて、Webアプリケーションのセキュリティを学んでいきましょう。
OWASP Top10はWebアプリの代表的なセキュリティリスクをまとめた「10大リスク」リスト。
世界中の開発者・企業・教育機関が、セキュリティに関する共通基準として活用している指針といえます。
https://biz.addisteria.com/what_is_owasp_top10/
今回は最新のOWASP TOP10 2025*で、2021に続きトップ１位の座に輝いたBroken Access Control（アクセス制御の不備）について解説します。
Laravelアプリケーション開発時の対策や、バイブコーディング（生成AIコーディング）でも役立つ対策も考えていきますね。
Broken Access Control（アクセス制御の不備）
公式ページはこちら：
Broken Access Controlは、「認可（Authorization） の不備」と解釈できます。
誰が何をどこまでできるか―その制御が正しく設定されていない状態や、ルールが破られてしまう状態を指します。
たとえば、
-
権限がない他人のアカウント情報を閲覧できてしまう
-
非管理者が管理ページへ直接アクセスできてしまう、
といったケースです。
CWE（共通脆弱性タイプ）
このカテゴリーに含まれる主なCWE（脆弱性分類）は次のとおりです。
-
CWE-200：権限のないユーザーに機密情報が露出する
-
CWE-201：通信データ中に機密情報が挿入される
-
CWE-352：クロスサイトリクエストフォージェリ（CSRF）
- CWE-918：サーバーサイドリクエストフォージェリ（SSRF）
CWE918 SSRFは、サーバーを踏み台にして、本来アクセスできない内部ネットワークなどに不正なリクエストを送信する脆弱性のことです。以前は単独でランキングしていましたが、OWASP TOP10 2025年度版では、Broken Access Controlの中に統合されました。
対策
これに対して、下記のような対策が挙げられます。
-
基本は「拒否がデフォルト」
公開リソース以外は、アクセスを明示的に許可する方式にする。 -
認可ロジックは一箇所に集約
各画面で個別にチェックするのではなく、共通の仕組みを再利用。 -
「所有者」単位で制御
データは「自分のもの」だけ操作できるようにし、他人のレコードは触れないようにする。 -
アプリケーション固有の業務ルールは、ビジネスロジック層で強制
-
不要な情報を公開しない
.gitやバックアップファイルをサーバー上に置かない。ディレクトリ一覧も無効に。 -
アクセス失敗を記録・通知
認可エラーが続いた場合はログを残し、必要なら管理者にアラートを出す。 -
APIへの過剰アクセスを防ぐ
レートリミットを設定して、自動攻撃ツールによる負荷や不正試行を抑制。 -
セッション管理を正しく行う
ログアウト時にはセッションを破棄。JWTは短命トークンにし、長期間有効なJWTが必要な場合はOAuth標準で失効管理する。 - 実績あるツールの標準的なアクセス制御を使う
ツールキットやパターンが提供する標準的でシンプルなアクセス制御を使う
Laravelでの対策
Laravelで開発する場合、Gate や Policy といった機能により、認可（Authorization）をアプリ全体で一貫して管理できます。また、特定のルートを守る Middleware も有効です。
GateやMiddlewareについては、拙著『Laravelの教科書』で詳しく解説しています。
クリックするとamazonページへ。
↓↓↓
また、運営中の学習サイト「Laravelの教科書」の上級編でも、実際のアクセス制御を扱っています。ご興味あれば、下記ボタンをクリックして詳細をご覧ください（基礎編は無料です）。
バイブコーディング（生成AIコーディング）での注意点
最近では、生成AIツールを活用してコードを生成する方法が広まっています。便利な一方で、生成されたコードの権限設定が抜け落ちている ケースも少なくありません。
たとえば、
-
APIのエンドポイントに認可チェックがない
-
管理者ページへのアクセス制御が未設定
-
テスト環境のまま本番へデプロイ
といった「AIが生成したコードを信じすぎて検証しない」リスクが発生しがちです。
実際に、管理者アカウントの乗っ取りから、すべてのユーザーデータが漏洩する事件も発生しています。
レコードの所有者単位で制御・「必要最小限の権限しか与えない」という原則を意識し、生成されたコードをレビュー・補強することが重要です。
まとめ
Broken Access Control（アクセス制御の不備）は、技術的な設定ミスというより、設計段階の考え方の甘さ から生まれることも多い脆弱性。
とはいえ、「誰が何をどこまでできるか」は、Webアプリごとに異なるため、機械的な一律チェックが難しい部分といえます。
だからこそ、リスクが高いとして、トップ10の最初に位置付けられているのですね。
安全なWebアプリを開発するためには、設計段階で、この部分への対策をしっかりと考える必要があります。
OWASP Top10で学ぶセキュリティ、２個目の項目はこちら。
