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