Serialized data is a structured string representation of an object, array, or scalar value that can be stored and later reconstructed. In PHP, serialization is common for database storage, but it becomes dangerous when application code accepts attacker-controlled serialized input and later deserializes it without strict validation.
What Serialized Data Represents
Serialized data is a transportable text form of a value or object graph. It preserves structure so software can store, send, or cache data and later reconstruct the original object, array, or scalar.
The format itself is neutral. The security question starts when serialized input crosses a trust boundary, because the receiving application may reconstruct objects, invoke magic methods, or restore state that the sender should never control.
In practice, serialization is common in caching, session handling, job queues, and database fields. That convenience is also why unsafe deserialization often becomes a hidden attack surface rather than an obvious feature.
How Serialization Becomes a Security Boundary
Serialization is not the same as encryption or integrity protection. A serialized string may be easy for an attacker to read, copy, modify, or replay if the application treats it as trusted content.
The main security boundary is the deserialization step. If code accepts attacker-controlled serialized data, then the object construction process can become a control-flow issue, not just a data-format issue. That is why the same format can be harmless in one place and dangerous in another.
PHP is a well-known example because object deserialization can trigger application-specific behaviour through classes, properties, and methods already present in the codebase. Similar design risks exist in any ecosystem where data can restore executable object state.
For that reason, serialized data should be treated as untrusted input unless it is protected by a strong integrity mechanism and the application only deserializes well-defined, expected structures.
Common Failure Modes and Abuse Paths
The most serious failure mode is unsafe deserialization of untrusted content, which can lead to object injection, logic abuse, denial of service, or remote code execution depending on the language runtime and available gadgets.
Attackers often look for payloads that exploit class autoloading, gadget chains, weak type assumptions, or permissive deserialization options. Even when code execution is not reachable, attackers may still alter application state, bypass authorization checks, or poison business logic.
Data stored for convenience can also become a persistence risk. If serialized blobs are copied between queues, caches, files, or databases without validation, a tampered value may survive longer than a session token or request parameter would.
Integrity matters because the parser is doing more than parsing. It is rehydrating application state, and that state may include behaviour the attacker can influence if the input is not tightly constrained.
Where Serialized Data Fits in Secure Design
The safest pattern is to keep serialized data narrow, versioned, and expected. Use it only for data structures that you control, and prefer safer interchange formats when you do not need full object reconstruction.
When serialized values must be accepted, the application should assume the content can be malformed, stale, oversized, or adversarial. That means the schema, allowed classes, and trust source need to be explicit rather than implicit.
Security reviews should pay special attention to any code path that deserializes data received from users, partner systems, queues, cookies, caches, or upstream services. These are the places where trusted internal state can quietly become external input.
Strong platform guidance helps here. Controls for validation, least privilege, and secure coding are directly relevant, and the attack patterns are well documented in NIST SP 800-53 Rev 5 Security and Privacy Controls, OWASP API Security Top 10, and MITRE ATT&CK Enterprise Matrix.
Risk and Threat Considerations
Serialized data becomes risky when applications assume the bytes are merely content, but the deserializer can revive executable state. That turns a data-handling feature into a trust-boundary problem, especially when the input is attacker-controlled or indirectly influenced.
Failure mechanism: The attacker supplies a crafted serialized payload that exploits object injection, gadget chains, or unsafe class restoration, causing the application to execute unintended logic or consume resources abnormally.
Impact: Consequences range from logic corruption and privilege abuse to denial of service and, in the worst cases, remote code execution or durable compromise of application state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | V15 — Secure Coding and Architecture | Unsafe deserialization is a secure-design issue in application code. |
| V2 — Validation and Business Logic | Serialized input requires strict validation before reconstruction. | |
| V16 — Security Logging and Error Handling | Deserialization failures and suspicious payloads need detectable handling. | |
| Recommendation — Eliminate unsafe object restoration paths and constrain deserialization to trusted, expected data structures. Validate serialized inputs before processing them and reject unexpected structures or types. Log deserialization errors and anomalous payload handling for investigation and response. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Serialized blobs are untrusted input that must be validated before use. |
| AC-6 — Least Privilege | Limiting runtime privileges reduces the blast radius of deserialization abuse. | |
| Recommendation — Validate serialized content before deserializing it and reject malformed or unexpected payloads. Restrict application privileges so a deserialization flaw cannot easily escalate system impact. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Deserialization flaws are application security weaknesses that require secure design and review. |
| Recommendation — Review code paths that deserialize external input and remove unsafe object restoration behavior. | ||
Practitioner Guidance
What to watch for: Any code path that deserializes data from users, third parties, caches, queues, or long-lived storage deserves special scrutiny. If the application restores objects rather than plain data, confirm that only expected types can be reconstructed.
Governance implication: Treat serialization formats as part of the application attack surface, not just an implementation detail. Ownership should sit with the team that controls both the producer and the consumer, because the risk appears at the boundary between them.
Practitioner takeaway: If the system does not truly need object rehydration, do not let deserialization become a hidden execution path.
Related resources from NHI Mgmt Group
- What breaks when a framework trusts serialized request data too much?
- Why does a CMS that accepts user-controlled serialized data create a higher code execution risk?
- Why is it important to integrate identity and data governance?
- How should security teams unify identity across cloud and data center environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
