Test infrastructure is often considered something auxiliary and safe by definition, and this is a dangerous delusion. An E2E suite stores credentials, goes into real environments, records traces with real requests and responses. All of this has a threat model, exactly like production: a leaked test key, an externally reachable test API, a published trace with a token are real breaches, not theoretical ones. The same discipline is applied to test infrastructure as to the live one.
The first rule - credentials not in the repository. Passwords and keys of test accounts are kept in CI secrets, not in the code or config; they reach the test through environment variables. A committed secret stays in git history forever, even if removed later, and is visible to everyone with repository access. This is the most frequent and, for an attacker, the cheapest leak - and the easiest to prevent.
The second - test artifacts are sensitive. The directory with a saved storageState contains live session cookies; traces and videos contain the DOM, request headers, API responses and data typed into fields. All of this may carry tokens and personal data. Artifacts must be treated as sensitive: limited access, limited retention, and by no means a public link to a trace by which anyone could see the session internals.
The third - the test API needs its own protection. The endpoints through which tests create data bypassing the UI are a powerful tool, and in production it must not exist or must be closed off by a separate key. A test API open in production, allowing the creation of users and orders, is a ready-made hole. It is protected with a separate secret and made inaccessible in the live environment, rather than relying on "nobody knows about it".
It helps to gather the test security rules into a checklist once, to verify against when setting up an environment. Below is a list of key points: secrets, sensitive artifacts, protecting the test API, isolation from live services, a safe production smoke, limited access. You return to it when adding a new environment, integration or type of artifacts - so as not to open a breach through carelessness.
| Rule | What it protects |
|---|
| Credentials in CI secrets, not the repository | A key leak into git history |
|---|
| .auth, traces, videos under limited access | Tokens and PII in artifacts |
|---|
| Test API behind a separate key, closed in prod | Creating data bypassing the UI |
|---|
| E2E without prod payment, email, SMS | Real charges and mailings |
|---|
| Production smoke read-only or a synthetic account | Corruption of live data |
|---|
| Limited retention and access to artifacts | Long-lived leaks |
|---|
A separate boundary is live external services. The E2E environment must not use production payment, real email and SMS sending: a test need not charge money or send letters to real people. There are sandboxes and test modes of providers for this. Mixing the test environment with live external services means one day making a real payment or sending test notifications to customers, which is costly both reputationally and legally.
A production smoke requires special caution. Running a few scenarios on the live production after deploy is useful - it checks that the real system works. But such tests must be read-only or work with a dedicated synthetic account, not change real users' data. A test that creates or deletes something in production under an ordinary account turns from a tool of trust into a source of incidents on live data.
The typical test security failures are predictable. A secret in the repository, settled in git history forever. A published trace or an open artifacts directory with live cookies and tokens. A test API open in production without a separate key. And a production smoke changing real data instead of read-only or a synthetic account. Keep secrets in CI, artifacts under limited access, the test API closed in production, and live services out of the test environment.