Java 27 JFR Auto-Redaction: Automatic Secret Masking in Diagnostic Files

While troubleshooting a Spring Boot CPU spike, the author captured a JFR recording and realized that diagnostic files can inadvertently leak credentials. JFR records not only performance data but also JVM startup parameters, system properties, and environment variables — which often contain database passwords, API keys, and tokens.

How Secrets Enter JFR

Typical Spring Boot deployments pass secrets via environment variables or -D system properties:

export SPRING_DATASOURCE_PASSWORD=order@2026
export OPENAI_API_KEY=sk-xxxxxxxx
java -Dpayment.token=abc123 -jar app.jar

These values appear in JFR events jdk.InitialEnvironmentVariable, jdk.InitialSystemProperty, and jdk.JVMInformation. Because JFR files are routinely shared among ops, developers, and architects, they become a security risk.

Java 27's Solution: JEP 536 – JFR In-Process Data Redaction

Java 27 (released 2026-09-15) adds automatic redaction inside the JVM before data is written to the recording. The feature is enabled by default and covers three event types:

jdk.InitialEnvironmentVariable

jdk.InitialSystemProperty

jdk.JVMInformation

(including command-line arguments via redact-argument)

Default Redaction Patterns

The JVM ships with a built-in list of case-insensitive glob patterns:

*api*key*
*auth*
*client*secret*
*credential*
*passphrase*
*passwd*
*password*
*private*key*
*pwd*
*secret*
*token*

Any key matching these patterns has its value replaced with [REDACTED]. For example, SPRING_DATASOURCE_PASSWORD and OPENAI_API_KEY are automatically masked.

Custom Rules via FlightRecorderOptions

Organizations can add their own naming conventions without losing the defaults by prefixing with +:

-XX:FlightRecorderOptions='redact-key=+*sign*;*internal*access*'

Critical detail: omitting the + replaces the entire default rule set, which would disable built-in protections for *password*, *token*, etc. Rules can also be loaded from a file using @filename.

Command-Line Argument Redaction

redact-argument

applies glob patterns to JVM arguments recorded in jdk.JVMInformation:

-XX:FlightRecorderOptions='redact-argument=+--merchant-secret=*'
--merchant-secret=abcdefg

Verification Test

The author ran a Spring Boot app with deliberate secrets, started a 60-second JFR recording, and inspected events with jfr print:

jfr print --events jdk.InitialEnvironmentVariable order.jfr
jfr print --events jdk.InitialSystemProperty order.jfr
jfr print --events jdk.JVMInformation order.jfr

All default-pattern keys showed [REDACTED].

Limitations and Boundaries

The redaction is best-effort and has explicit gaps:

Custom JFR events (user-defined @Name events) are not scanned — fields like apiKey or token inside custom events are recorded verbatim. jdk.ProcessStart (child process info) is not covered by redact-argument. jdk.InitialSecurityProperty is not in the redact-key scope.

The author stresses: never put secrets into custom JFR events ; log only non-sensitive identifiers (order ID, provider, success flag).

Operational Recommendations

Treat .jfr files as sensitive diagnostic artifacts — do not share via chat, public drives, Git, or third-party analyzers.

After upgrading to Java 27, verify redaction in a test environment:

export TEST_PASSWORD=should-not-see-this
export TEST_API_KEY=should-not-see-this
java -XX:StartFlightRecording=filename=test.jfr,duration=30s -jar app.jar
jfr print --events jdk.InitialEnvironmentVariable test.jfr

Check active default patterns with java -XX:FlightRecorderOptions:help.

Broader Context

Diagnostic data (thread dumps, heap dumps, JFR, GC logs, APM traces) increasingly mirrors runtime internal state. Java 27's change doesn't reduce observability; it adds a default safety layer for the most common secret patterns across dozens or hundreds of services without requiring code changes. However, it complements — not replaces — comprehensive secret management (logs, heap dumps, Kubernetes secrets, custom instrumentation).