Karate DSL report serialization exposes karate-config.js secrets despite showConfig flag

Direct answer

The showConfig: false flag is not documented and does not reliably redact nested objects or Java-interop values in Karate 1.4.x. Treat it as a display toggle, not a security control. The reliable, version-stable approach is to keep secrets out of karate-config.js entirely and use runtime injection plus name-based masking.

Why the flag fails

Karate merges karate-config.js (and any environment variants) into a single configuration object at startup. The report serializer walks that object when writing HTML and JUnit XML. An undocumented boolean that only hides the top-level config key cannot reach values nested inside objects, arrays, or values injected later via Java.type(...) calls from secret managers. Parallel execution compounds the problem: each forked JVM reloads the config, giving every worker a fresh chance to serialize a secret into its report fragment.

Confirmed mitigations (version-stable)

1. Never put secrets in karate-config.js. Read them at call time from environment variables or system properties:

   // In a feature or helper
   * def dbUrl = java.lang.System.getenv('DB_URL')
   * def apiKey = java.lang.System.getProperty('api.key')

   Because the value never enters the merged config object, it cannot be serialized into any report.
2. Use Karate's built-in name-based masking. Variable names containing password, secret, token, key, or credential (case-insensitive) are automatically replaced with **** in logs and reports. Store sensitive values under such names:

   * def dbPassword = java.lang.System.getenv('DB_PASSWORD')
   # Report will show dbPassword: ****

3. If you must scrub after the fact, use a RuntimeHook. Karate 1.x exposes Runner.Builder.hook(new MyRuntimeHook()) where MyRuntimeHook implements RuntimeHook (or the newer ReportHook interface). In beforeReport(Report report) you can walk the report model and replace or remove sensitive keys before HTML/JUnit serialization. Pin your Karate version in CI when relying on this internal API.

Verification steps for your pipeline

1. Add a canary secret to karate-config.js (e.g. canary: 'LEAK-THIS-STRING').
2. Run a minimal suite with karate.configure('report', { showConfig: false }).
3. Grep the generated target/karate-reports/*.html and *.xml for LEAK-THIS-STRING. Expect to find it.
4. Repeat with the secret injected only via System.getenv() at call time and confirm zero occurrences.
5. Enable name-based masking (store as mySecret or apiToken) and verify the report shows ****.
6. If using a custom hook, add a CI gate that fails the build when any archived report artifact matches a denylist of secret patterns.

One diagnostic detail that changes the recommendation

Are you using the standalone JAR, the Maven/Gradle plugin, or a custom Runner bootstrap? The hook registration API differs slightly between karate-junit5, karate-testng, and the CLI runner. Knowing which entry point you use lets me give the exact hook registration snippet.