Secrets in Playwright traces: what a trace contains and how to keep tokens out

What a Playwright trace records

The trace viewer is the best debugging tool Playwright has because it records almost everything about a test. According to the Playwright docs, the viewer shows:

• Actions with the locator used and how long each took, plus DOM snapshots before, during and after each action. Snapshots are on by default.
• Screenshots as a film strip of the page during the test.
• Console output from the browser and from your test.
• Network: every request with its method, status, request headers, response headers, request body and response body.
• Source: the test source code, next to the action that ran.
• Attachments such as visual comparison images.

Every one of these can carry a secret. The Authorization header of an API call, a Set-Cookie with a session id, a login response with an access token in its JSON body, a console.log(process.env) someone added while debugging, a token rendered on an admin page and captured in a snapshot.

Where the leaks usually come from

Logging in through the UI or an API

A test that logs in produces a session. The response that sets the cookie, and every later request that sends it, are in the network log. Playwright's authentication guide warns that the saved browser state file may contain sensitive cookies and headers that could be used to impersonate you or your test account, and recommends keeping playwright/.auth out of git. The same cookies are in the trace.

Extra headers and API testing

Headers you add for every request, for example with extraHTTPHeaders in use, are sent on each request and recorded with it. API tests that call your backend with a bearer token record that header too.

Debug output

Console output is part of the trace. A temporary console.log of a config object or of process.env ends up in every trace recorded while it is there.

Data on screen

DOM snapshots and screenshots show the page as it was. If a page shows an API key, a reset link or real personal data, so does the trace. Screenshots and videos are images: no text redaction can clean them.

Who can see your traces

Traces usually travel inside the HTML report or test-results/, uploaded as a CI artifact. On GitHub Actions, people who are signed in to GitHub and have read access to the repository can download workflow artifacts. On a public repository that is everyone with a GitHub account. On a private one it is everyone in the organization with read access, for as long as the artifact is kept.

Viewing is safer than it looks: Playwright documents that trace.playwright.dev loads the trace entirely in your browser and does not transmit any data externally. The risk is the file itself, wherever it is stored or shared.

How to keep secrets out

1. Use accounts and keys made for tests

Run tests with test users and API keys that only work in the test environment, with as little access as possible, and rotate them. Then a leaked trace exposes a key that opens nothing important. This matters more than any other step.

2. Record traces only when they help

trace: 'on' records every test. 'on-first-retry' records only the first retry, and 'retain-on-failure' records every run but keeps the trace only when the test failed. Fewer traces means fewer files with secrets in them:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    trace: 'retain-on-failure', // or 'on-first-retry'
  },
});

3. Turn off what you do not need

The trace option also takes an object. In Playwright 1.63 it accepts mode plus snapshots, screenshots, sources and attachments, so you can, for example, keep snapshots but leave your test source out of the file:

use: {
  trace: { mode: 'retain-on-failure', sources: false, screenshots: false },
},

Network headers and bodies stay in the trace whatever these options say, because they are what makes a trace useful for debugging. That is why the next two steps matter.

4. Keep artifacts private and short-lived

Upload reports and traces only from jobs that need them, set a short retention-days on actions/upload-artifact, and be careful with public repositories. Never paste a trace.zip from a real environment into an issue or a chat.

5. Keep secrets out of logs

Read secrets from environment variables, never print them, and remove debug logging before merging. CI systems mask known secret values in their own logs, but that masking does not reach inside a trace.zip.

6. Redact before traces leave CI

If traces are sent anywhere outside your CI, redact them on the way out: blank sensitive headers and cookies, scan bodies and console output for token patterns, and drop the source files. Do it in CI, before upload, so the raw trace never leaves your infrastructure.

How TurnSignal handles traces

TurnSignal keeps your Playwright traces next to each test's history and opens them in the browser from the run page. Because traces carry secrets, the reporter treats them carefully:

• Traces are redacted in your CI before upload: Authorization, cookie and other sensitive headers are blanked, and common secret formats (tokens, passwords, keys, and the values of secret-looking CI environment variables) are replaced in the network log, console output and text resources.
• Your test source code is left out of uploaded traces by default.
• A trace that cannot be redacted safely is not uploaded, never sent raw.
• Screenshots and videos can't be redacted, so you choose what to send (TURNSIGNAL_ARTIFACTS=trace,screenshot or none), and project owners can turn artifacts off.

Redaction matches known patterns and sensitive names, so it can miss an unusual secret. Test-only credentials (step 1) are still the real protection. The docs list what is redacted and how to add your own patterns.