A text representation of an in-memory object that can be stored or transferred and later rebuilt by the application. It becomes risky when the data comes from an untrusted source, because attackers may modify the structure or field values to influence application logic during deserialisation.
What Serialized Object Data Is
Serialized object data is a structured representation of an application object that can be written to storage or sent across a network, then reconstructed later. It preserves state, but it also preserves trust assumptions about what the application expects to receive.
In practice, serialization sits between live program memory and a portable data format. That makes it useful for caching, persistence, queues, remote calls, and session handling, but it also means the receiving component must treat the input as potentially hostile unless integrity is guaranteed.
How Serialization Changes the Security Boundary
The key security shift is that serialized data is often treated as “application-shaped” input rather than as ordinary text or bytes. Once deserialisation begins, the parser may instantiate objects, populate fields, or trigger helper methods in ways that affect control flow, permissions, or business logic.
That is why the same data handling path can be harmless in one context and dangerous in another. If the format is trusted, serialization is just a transport mechanism. If the source is untrusted, it becomes an attack surface where field values, object graphs, or type metadata can be manipulated to change what the application believes it has received.
Where Serialized Object Data Becomes Dangerous
The main risk comes from deserialising data that was not created and protected by the application itself. Attackers may tamper with object structure, replace expected types, or alter values that the program later uses for decisions, such as authorization state, user roles, feature flags, or counters.
Some formats are especially risky when they allow rich object reconstruction or automatic type resolution. The more logic the deserialiser performs on behalf of the application, the more likely it is that malformed or malicious input can influence runtime behaviour before the application has a chance to validate it.
Common Uses and Safe Design Expectations
Serialized object data is common in session stores, message brokers, caching layers, remote procedure calls, and inter-service communication. Those uses are legitimate, but they require clear ownership of what types can be written, who can read them, and whether integrity and authenticity are enforced before deserialisation.
For safer designs, teams often prefer simple, schema-driven formats for untrusted boundaries, keep object graphs narrow, and avoid automatic reconstruction of arbitrary classes. Where object serialization is unavoidable, the implementation should assume that any externally supplied payload can be altered and should validate the result before it is acted on.
Risk and Threat Considerations
Serialized object data is risky because deserialisation can become a direct path from untrusted input to application logic. If an attacker can influence the payload, they may trigger unsafe object creation, change state that the program trusts, or abuse gadgets in the runtime and libraries.
Failure mechanism: The application accepts a serialized payload and reconstructs objects before validating the source or the content, allowing attacker-controlled data to affect parsing, instantiation, or downstream logic.
Impact: The result can range from logic manipulation and privilege abuse to remote code execution, depending on the format, libraries, and exposed object paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Covers validating external input before it drives application behavior, including deserialized payloads. |
| SA-11 — Developer Testing and Evaluation | Supports verifying that deserialization paths resist malformed or malicious inputs. | |
| Recommendation — Validate serialized payloads before reconstruction and reject unexpected structures or values. Test deserialization code paths with hostile inputs and confirm unsafe object handling is blocked. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Addresses unsafe object handling and insecure design choices that make deserialization exploitable. |
| Recommendation — Design serialization boundaries to avoid arbitrary object reconstruction from untrusted data. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Covers abuse of trusted material to obtain execution or access when payloads or tokens are manipulated. |
| Recommendation — Hunt for abused trusted material where deserialized data changes access or execution paths. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Serialized objects often persist sensitive state that should be protected when stored. |
| Recommendation — Protect stored serialized objects and restrict who can read or modify them. | ||
Practitioner Guidance
What to watch for: Treat any deserialisation boundary that crosses trust domains as a high-risk control point. Review whether the format allows arbitrary type materialisation, whether integrity is verified before parsing, and whether the receiving code truly needs full object reconstruction.
Practitioner takeaway: The safest assumption is that serialized data is just input until proven otherwise, so the control objective is to reduce what can be reconstructed, not merely to parse it successfully.
