なぜパスワードリセットのテストが軽視されるのか

ほとんどの開発者は自分のメールアドレスでパスワードリセットフローを一度テストして終わりにします。5回目のテスト実行後には、受信トレイは同じように見える「パスワードをリセット」メッセージで埋め尽くされます。どのリンクがどの実行に属するかの追跡を失い、最終的には面倒くさくなって徹底的なテストをやめてしまいます。まさにその種の怠慢が深刻なバグを本番環境に侵入させます。

パスワードリセットフローで実際にテストする必要があること

単純な「メールを送信するか」というチェックは不十分です。OWASP Authentication Cheat Sheet は包括的な要件セットを詳細に説明しています：

• メール配信 — リセットメールが届くか、また速やかに届くか
• リンクの正確性 — メール内のリンクが正しいトークンで正しいページに誘導するか
• トークンの有効期限 — 25時間後にリンクをクリックした場合、期限切れトークンが正しく拒否されるか
• 一回限りの使用 — 同じリセットリンクを二度使用できるか（できてはいけない）
• 新しいリクエスト時のトークン無効化 — ユーザーが再度リセットを要求した場合、最初のトークンが無効になるか
• SSOアカウント — OAuthで登録したユーザーの場合はどうなるか
• レート制限 — アドレスごとのリセットリクエスト数に制限があるか

一時メールのアプローチ — ステップバイステップ

最もクリーンな解決策は、各テスト実行に新鮮な一時的なメールアドレスを使用することです。一時受信トレイを開き、アドレスをコピーし、アプリケーションにテストアカウントを登録し、リセットをトリガーして、リアルタイムでメールの到着を確認します。リンクをクリックし、完全なフローを確認し、ログインが機能することを確認します。別のシナリオのためには、新しいブラウザタブを開くだけです。

トークンセキュリティチェックリスト

パスワードリセットトークンは一般的な攻撃面です。OWASP によれば、安全な実装は次の要件を満たす必要があります：

• 少なくとも32文字、暗号学的にランダムに生成
• 24時間以内、理想的には1時間以内に期限切れ
• 一回限りの使用 — 換金後すぐに無効化
• 新しいリセットが要求されたときに無効化
• メールアドレスごとにレート制限
• 平文でログに記録しない

リグレッションスイートにパスワードリセットを含める

パスワードリセットは認証ライブラリが更新されると静かに壊れます。少なくとも基本的なエンドツーエンドテストを追加してください：テストアカウントをプログラムで作成し、リセットをトリガーし、送信メールを傍受してトークンを確認します。MXToolbox でドメインの認証設定を確認し、実際のセキュリティ侵害についてTroy Hunt のブログを参照してください。