PHP __debugInfo(): Safely Debugging Objects That Contain Secrets

During development we constantly inspect object state. That can happen through dump(), dd(), var_dump(), a debugger, or temporary diagnostics.

With ordinary data this is easy to ignore. The situation changes when an object contains a password, key, token, or secret hash.

While developing the Product Registry module in AVN Center, I ran into exactly this case. ProductRegistrationCredentialAuthenticationRecord contains both registration credential data and a CredentialSecretHash.

The hash is required by the application, but I do not need to see its value while debugging. More importantly, I do not want it to appear accidentally in the normal diagnostic representation of the object.

This is not an artificial example with a fictional password. It is a real object used to work with product registration credentials.

It stores two objects: ProductRegistrationCredential and CredentialSecretHash. Both are needed by application logic, so simply removing the hash from the class is not an option.

But runtime requirements and debugging requirements are different. The application needs the hash itself. Diagnostics only need to know that it exists.

Both properties are private, and the class itself is readonly. That is useful, but it does not replace control over the diagnostic representation.

private controls normal property access. readonly prevents the initialized state from being changed again.

Neither rule answers a different question: which information about this object is safe to expose during debugging?

__debugInfo() lets a class explicitly define the representation used by standard PHP object inspection during debugging.

The important part is not merely returning an array. The class no longer depends on an accidental representation of its internal state.

I decide which values are useful for diagnosis and which values should remain hidden.

I could make __debugInfo() almost empty. That would reduce exposure, but it would also make diagnostics much less useful.

When investigating product authentication, it is useful to see:

• the credential identifier;
• the registration identifier;
• the environment;
• the authentication profile;
• the current status.

That context is enough to identify the record without exposing the secret itself.

I could simply omit secret_hash from the result. Keeping the key with [REDACTED] provides one extra piece of useful information: the field is intentionally hidden.

That is different from a value being missing, not loaded, or accidentally lost.

During debugging I can see that the object does contain a secret component, while its actual value is deliberately withheld.

I do not want a diagnostic representation built around "show everything except a few forbidden fields".

For an object containing sensitive data, the opposite approach is safer: explicitly list only what is allowed to be shown.

A new property then cannot suddenly appear in diagnostics just because someone adds it to the class months later.

This version provides very little control.

It returns complete internal objects and effectively pushes the responsibility further down: now their diagnostic representations must also be safe.

That is especially undesirable for CredentialSecretHash. If this class is responsible for safe inspection, the sensitive object should not be returned at all.

At first this can look contradictory: if the class exposes secretHash(), why hide the value in __debugInfo()?

Because these access paths exist for different purposes.

secretHash() exists for application code that genuinely needs the value object. __debugInfo() exists for a person inspecting object state during debugging.

Programmatic access does not automatically mean the same value should be visible in diagnostic output.

This boundary is important. __debugInfo() controls the diagnostic representation in PHP mechanisms that use this magic method.

It does not mean the secret is automatically protected everywhere else.

Separate care is still required for:

• array conversion;
• JSON;
• serialization;
• application logs;
• exception context;
• external API payloads;
• metrics and telemetry.

A safe __debugInfo() protects one specific boundary. It should not create a false sense that every other path is protected as well.

This distinction led me to a simple rule: a diagnostic representation should not be a copy of the object internal state.

Its job is to provide enough information to investigate a problem while exposing the minimum necessary data.

Secret exposure during debugging rarely looks like one dramatic mistake.

A developer is simply trying to understand an authentication problem, runs dump($record), copies the result into a message, adds it to a task description, or temporarily writes it into a log.

The less manual discipline required for safe diagnostics, the better.

If the class already knows that the secret should not be displayed, that rule is applied consistently whenever the relevant inspection mechanism is used.

I am not trying to hide everything. Instead I ask a simple question for every field: will this help diagnose the problem?

Identifiers help locate the record. The environment shows where it is used. The authentication profile and status explain its current mode.

The actual secret hash adds almost nothing to that diagnosis, so exposing it has no practical value.

• First decide which data is actually useful for diagnostics.
• Do not expose internal object state automatically.
• Do not include secret values in the result.
• If the presence of a secret matters, use an explicit marker such as [REDACTED].
• Do not rely only on private or readonly.
• Review JSON, serialization, logs, and other output paths separately.
• A new sensitive property should not automatically appear in diagnostics.

I would not add __debugInfo() to every DTO or entity.

It is most useful when the internal state and the safe diagnostic representation are meaningfully different.

Examples include objects containing passwords, tokens, secret keys, signatures, hashes, private connection settings, or other values that should not be copied accidentally into diagnostic output.

If an object contains only ordinary non-sensitive data, a dedicated method may provide little value.

For ProductRegistrationCredentialAuthenticationRecord, I did not need to change the data model or remove CredentialSecretHash.

I only needed to separate two concerns clearly: what the object must contain at runtime and what a person should see during debugging.

__debugInfo() provides a very small control point for that. I keep identifiers, environment, authentication profile, and status while replacing the sensitive value with [REDACTED].

It is a small method, but it removes one unnecessary risk from everyday development.

To me, __debugInfo() is not a way to make a secret safe. It is a way to make debugging safer.