In this series of articles, we walk you through the OWASP Top 10 — the most common and most damaging types of cyber attack. These topics have a reputation for being hard to follow, and when you go looking for answers online, you often land on explanations that only make sense if you’re already an expert. That’s not a criticism; there’s simply a shortage of clearly written material on these threats. At Rootsec, we set out to change that, with plain-language explanations and no avalanche of jargon. In this article, we tackle a topic that sounds intimidating but is easier to grasp than you might think: what is insecure deserialization?

What is insecure deserialization?

In short, insecure deserialization is an attack technique that lets an attacker smuggle a harmful payload into an application using serialized objects. To understand what that means, we need two quick definitions.

When you build a web application, you constantly need to move data around — between systems, across a network, or in and out of storage. That data usually lives in objects: bundles of variables that hold information. The trouble is that an object can’t travel as-is, so the application converts it into a simple, flat stream of text. That conversion process is called serialization. When the data arrives at the other end, the reverse process turns that flat text back into a usable object. That’s deserialization.

So far, so harmless. The vulnerability creeps in because developers tend to trust serialized objects in a way they would never trust ordinary user input. They forget to apply the usual checks and validation. An attacker who spots this can tamper with the serialized data — slipping in malware, ransomware, or a worm — and the application will happily rebuild it into a live object and act on it. In other words, a door that should have been locked is left wide open, and that often leads straight to the deeper weaknesses underneath.

Where this fits in the OWASP Top 10: insecure deserialization was its own category — A8: Insecure Deserialization — in the OWASP Top 10 of 2017. In the current OWASP Top 10 (2021), it no longer stands alone. It now sits within the broader category A08: Software and Data Integrity Failures, which covers failures to verify the integrity of code and data — including deserializing data from sources you can’t trust.

What are the consequences of insecure deserialization?

There are no precise figures for how often this attack occurs. OWASP placed it on the list largely on the strength of industry survey data rather than hard counts, simply because it can be difficult to detect after the fact.

The impact, however, can be severe. The worst-case scenario is remote code execution — where an attacker is able to run their own code or commands on your server from a distance. From there, very little is off-limits: data theft, service disruption, or a foothold for a deeper breach.

A well-known case widely linked to this class of flaw is the 2017 Equifax breach, in which the personal data of many millions of people was exposed. It’s a stark reminder that a single overlooked integrity check can have consequences on an enormous scale.

How to prevent insecure deserialization

The golden rule is simple: never trust serialized data from a source you don’t control. From there, a layered set of measures keeps you well protected:

  • Reject untrusted serialized objects. Build in an architectural pattern that refuses to deserialize data coming from untrusted sources in the first place.
  • Limit what can be serialized. Where possible, use a serialization format that only allows primitive data types, so there’s far less an attacker can abuse.
  • Sign your serialized objects. Apply digital signatures so the application can verify that data hasn’t been tampered with before it acts on it.
  • Isolate the process. Run deserialization in a low-privilege, sandboxed environment, so even a successful attack has very little room to do damage.
  • Log everything. Record deserialization exceptions and failures — they’re often the first sign that someone is probing for a way in.
  • Restrict and monitor network access. Limit and watch the network connectivity of any container or service that performs deserialization.
  • Keep watching. Monitor deserialization activity continuously and raise an alert the moment you see suspicious patterns.

At Rootsec, it has always been our goal to make information security simple — and this series is part of that mission. Insecure deserialization is one of those flaws that hides quietly inside an application until someone goes looking. The good news is that, with the right checks in place, it’s very preventable.

Not sure whether your applications handle serialized data safely? A Rootsec penetration test uncovers integrity flaws like insecure deserialization before an attacker does. Book a free consultation.