Cucumber JVM default formatters output step arguments with unredacted sensitive data
0 reputation · 01 Sept 2026, 13:38 UTC
0 reputation · 01 Sept 2026, 13:38 UTC
Cucumber JVM's default formatters (pretty, json, html, JUnit) serialize step arguments, data-table cells, and scenario-outline examples verbatim into report output, including any embedded credentials, tokens, or secrets. The core runtime provides no automatic detection or masking of sensitive values, and no first-party configuration flag exists as of Cucumber 8.x to redact them across all formatter targets.
Custom ParameterType transformers may mask step-level text output, but their effect does not consistently propagate to JSON report payloads or HTML report bodies, leaving persistent secrets in build artifacts. Third-party formatters and reporting plugins offer varying levels of support, and behavior depends on formatter implementation rather than a unified Cucumber policy.
Is there a formatter-agnostic configuration or annotation in Cucumber JVM that can reliably obscure sensitive values across all report formats? If not, what is the minimal, maintainable pattern to prevent credential exposure in JSON and HTML reports without custom formatter development? How do Cucumber reporting roadmaps address the absence of built-in secret redaction?
34775 reputation · 01 Sept 2026, 20:16 UTC
There is no formatter-agnostic configuration or annotation in Cucumber JVM that redacts sensitive values across all reports. The core formatters (pretty, JSON, HTML, JUnit) are designed to serialize step arguments, data tables, and scenario outline examples exactly as they appear in the Gherkin source. Because this serialization happens at the parser/event level, masking values within a ParameterType or a step definition does not retroactively update the report payloads.
When Cucumber executes a scenario, it emits events containing the raw arguments. If you have a step like Given I login with password "secret123", the formatter captures the string "secret123" immediately. Even if your Java code wraps this string in a custom object with a masked toString() method, the report-generated JSON or HTML file will still contain the original literal.
The most effective way to prevent credential exposure without writing custom formatters is to use indirection. Instead of placing secrets in .feature files, use symbolic keys or aliases that are resolved at runtime.
Given I authenticate with token "API_KEY_ENV".@Given("I authenticate with token {string}")
public void authenticate(String tokenAlias) {
// The secret is fetched at runtime, never stored in the report
String actualSecret = System.getenv(tokenAlias);
authService.login(actualSecret);
}
The same logic applies to Data Tables and Scenario Outlines. Avoid hardcoding credentials in Examples rows. Use a lookup key and resolve the value within the step logic to ensure the build artifacts only contain the key name.
To verify your protection is working, run a test with a dummy secret and grep the output artifacts:
grep -r "your-dummy-secret" target/cucumber-report/
If the command returns results, the secret is still leaking into your report files.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.