Serialization

How serialization works

Serialization turns an in-memory structure into a portable representation, usually text or binary, so software can write it to disk, send it over a network, or hand it to another process. The reverse operation, deserialization, rebuilds the original object or data structure from that representation.

The key design choice is not just format, but fidelity: some serializers preserve rich object graphs, type information, and references, while others deliberately flatten data into simpler records. That trade-off affects interoperability, performance, and how much trust the receiving system must place in the incoming payload.

Common examples include JSON for web APIs, XML in older enterprise integrations, protocol buffers for compact service-to-service communication, and native language serializers used for session state or application caches. Each format solves the same basic problem, but with different assumptions about schema, compatibility, and parsing safety.

When teams treat serialization as a purely mechanical step, they often miss that the format itself becomes part of the application boundary. What looks like ordinary data can carry structure, metadata, or type cues that influence behaviour on the receiving side.

Serialization in software systems

Serialization shows up anywhere systems need to persist or exchange structured state. Files, message queues, RPC calls, APIs, logs, checkpoints, and cache entries all depend on a representation that survives process boundaries and can be reconstructed later.

That makes serialization a compatibility layer as much as a data format. Producers and consumers need to agree on field names, data types, versioning rules, null handling, and whether unknown fields are ignored or rejected. Small changes can break a downstream parser or silently alter business logic.

In distributed systems, serialization also affects latency and bandwidth. Compact binary formats can reduce overhead, while human-readable formats make inspection and debugging easier. Security teams care about both because a format that is easy to inspect is not automatically safe to consume.

For APIs, serialization often defines the shape of trust. The receiving service must decide whether to accept the message as plain data, validate it strictly, or treat parts of it as potentially dangerous instructions. That decision has direct consequences for attack surface and control design.

Why serialization becomes a security boundary

Serialization becomes dangerous when a receiver reconstructs objects unsafely from untrusted input. The risk is not the act of converting data itself, but the possibility that parsing or object creation triggers unexpected behaviour, logic abuse, or code paths the developer never intended.

Problems are especially severe when the deserializer accepts rich object types, performs automatic class instantiation, or honors embedded references and polymorphic type hints. In those cases, the input can influence program flow, not just data values.

Security review should therefore focus on what the application allows the input to become. A simple record is usually far safer than a full object graph, and strict schema validation is safer than permissive reconstruction of arbitrary classes or methods.

Modern secure coding guidance often treats deserialization as a high-risk trust boundary. For a broader control view, NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Benchmarks both reinforce disciplined control of input handling, configuration, and application integrity.

Safe usage patterns and common failure modes

The safest serialization patterns are narrow, predictable, and explicit. Use well-defined schemas, reject unexpected fields, avoid automatic type resolution, and prefer data-only formats for untrusted boundaries whenever possible. If a system must accept richer structures, it should do so with strict allowlists and hardened parsing rules.

Common failure modes include version drift, malformed payloads, parser differentials, and insecure defaults that deserialize too much on behalf of the application. Another frequent mistake is assuming that “internal” traffic is trustworthy, even when messages can be replayed, relayed, or tampered with upstream.

Organizations also need to think about where serialized objects are stored. Cached session state, queued jobs, and archived blobs can become long-lived attack surfaces if they are later reloaded by a more privileged component or a different version of the application.

From an operational standpoint, the safest rule is to treat every serialized payload as untrusted until validated. That applies equally to files uploaded by users, messages from partner systems, and data moved between internal services.

Serialization, deserialization, and security controls

Serialization and deserialization should be governed as part of application design, not patched in after an incident. The most effective controls reduce the amount of implicit behaviour in parsing, keep data formats stable, and make unsafe object reconstruction hard to reach.

Where applications expose APIs, the relevant security questions are often about input validation, object mapping, and whether the receiver can be tricked into instantiating unexpected structures. For API-facing systems, the OWASP API Security Top 10 is a useful companion for thinking about how malformed or hostile payloads cross service boundaries.

In software delivery, secure design also depends on the integrity of the components that perform serialization and the build chain that ships them. For that reason, OWASP SAMM and SLSA are relevant when organizations want to reduce the chance that unsafe libraries, build outputs, or dependencies become part of the serialization path.

Related resources from NHI Mgmt Group

• How can security teams tell whether serialization risk is actually controlled?
• Why does prompt injection become more serious when serialization is involved?
• What breaks when attacker-shaped LLM output reaches serialization paths in AI frameworks?
• How should organisations respond when a core AI framework serialization flaw is disclosed?