Тестовую инфраструктуру часто считают служебной и безопасной по определению, и это опасное заблуждение. E2E-набор хранит учётные данные, ходит в реальные окружения, записывает traces с настоящими запросами и ответами. У всего этого есть модель угроз, как у продакшена: утёкший тестовый ключ, доступный извне test API, опубликованный trace с токеном - это реальные бреши. К тестовой инфраструктуре применяют ту же дисциплину, что к боевой.
Первое правило - учётные данные не в репозитории. Пароли и ключи тестовых аккаунтов хранят в секретах CI, а не в коде и не в конфиге; в тест они попадают через переменные окружения. Закоммиченный секрет остаётся в истории git навсегда, даже если его потом убрать, и виден каждому, у кого есть доступ к репозиторию. Это самая частая и самая дешёвая для атакующего утечка - и самая легко предотвратимая.
Второе - артефакты тестов чувствительны. Каталог с сохранённым storageState содержит живые cookies сессии; traces и videos - DOM, заголовки запросов, ответы API и введённые в поля данные. Всё это может нести токены и персональные данные. Относиться к ним надо как к чувствительным: ограниченный доступ, ограниченная ретенция, и никакой публичной ссылки на trace с внутренностями сессии.
Третье - тестовый API нуждается в собственной защите. Эндпоинты, через которые тесты создают данные в обход UI, - это мощный инструмент, и в проде он не должен существовать или должен быть закрыт отдельным ключом. Открытый в продакшене test API, позволяющий создавать пользователей и заказы, - это готовая дыра. Его защищают отдельным секретом и делают недоступным в боевом окружении, а не полагаются на то, что "о нём никто не знает".
Полезно один раз свести правила безопасности тестов в чек-лист, чтобы свериться при заведении окружения. Ниже - список из ключевых пунктов: секреты, чувствительные артефакты, защита test API, изоляция от боевых сервисов, безопасный production smoke, ограниченный доступ. К нему возвращаются, когда добавляют новое окружение, интеграцию или тип артефактов, - чтобы не открыть брешь по невнимательности.
| Правило | Что защищает |
|---|---|
| Credentials в CI secrets, не в репозитории |
| Утечка ключей в историю git |
| .auth, traces, videos под ограниченным доступом | Токены и PII в артефактах |
|---|
| Test API за отдельным ключом, закрыт в проде | Создание данных в обход UI |
|---|
| E2E без прод-платежа, email, SMS | Реальные списания и рассылки |
|---|
| Production smoke read-only или synthetic-аккаунт | Порча боевых данных |
|---|
| Ограниченный retention и доступ к артефактам | Долгоживущие утечки |
|---|
Отдельная граница - боевые внешние сервисы. E2E-окружение не должно использовать продакшен-платёж, реальную рассылку email и SMS: тест не обязан списывать деньги или слать письма настоящим людям. Для этого есть sandbox и тестовые режимы провайдеров. Смешать тестовое окружение с боевыми внешними сервисами - значит однажды провести реальный платёж или разослать тестовые уведомления клиентам, что дорого и репутационно, и юридически.
Production smoke требует особой осторожности. Прогонять несколько сценариев на живом проде после деплоя полезно - это проверяет, что реальная система работает. Но такие тесты должны быть read-only или работать с выделенным synthetic-аккаунтом, а не менять данные настоящих пользователей. Тест, создающий или удаляющий что-то в проде под обычным аккаунтом, из инструмента доверия превращается в источник инцидентов.
Типичные провалы безопасности тестов предсказуемы. Секрет в репозитории, навсегда осевший в истории git. Опубликованный trace или открытый каталог артефактов с живыми cookies и токенами. Открытый в проде test API без отдельного ключа. И production smoke, меняющий реальные данные вместо read-only или synthetic-аккаунта. Держите секреты в CI, артефакты - под ограниченным доступом, test API - закрытым в проде, а боевые сервисы - вне тестового окружения.