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.

To edit a masked value, click the cell — it reveals the input while you type, then re-masks. To un-mark, click the lock icon again.

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.

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