I'm trying to look for some way for mitigation of insecure deserialization vulnerability for the application front-end

Then I found this link


I saw this in the link:

A8-Insecure Deserialization This type of attack occurs if an application is using custom serialization and deserialization. This attack requires knowledge of that application and type of serialization used.

Usually, it's an issue if sensitive data is serialized and stored using custom serialization functions. An attack vector can be sent as a serialized parameter. There is a possibility of malicious code execution while the parameter is deserialized.

This is not an issue if common serialization techniques like JSON and XML are used. Enforcing strict type constraints can mitigate the risk. Other than that, the application should not accept serialized data from external sources.

I just want to confirm my understanding to the bolded part. Is it correct? That one of way to mitigate this vulnerability is to serialize into json object or xml object then parse it to expected object after deserializing the object?

  • Serializing with these formats would only prevent vulnerabilities incurred due to serialization from the networking layers to the application layer. Any attack vectors in the JSON/XML that is delivered to your application code can still be dangerous if they are not properly treated (an obvious example would be eval(response["data"]["userInputtedText"])).
    – zr0gravity7
    Jul 22, 2021 at 16:10

1 Answer 1


It may be a bit tricky to get a clear answer on that. Let's try it anyway and to do so let's go back to the roots. What is serialization about?

Serialization is about translating the inner state of an object into a byte stream. Deserialization is about translating the byte stream back into an object. We usually do the serialization/deserialization stuff for the purpose of storing data on some drive or data transmission over the wire.

So is passing JSON or XML objects over the wire related to serialization/deserialization of data? Yes. Is it relevant from the perspective of insecure deserialization vulnerabilities? No. Why is that? It's kind of a historical thing. The term of insecure deserialization vulnerabilities has been created to tackle an issue that was not known before and mostly related to Java applications at that time (please have a look here, it shows a brilliant timeline). Parsing issues with JSONs and XMLs have their own categories of related risks (like A4:2017-XML External Entities) and the deserialization of Java objects (which could lead to remote code execution) was thought to cover a different ground at first. Make no mistake. It's not only Java related. You can have issues in PHP and other languages too, but it was meant to address something else although the name does not clearly imply this.

Having said that, it's not common understanding and you may still have some discussions if you face some security engineers, as this is only a definition matter.

You must log in to answer this question.