OWASP Top 10 を通じて、Webアプリケーションのセキュリティを学んでいきましょう。
OWASPとOWASP Top10についてはこちら。
https://biz.addisteria.com/what_is_owasp_top10/
今回は最新のOWASP TOP10 2025*で7位の座のAuthentication Failures（認証の失敗）について解説します。
こちら、前回の2021年版でも同じく７位でした（名称は変わっています）。
Laravelアプリケーション開発時の対策や、バイブコーディング（生成AIコーディング）でも役立つ対策も考えていきますね。
Authentication Failures（認証の失敗）
Authentication Failures（認証の失敗）について、公式説明ページはこちら：
これは、認証機能が弱すぎることによる脆弱性リスクです。
便利なフレームワークを使うと、安全な認証機能はあらかじめ実装されています。それにもかかわらず、この認証の失敗リスクは以前として存在しています。
例えば、下記のような状況が該当します。
- 分かりやすすぎるパスワードを使用する（Password1とかadminのような）
- ユーザーに漏洩した認証情報でアカウントを作ることを許す
- アカウント復旧やパスワード再設定が簡単にできてしまう
- 暗号化なし、平文のまま、あるいは弱いハッシュ化でパスワードを保存する
- 二段階認証がない
- セッション管理が不適切（ログアウト後もセッションが残ったままなど）
また、既知のユーザー名とパスワードの組み合わせによる一斉攻撃は、現在非常に一般的な攻撃です。たとえば、Winter2025 → Winter2026 といった感じで、パスワードの一部を変えて認証を試みていくものです。
もはやパスワードだけで大事なデータを守れる時代は、終わりつつありますね。
CWE（共通脆弱性タイプ）
このカテゴリーに含まれる主なCWE（脆弱性分類）は次のとおりです。
-
CWE-259：ハードコードされたパスワードの使用
-
CWE-297：ホストの不一致を伴う証明書の不適切な検証
-
CWE-287：不適切な認証
-
CWE-384：セッション固定
- CWE-798：ハードコードされた認証情報の使用
対策
このリスクに対して、下記のような対策が挙げられます。
-
二段階（二要素）認証機能を実装する
-
パスワードマネージャーにパスワードを作らせる
-
デフォルトの認証情報をそのままにしてデプロイしない
特に管理者ユーザーの場合は要注意 -
パスワードの強さをチェックする機能を実装する
-
アカウント作成時とパスワード変更時に、既知の漏洩認証情報リストと照合
-
パスワードの長さ、複雑性、繰り返し使用しているかをチェック
- パスワードの定期変更を強制しない
- アカウント列挙攻撃への対策
登録、認証情報復旧、APIのパスウェイをアカウント列挙攻撃から保護 - ログイン試行の制限
- 安全なセッション管理
- 信頼できる既製のシステムを使用
Laravelでの対策
Laravelは、スターターキットを使用してプロジェクトを作成すれば、デフォルトで使いやすく安全な認証機能が実装されています。
セッションについても適切に管理されており、デフォルトでは120分間（2時間）の非アクティブ時間でセッションが期限切れになります。
また最近の変更により、デフォルトで二段階（二要素）認証機能もつきました。この点について解説しますね。
二段階（二要素）認証機能がデフォルトで利用可能に
Laravelでは現在、スターターキットを使用してプロジェクトを作ると、Fortifyが使われます。Fortifyは、ログイン・登録・パスワードリセット・メール認証・2段階認証（2FA）などを提供する認証バックエンドです。
ただ、すべてのユーザーに対し二段階認証を義務付けるのは現実的ではない可能性もあります。
Webアプリによりますが、秘匿性の高いデータを扱っているのでなければ、通常ユーザーは二段階認証までは付けなくても良いでしょう。
一方、他のユーザーの管理を行う管理者ユーザーについては、二段階認証機能をつけておくと安心です。
また、すべてのユーザーに対して、メール認証機能の搭載はあったほうが良いかと思います。メール認証の搭載方法は、運営中の学習サイトの上級編などでもご紹介しています。ご興味あれば見てみてください。
基礎編は無料です。
古いプロジェクトの場合
古いプロジェクトの場合でも、ライブラリを使用して二段階機能を実装することは可能です。
機密データを扱うユーザーや、管理者などには付けておいた方が良いでしょう。
バイブコーディング（生成AIコーディング）での注意点
バイブコーディング（生成AIコーディング）ツールを使用して認証機能を搭載する場合は、バックエンドにSupabaseなどが使われたりします。
ツールによってはコードを全く意識せずに開発を進められますが、個人的には、認証機能まで実装する場合には、ある程度仕組みを知っておいた方がよいと思います。
特に重要な個人情報を収集するようなツールを作る場合には、何かあった時に、大きな問題に発展しかねません。
さいごに
認証は超基本ポイントですよね。
いちから実装するより、既存の安心できるライブラリを使うほうが安全だと思います。また、ユーザーの役割に応じた認証機能を実装しておくとよいでしょう。
OWASP Top10で学ぶセキュリティ、次の項目はこちら。
