Mask passwords and other secrets

Login and signup tests put real credentials in your test data. By default those values appear in plain text everywhere Marriska records a run — the report, the live runner, step logs. Marking a variable sensitive hides its value (••••••) in everything we store or stream, while Playwright still types the real value into the page so the test works exactly as before.

Mark a variable sensitive

1. Open a test and go to the Variables tab.

2. In the variables table, click the lock icon on a column header (e.g. password). The icon turns solid to show it’s now sensitive, and every cell in that column shows •••••• instead of the value.

3. That’s it — the change saves automatically. The next run masks that variable’s value everywhere it would otherwise be recorded.

Once saved, a sensitive value is never shown again — not in the Variables tab, not to anyone else in your organization, not through the API. Click a hidden cell to type a replacement (leave it empty to keep the stored value), or press Clear to empty it.

To un-mark, click the lock icon again. If the column holds hidden values, you are asked first: they are cleared rather than revealed, so type them again if the column should keep them.

Note

You can only mark a variable that already exists in your steps as a {{placeholder}}. Sensitive is a property of the variable, so it applies across every run and every test set the test belongs to.

What gets masked

When a variable is sensitive, its resolved value is replaced with •••••• in:

• Run reports — step descriptions, the saved step log, and the per-iteration values shown next to a run.
• The live runner — the same masked text streams in real time.
• Runner history — past runs render the already-masked report.
• The generated step preview and YAML shown during a run.
• Screenshots — any form field holding a secret value is boxed out at capture (using Playwright’s screenshot masking), so the value isn’t visible in stored screenshots or in visual comparison.

The masking is done by replacing the literal value, the same way CI systems mask registered secrets in their logs. Very short values (1–2 characters) aren’t masked in free-flowing text, because they’d collide with ordinary words — use a real secret value.

What still happens normally

• The real value is still typed into the page. Masking only changes what Marriska records, never what the browser does — your login still logs in.
• Non-sensitive variables are untouched — only the columns you lock are masked.

Current limitations

Not yet covered

These are tracked for a later release. Marking a variable sensitive does not yet cover:

• Secrets shown as page text. Field masking covers values typed into form inputs. A secret that the page renders as text — e.g. echoed back on a confirmation screen — isn’t boxed out in the screenshot. (As defense in depth, sensitive tests also skip the external visual- comparison AI entirely and use local pixel-diff, so even an unmasked image never leaves the platform.)
• Older reports. Masking isn’t retroactive — reports created before you marked the variable keep their original text. An operator can run a one-time scrub to mask known values in old reports.

The CLI runner and local agent honor sensitivity too: the test spec they fetch includes which variables are sensitive, so their relayed events, local report, and screenshots are masked the same way as a cloud run. That spec does carry the values themselves, because a local run has to type them — anyone holding an API key for your organization can read them there. Only an owner or an admin can create an API key.

Through the API

A sensitive value is returned as {"hidden": true, "ref": "…"} — by every endpoint that returns a test’s data rows or a test set’s overrides. The ref proves which stored value you were shown; it contains no form of the value, differs on every read, and stops working after 24 hours.

To update a table, send each cell as exactly one of:

Send	Meaning
"a string"	Set the value
{"keep": "<ref>"}	Keep the hidden value the ref was issued for — wherever its row has moved since, and under a renamed column
{"clear": true}	Clear the value

A bare null, or the {"hidden": …} object sent back as it was received, is refused with 422, so nothing is kept or cleared by accident. A keep under a column that is no longer sensitive is a 422: type the value again or clear it. A keep whose value has changed since you read it — or whose ref is older than 24 hours — is a 409: fetch the test again and retry.

Related

• Run one test with many inputs — the variables and data table sensitive values live in
• Data handling — what Marriska stores, who can see it, and what’s sent to AI providers
• Security model — auth, access control, and org isolation