Тестування листів для відновлення OAuth без використання реальних поштових скриньок

Спрощене тестування листів для відновлення OAuth створює ризики для безпеки. Багато команд надсилають посилання для скидання пароля на одну спільну поштову скриньку. Вони перевіряють, чи прийшов лист, і йдуть далі. Цей метод є недосконалим. Він приховує повторне використання токенів, доставку не тому користувачу та витік конфіденційних даних у логах.

Використовуйте тимчасову електронну адресу для кожного запуску тесту. Ізолюйте подію, перевірте її та видаліть дані. Це запобігає змішуванню тестових даних, через яке результати стає важко підтвердити.

Хороша модель загроз має містити такі запитання:

  • Чи дійшов лист саме до тієї поштової скриньки, яка призначена для цього конкретного запуску?
  • Чи закінчується термін дії посилання або коду саме тоді, коли це має статися?
  • Чи не розкриває тема листа занадто багато даних користувача?
  • Чи може старий токен працювати після нового запиту?
  • Чи зберігають логи секрети відновлення довше, ніж це необхідно?

Найкращий патерн — одна поштова скринька на один запуск тесту. Це дозволяє прив'язати кожне посилання та часову мітку до конкретного прогону.

Дотримуйтесь такого алгоритму:

  • Створіть нову фікстуру користувача або ідентифікатор у пісочниці (sandbox).
  • Направте лист для відновлення на поштову скриньку, обмежену межами поточного запуску.
  • Один раз ініціюйте дію відновлення OAuth або пароля.
  • Переконайтеся (assert), що надійшов рівно один відповідний лист.
  • Відкрийте посилання або введіть код, щоб перевірити термін дії та поведінку одноразового використання.
  • Негайно видаліть дані поштової скриньки та фікстури.

Якщо ваш процес вимагає перевірки вчорашніх листів, ваш процес зламаний. Докази відновлення ніколи не повинні залежати від застарілих даних.

Перевірте ці пункти перед релізом:

  • Псевдонім отримувача відповідає тестовій ідентичності.
  • Для події існує лише одне дійсне повідомлення для відновлення.
  • Тема та прев'ю не розкривають конфіденційних даних.
  • URL-адреса відновлення веде на правильне середовище.
  • Токен стає недійсним після використання або закінчення терміну дії.
  • Поведінка при повторних спробах не залишає активними кілька дійсних токенів.

Уникайте цих поширених помилок:

  • Повторне використання однієї скриньки для кількох тестових користувачів.
  • Зберігання URL-адрес відновлення в довгострокових логах.
  • Включення повних адрес електронної пошти в теми листів для відновлення.
  • Забування про анулювання старих посилань після повторного запиту.

Дані стейджингу мають значення. Вони часто містять реалістичні імена та конфігурації. Використовуйте безпечні налаштування за замовчуванням: короткий термін зберігання, одноразові секрети та явне очищення.

Source: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni