開発者向け電子メールテストチェックリスト: リクエストから有効期限まで

電子メールのテストは、メッセージが表示されたことを確認するだけではありません。信頼性の高いテストでは、アプリケーション リクエストから配信、レンダリング、ユーザー アクション、有効期限、および再試行動作までのイベントを追跡します。また、フローが安全に失敗するかどうかもチェックします。

このチェックリストは、自分が所有しているシステムとアカウント、またはテストを許可されているシステムとアカウントに対してのみ使用してください。一時的な受信トレイを使用して、一括アカウントを作成したり、別の Web サイトの制限を回避したり、許可なくサードパーティのリセット フローをテストしたりしないでください。 Once Email はメッセージのみを受信します。応答は送信されないため、送信者のアプリケーション内で何が起こったかを証明できません。

1. メールをリクエストする前に 1 つのテスト ケースを定義します。

ボタンを押す前に、環境、ビルド、ブラウザ、機能、および予想される結果を記録します。各実行に signup-valid-address や reset-expired-link などの中立的な識別子を与えます。テスト名にパスワード、トークン、または個人アドレスを含めないでください。

製品が実際にサポートするパスのケースを準備します。

• 有効なサインアップまたはアドレス検証リクエスト。
• 明らかな入力エラーのある住所。
• 最初のメッセージがまだ有効である間に繰り返されるリクエスト。
• 有効期限が切れたコード、またはすでに使用されているコード。
• 既存のアカウントと存在しないアカウントの両方に対するパスワード リセット リクエスト。
• キャンセル、ナビゲーションに戻る、および関連する場合は 2 番目のブラウザ セッション。

OWASP Web セキュリティ テスト ガイド では、リセットをアカウントへの代替ルートとして扱い、サポートされているすべてのインターフェイスを確認することを推奨しています。したがって、動作が異なる可能性がある場合、テスト計画では Web インターフェイス、モバイル アプリケーション、および API を個別にカバーする必要があります。

2. ユーザーを列挙せずにリクエストの応答を確認する

承認されたリクエストを 1 つ送信し、表示される応答、ステータス、時間を記録します。パスワードを回復する場合、既存のアカウントと存在しないアカウントで、明らかに異なるメッセージや応答タイミングを通じてアカウント メンバーシップを開示してはなりません。

これをテストするために大規模なサンプルを生成しないでください。負荷、悪用、レート制限のテストをシステム所有者と調整し、専用の環境を使用して、承認された境界で停止します。 OWASP の パスワードを忘れた場合のチートシート では、リセットされたエンドポイントによってアカウントの存在が公開されたり、受信トレイがあふれたりする可能性があるため、一貫した対応と過剰な自動送信に対する保護を推奨しています。

2 回目のクリックによって、同時に有効なシークレットの安全でないコレクションがサイレントに作成されないことを確認します。意図されたポリシーでは、最初のコードを無効にしたり、保留中のリクエストを再利用したり、慎重に制限された数を許可したりする可能性があります。製品チームはどの結果が正しいかを定義する必要があります。

3. 即時アサーションではなく、時間指定された状態として配信を観察する

アプリケーションがリクエストを受け入れたときにタイマーを開始します。メッセージが表示された時点を記録します。ただし、数秒の遅延を失敗として扱うのではなく、合理的な観察期間を使用してください。メールはキューとフィルターを通過するため、到着時間は固定された定数ではなく分布になります。

承認された低リスクテストに Once Email を使用する場合:

1. 残り有効期間が十分にある受信専用アドレスを作成または選択します。
2. アドレスをテスト対象のアプリケーションに正確にコピーします。
3. 1 つのメッセージをリクエストし、受信箱を開いたままにします。
4. 表示されない場合は、慎重に更新し、確認メールのトラブルシューティング チェックリスト] に従ってください。
5. リクエストと観測された到着時刻を UTC で記録し、テスト環境も記録します。

メッセージが見つからないからといって、送信者がメッセージを送信していないことが証明されるなどと主張しないでください。アプリケーション ログ、プロバイダー イベント、メッセージ ヘッダーは別個の証拠ソースです。可能であれば、テスト システムによって作成された相関値を使用しますが、アクセスを許可したり、ユーザーを識別したりする場合は公開しないでください。

