Insecure Deserialization is a vulnerability that occurs when an application deserializes (reconstructs into objects) data from untrusted sources without proper validation, allowing an attacker to manipulate that serialized data to achieve malicious outcomes – potentially including remote code execution. To understand it, one needs the pair of concepts: serialization is the process of converting an object or data structure into a format (such as a byte stream, JSON, or XML) that can be stored or transmitted, and deserialization is the reverse – reconstructing the object from that format. Applications serialize and deserialize data routinely to pass objects between systems, store session state, or exchange data over APIs.
The vulnerability arises when an application accepts serialized data from an untrusted source (such as user input, cookies, or API requests) and deserializes it without verifying its integrity or safety. Because deserialization can instantiate objects and, in some languages and frameworks, trigger code execution during the reconstruction process, an attacker who can tamper with the serialized data may be able to inject malicious objects or manipulate the application’s logic. In the most serious cases, this leads to remote code execution, allowing the attacker to run arbitrary code on the server. Other consequences include privilege escalation, authentication bypass, data tampering, injection-style attacks, and denial of service.
Insecure deserialization was significant enough to appear in the OWASP Top 10. It is considered dangerous both because the impact can be so severe (up to full system compromise) and because it can be difficult to detect and exploit correctly – but devastating when successfully exploited. The attack surface is easy to overlook, since deserialization often happens behind the scenes as a normal part of application operation.
APIs are relevant here because they frequently exchange serialized data (such as JSON or other formats) and may deserialize incoming request bodies, tokens, or objects. If that data is trusted implicitly, the API becomes vulnerable.
Preventing insecure deserialization involves several practices: avoiding deserialization of untrusted data altogether where possible; if it must be done, enforcing strict integrity checks (such as digital signatures) to ensure serialized data has not been tampered with; using safe, restricted deserialization that only permits expected types; validating and sanitizing incoming data; isolating and running deserialization in low-privilege environments; and preferring simple data formats and safe parsing over language-native serialization that can instantiate arbitrary objects. The overarching principle is to never trust serialized data from external sources and to treat deserialization of untrusted input as a high-risk operation requiring strong safeguards.