Protect serialisable classes by excluding sensitive data from serialised state where possible, or by encrypting and tightly controlling the serialisation process. Serialised objects can be stored, copied, or deserialised in unsafe contexts, exposing secrets or enabling tampering. Define an explicit serial form and review which fields must never leave memory.
How serialisable sensitive data becomes a security problem
A serialisable class becomes risky when its in-memory object graph is turned into data that can be written to disk, copied across processes, logged, cached, or sent over a wire. At that point, fields that were supposed to be transient can outlive the object’s normal protection boundary. The mitigation starts with deciding which values should never be part of the serial form at all.
For classes that hold credentials, tokens, keys, personal data, or other secrets, the safest design is to keep those values outside serialised state unless there is a clear business need. If the object must travel, serialise only the minimum non-sensitive state needed to reconstruct behaviour, and treat everything else as runtime-only material.
That design choice matters because serialised data is often handled by code paths that are easier to copy, inspect, or replay than live objects. If sensitive fields are included by default, they can be exposed through backups, message queues, debug artefacts, test fixtures, or deserialisation in untrusted contexts. The mitigation is to make the serial form explicit, narrow, and reviewable.
Design the serial form so secrets never become ambient data
The cleanest mitigation is exclusion: mark sensitive fields as non-serialised where the language supports it, or use custom serialisation so only approved fields are emitted. This is especially important when the class contains material that is valid only in memory, such as session state, authentication material, or temporary authorisation context. CWE Top 25 Guide is useful here because it maps common weakness patterns like cleartext storage, sensitive data leakage, and missing serialisation controls.
If some state must survive serialisation, separate durable business fields from sensitive runtime fields and define a stable serial form deliberately rather than relying on default field-by-field serialisation. That lets you review exactly what can leave memory, what must be reconstructed after deserialisation, and what should be regenerated instead of persisted.
When a class cannot be safely serialised without the secret itself, use encryption as a containment measure, not as a reason to serialise everything. Encryption helps only if keys are tightly controlled, the ciphertext is protected in transit and at rest, and the decrypted value is not left hanging around longer than necessary.
Control deserialisation, integrity checks, and post-load handling
Mitigation does not stop at writing the object out. Deserialisation is another trust boundary, so the receiving side should validate the source, enforce allowed types, and reject objects whose structure or provenance is unexpected. A malicious or malformed payload can tamper with state, trigger unsafe object behaviour, or rehydrate fields in ways the original code did not intend.
Where the class participates in security-sensitive workflows, validate that the deserialised object still satisfies the invariants the application depends on. If a field should be recomputed, repaired, or re-fetched after load, do that explicitly rather than trusting the serialized value. This is also the point at which you should clear or replace any temporary secrets that were needed only to reconstruct state.
In practice, the safest posture is to assume that every serialised object may be copied, inspected, or replayed outside the original trust zone. That means serialisation should be a deliberate capability, not a default behaviour inherited from the language.
Risk and Threat Considerations
Serialised objects create a wider exposure surface than live memory because they are easier to persist, move, archive, and reuse. If sensitive fields are embedded in the serial form, the data can leak through storage, transport, logging, or test artefacts, and a crafted payload can also introduce integrity risk during deserialisation.
Failure mechanism: Default or overly broad serialisation captures secrets that should have stayed transient, then later copies of the object are read in unsafe contexts or modified before deserialisation.
Impact: Secrets can be disclosed, credentials can be reused outside their intended scope, and object state can be tampered with in ways that affect application logic or access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Serialised sensitive data often leaks via logs and copied artefacts. |
| Recommendation — Limit logged object contents and protect serialisation artifacts from disclosure. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Deserialised objects must be validated before trusted use to prevent tampering. |
| Recommendation — Validate deserialised data before applying it to application state. | ||
| OWASP ASVS | V14 — Data Protection | Sensitive fields in serialised state require minimisation and protection. |
| V16 — Security Logging and Error Handling | Serialisation failures and debug output can expose sensitive fields. | |
| Recommendation — Exclude or protect sensitive fields before serialising application objects. Prevent serialisation errors from disclosing sensitive object contents. | ||
Practitioner Guidance
What to verify: Review the class for every field that is included by default in the serial form, then verify whether each one is genuinely safe to persist, copy, or rehydrate. If the field is sensitive in any environment, treat omission as the default and persistence as the exception.
Decision rule: If the value can be regenerated, re-fetched, or derived after load, do not serialise it. If it cannot be avoided, encrypt it, restrict who can serialise and deserialise the object, and document the reconstruction path so the design stays reviewable.
Practitioner takeaway: The main control is not stronger serialisation, it is smaller serial state, because every field you exclude removes one more opportunity for accidental disclosure or post-load abuse.