4. メッセージをコンテンツおよびデータとして検証する

受信した件名、送信者ドメイン、表示される目的を承認されたテンプレートと比較します。アプリケーションがプレーンテキストと HTML の両方を生成する場合は、どちらの代替案も確認してください。デスクトップと狭いモバイル ビューポートでのコンテンツの間隔、折り返し、色のコントラスト、および意味のある順序を確認します。

次に、変数データを確認します。

• 意図したテストアドレスが必要な場所に表示され、予期しない場所には表示されません。
• 環境名は、ステージングメールが実稼働メールと間違われるのを防ぐのに十分明確です。
• 日付と有効期限のステートメントでは、明確なタイムゾーンが使用されます。
• コードまたはアクションが正しいテスト ケースに関連付けられている。
• リンクは HTTPS と予期されるホストを使用します。
• 内部スタック トレース、API キー、パスワード、または無関係な顧客データは表示されません。

リンク先を見つけるためだけに、疑わしいリンクを開かないでください。メッセージ HTML をブラウザのローカル 電子メール リンク チェッカー ] にコピーして、電子メールをレンダリングせずに URL とリモート リソースをリストし、宛先ホストをテスト仕様と比較します。

5. 演習の成功、再利用、有効期限切れ

コードまたはリンクについては、承認されたハッピー パスを 1 回テストします。意図したアクションのみを実行し、正しい環境に到達し、不要なページ要素や分析イベントでシークレットが公開されていないことを確認します。

次に、セキュリティの移行を確認します。

• 使い捨てシークレットは成功後に機能を停止します。
• 期限切れのシークレットは、アクションを完了せずに拒否されます。
• 不正な値は安全に失敗します。
• 交換リクエストは文書化された無効化ルールに従います。
• 別のブラウザでアクションを開いても、必要なコンテキストはバイパスされません。
• パスワードをリセットしても、多要素認証が自動的に弱くなったり、不要なセッションがアクティブなままになったりすることはありません。

OWASP では、ランダムで十分な長さがあり、安全に保存され、使い捨てで有効期限が切れているリセット シークレットを推奨しています。また、HTTPS リセット URL と推測に対する保護も推奨しています。テストでは、制御されていない強引な試みではなく、製品の動作を検証する必要があります。

6. テスト失敗メッセージとリカバリ

配信が遅れたり、コードの有効期限が切れたり、リンクがすでに使用されている場合、ユーザーは有益な次のステップを必要とします。エラーによってアカウントの存在、秘密の断片、内部インフラストラクチャが明らかにならないことを確認します。インターフェイスでは、迅速なリクエストの繰り返しを奨励することなく、正当な再試行を許可する必要があります。

また、アカウント フローが完了する前に一時受信トレイの有効期限が切れた場合に何が起こるかをテストします。使い捨てアドレスは、アカウントの長期的な回復、領収書、またはセキュリティ通知が必要な場合には適していません。 一時的な電子メールと永続的な電子メール ガイド では、永続的な管理されたアドレスがより安全なテストの前提となる場合について説明しています。

7. 最小限の再現可能な結果を​​記録する

有用なテスト結果には、ケース、環境、ビルド、UTC タイムライン、期待される結果、実際の結果、および慎重に編集された 1 つの証拠アイテムが含まれます。問題がリクエストの作成、メッセージ配信、コンテンツ、アクション、有効期限、または回復のいずれにあるのかを述べます。 「メールが壊れている」などのあいまいな結果は避けてください。

証拠にアドレス、検証コード、リセット リンク、メッセージ ID、Cookie、または内部ホスト名が含まれている場合は、変更せずにアップロードしないでください。問題に添付する前に、電子メール テスト証拠編集ガイド] に従ってください。

リリース決定チェックリスト

フローを準備完了とマークする前に、承認された成功ケースが合格し、否定ケースが安全に失敗すること、再試行と有効期限のルールが仕様と一致していること、コンテンツが狭い幅で動作していること、ログや分析に機密情報が入っていないこと、使用可能な資格情報を公開することなく証拠が失敗を再現できることを確認してください。 1 回の正常な到着は有用な証拠ですが、それは完全な電子メール フロー テストではありません。