Data format deserialization risks JSON. The text itself is harmless. The real danger kicks in during deserialization, when your framework tries to build an object from that data. Suddenly, the parser’s behavior, library extras, and your application’s own logic become the target.
A deeply nested array or a crafted property can take a system down. The threat lives in that conversion step from typeless data to typed object. To secure your API endpoints, you have to grasp these mechanics. Our Secure Coding Practices guide breaks it down. Keep reading.
JSON Safety Snapshot
Here are the main risks and defenses for JSON deserialization.
- JSON is usually safe. But parsers can be dangerous. They can create new classes dynamically. This can lead to remote code execution.
- Deep nesting and large payloads are also risks. Parser errors, like duplicate keys, can cause denial-of-service. They might also create logic bugs.
- The best defense is layered. First, configure your parser securely. Then, validate all deserialized data with a strict schema.
Why Can’t You Just Trust the Parser?
The common belief goes like this. Traditional serialization, like Java’s ObjectOutputStream, bundles an object’s state and its class. Deserializing it reconstructs the object, calling constructors. That’s dangerous by design. Pure JSON is just text. No code. So it’s safe, right?
That’s where thinking gets fuzzy. The JSON text is inert. The vulnerability lives in the machinery that converts that text back into something your app can use. The parser is the first piece of that machinery.
Most JSON libraries are solid, but they have limits. They allocate memory. They use CPU. An attacker doesn’t need to execute code to break your service; they just need to push those limits.
In our training, we’ve seen systems buckle under surprisingly simple loads.
- A “JSON bomb” with extreme nesting triggers recursion limits.
- Very large numeric values can cause overflow, precision loss, or slow parsing in some implementations.
- Duplicate keys can be interpreted differently by different systems, leading to logic bypasses.
The parser is just the door. The real trouble starts when your framework starts deciding what to build with the materials it’s given. That’s where insecure deserialization often begins.
What Is the Polymorphic Deserialization Trap?
This is the closest JSON gets to the classic “insecure deserialization” nightmare. Polymorphic deserialization is a major JSON security hole. It stems from a developer’s need for flexibility like an API handling different payment types. To manage this, parsers like Jackson let JSON declare its own type using a field like @type. The parser reads this and tries to instantiate that exact class.
If the parser can instantiate attacker-chosen types and those types participate in a gadget chain, the result can be remote code execution. Unsafe polymorphic deserialization has been the root cause of multiple Jackson-related security issues.
The chain looks like this:
- Subject: JSON Parser
- Predicate: instantiates
- Object: Arbitrary class from @type property
The vulnerability isn’t in JSON. It’s the framework enabling remote code execution. We learned to disable global default typing. If you need polymorphism, you define a strict, explicit allowlist of classes the parser is permitted to instantiate. No exceptions.
When Does JavaScript’s Prototype Get Poisoned?
Credits: SEC-T
The risk shifts shape in Node.js environments. Here, the threat isn’t instantiation of a random class, but pollution of the very foundation of objects. JavaScript uses prototype-based inheritance. Every object has a link to a prototype object. If you can modify Object.prototype, you change the behavior of almost every object in the application.
Some vulnerable libraries, when merging a deserialized JSON object into an existing one, don’t filter special keys. An attacker sends a payload like:
{
"__proto__": {"polluted": "true"},
"regularKey": "value"
}If the merge function isn’t safe, it might actually assign the property polluted to the base Object.prototype. Now, any new object created in the application will have a property polluted: "true". This can lead to bizarre behavior, authorization bypasses, and in certain cases, remote code execution if the polluted property alters a critical function.
The mitigation is straightforward but must be deliberate. Avoid unsafe deep-merge patterns; sanitize keys such as __proto__, constructor, and prototype before assignment.
Why Is Mass Assignment a Silent Threat?
Even if you’ve dodged polymorphic exploits and prototype pollution, a more mundane risk remains. It’s called mass assignment or over-posting. Your framework, say Spring Boot or ASP.NET, is designed for convenience. It will automatically bind incoming JSON properties to your backend model object.
Your User model has fields: username, email, and isAdmin. Your profile update endpoint expects username and email. An attacker sends:
{"username": "attacker", "email": "a@b.com", "isAdmin": true}If your controller binds directly to the User domain model without validation, the isAdmin field might get set. The framework was just being helpful. The fix is to never bind incoming data directly to persistent models.
As highlighted by 42Crunch
“An API endpoint is vulnerable if it automatically converts client parameters into internal object properties without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.” – 42Crunch
Use an intermediate Data Transfer Object (DTO) that contains only the fields the endpoint is supposed to accept. Then, manually map those safe fields to your domain object. It’s a few more lines of code, and it slams this door shut.
How Can You Build a Defensive Workflow?
A secure workflow needs layered filters.
First, configure your parser. Set hard limits on size, depth, and string length. We disable features that let JSON define its own types. Use a streaming parser for big payloads.
In a recent analysis by OWASP Cheat Sheet Series
“Use a safe replacement for the generic readObject() method… Note that this addresses ‘billion laughs’ type attacks by checking input length and number of objects deserialized.” – OWASP Cheat Sheet Series
Next, validate with a JSON Schema. Enforce data types, formats, and ranges. This removes bad data.
Then, map everything to a dedicated Data Transfer Object (DTO). Only fields defined here pass through.
Finally, apply safe object serialization and user permissions.
We teach this as standard practice in our Secure Coding Practices. It’s not extra security work; it’s just how we code. The goal is to make the safe path the easy, default one.
| Security Layer | Purpose | Example Action |
| Parser Configuration | Stop parser-level abuse | Limit depth, payload size, and disable type metadata |
| Schema & DTO Validation | Accept only expected data | Validate schema and bind to dedicated DTOs |
| Business Logic Checks | Enforce application rules | Verify permissions before processing requests |
FAQs
Can a JSON deserialization vulnerability cause remote code execution?
A JSON deserialization flaw can allow remote code execution. This happens when applications allow unsafe polymorphic deserialization. They might also allow unsafe class instantiation. Developers should use strict input validation. Allowlists are also good. Binding data to objects only is another safeguard.
How does JSON parsing DoS affect application availability?
JSON parsing can lead to denial-of-service attacks. These attacks exploit deep nesting. They can also exploit large arrays or memory exhaustion. Developers should limit parsing depth. They should also set size limits and request timeouts. This keeps the application running smoothly.
Why is deserialization of untrusted data still dangerous with JSON?
Deserializing untrusted data is always risky. Unsafe JSON binding can cause problems. Incorrect JSON-to-object mapping can allow JSON object injection. Applications should only accept expected fields. They should bind requests to predefined data transfer objects.
What is the safest way to handle JSON polymorphic type risks?
The safest approach to JSON polymorphic type risks is to disable unnecessary type metadata and use a JSON deserialization allowlist for accepted types. Developers should avoid dynamic object creation unless a trusted business requirement makes it necessary.
How should developers test JSON deserialization security?
Developers should perform JSON deserialization testing with malformed payloads, oversized requests, and fuzzing techniques to uncover parsing weaknesses. They should also verify parser configuration, review error logs, and confirm that security controls work as intended before deployment.
Keep Your API Safer From the Start
A weak JSON setup can leave your API open before you even process the data. That’s why secure parser settings and strict validation matter every time you accept input. Don’t assume the default configuration is safe. Check it, test it, then make sure every request meets your rules before your application acts on it.
If you want practical guidance, the Secure Coding Practices Bootcamp is a great next step. It helps developers build secure code with hands-on labs that cover real risks, not just theory. Join the training and start writing safer code with more confidence.
References
- https://raw.githubusercontent.com/OWASP/CheatSheetSeries/master/cheatsheets/Deserialization_Cheat_Sheet.md
- https://42crunch.com/addressing-harbor-registry-vulnerability-with-42crunch/