Developers prevent serialisable classes from containing sensitive data by excluding secrets from serialised fields and marking sensitive members as non-serialisable where the language supports it. They should review every object that crosses process, network, or storage boundaries and replace secrets with references or short-lived tokens. Serialised sensitive data is easy to persist, replicate, and leak through logs or backups.
What makes serialised classes risky when they can carry secrets?
Serialization turns an in-memory object into data that can be copied, logged, cached, shipped over a network, or written to disk. If that object includes passwords, tokens, keys, session material, or personal data, the sensitive value stops being a transient runtime detail and becomes portable content. That changes the exposure profile from local object scope to wider storage, transport, and recovery surfaces.
Classes are especially risky when developers assume that serialization is only a technical convenience. In practice, it creates additional places where the object may be inspected, replayed, or retained longer than intended. A class that is safe in memory can become unsafe once it crosses a process boundary or lands in a backup set.
That is why developers should treat every serialisable object as part of the data protection boundary, not just the application boundary. The design question is not only whether the class works, but whether every field is appropriate to persist, replicate, and recover.
Which fields should never be serialised?
Any field whose disclosure would matter outside the current runtime should be excluded unless there is a strong, explicit business need. That includes credentials, API keys, refresh tokens, private keys, bearer tokens, session identifiers, and similar authentication material. It also includes secrets embedded in nested objects, superclass fields, and debug-only members that are easy to overlook during code review.
Where the language or framework supports it, developers should mark sensitive members as non-serialisable and make the serialised form contain only the minimum state needed to reconstruct the object safely. In many cases, the right pattern is to serialise a reference, identifier, or short-lived surrogate instead of the secret itself. The object can then be rehydrated from a protected store or re-fetched under controlled access.
CWE Top 25 Guide is useful here because serialization defects and sensitive-information exposure are recurring weakness patterns, not isolated mistakes. For secure coding teams, the practical rule is to review serialised fields as aggressively as input validation or authorization boundaries.
How do teams avoid leakage when objects move across boundaries?
The safest pattern is to minimise what leaves the object boundary and to separate identity-bearing data from business state. If a class must cross a process, network, or storage boundary, the payload should be deliberately shaped for that destination rather than copied wholesale from the live object. That reduces the chance that transient secrets, internal metadata, or diagnostic fields are accidentally preserved.
Developers should also assume that any serialised secret can be duplicated in logs, message queues, crash dumps, backups, and test fixtures. For that reason, sensitive values should be replaced with tokens, references, or derived values that are useless outside the intended context. If the application must carry a secret temporarily, keep its lifetime short and its scope tightly bounded.
Tokenisation and Data Masking Guide provides the cleanest model for this design choice: preserve utility while removing the original secret from the serialised form. When the value must remain recoverable, protected rehydration is preferable to embedding the raw secret in the object graph.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V14 — Data Protection | Serialization of secrets directly affects data protection in storage and transit. |
| Recommendation — Exclude secrets from serialised objects and validate that sensitive data is never emitted. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Serialised secrets are authenticator material that needs controlled lifecycle handling. |
| Recommendation — Remove authenticators from serialised state and rotate any exposed credentials. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Preventing secret leakage through serialisation is a data protection safeguard. |
| Recommendation — Classify sensitive fields and block their persistence in serialised payloads. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Serialised secrets create direct leakage of identity material across boundaries. |
| NHI-07 — Long-Lived Secrets | Serializable secrets persist longer and wider than intended. | |
| Recommendation — Keep secrets out of serialised fields and replace them with non-sensitive references. Shorten secret lifetime and avoid serialising durable credentials or tokens. | ||
Practitioner Guidance
What to verify: Check the actual serialised payload, not just the source class. Teams often believe a field is excluded because the primary property is marked correctly, while a nested object, custom serializer, or framework default still emits the sensitive value.
Common mistake: Relying on redaction in logs while leaving the underlying object serialisable. Redaction helps with one exposure path, but it does not stop persistence in caches, queues, backups, or downstream consumers.
What good looks like: The serialised representation contains only non-sensitive state, and any secret needed at runtime is retrieved through a separate controlled mechanism. If the object must travel, it should carry references or short-lived tokens, not durable secret material.
Practitioner takeaway: Treat serialization as a data-exposure decision, not a convenience feature. If a field would be harmful in a backup, log, or replayable message, it should not be present in the serialised class in the first place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org