You've added Jackson to your project, configured your ObjectMapper, and moved on. The library works, your tests pass, and JSON flows through your API without issue. But security engineers keep finding deserialization vulnerabilities in production code, and the pattern is consistent: teams believe myths about how Jackson handles untrusted input.
These myths persist because Jackson's documentation focuses on functionality, not threat modeling. Your team reads about features like polymorphic type handling and sees configuration options, but the security implications get lost in the implementation details. Let's correct the record.
Myth 1: Jackson Is Insecure by Default
Reality: Jackson ObjectMapper uses secure defaults and is fundamentally safe when you use current versions.
The library doesn't enable dangerous features without explicit configuration. Your baseline ObjectMapper instance won't automatically deserialize arbitrary types or execute code from JSON payloads. The vulnerability surface only expands when you enable specific features—particularly default typing—or when you run outdated versions with known CVEs.
The real risk is configuration drift. A developer enables a feature to solve a specific problem, that configuration gets copied across services, and nobody documents why it exists. Six months later, you're running a dangerous setup that nobody remembers implementing.
Update to the most recent Jackson version before you do anything else. Known security issues get patched, but only if you're running a version that includes the fixes.
Myth 2: Default Typing Is Just a Convenience Feature
Reality: Default typing is a deserialization vulnerability waiting for an exploit payload.
When you enable default typing, you're telling Jackson to use type information embedded in the JSON itself to determine which Java class to instantiate. This means an attacker who controls the JSON input can specify which classes get instantiated during deserialization.
The attack surface is your entire classpath. An attacker doesn't need to find a vulnerability in your code—they need to find any class in any library you depend on that performs dangerous operations in its constructor, setter methods, or during deserialization. Tools exist to enumerate these "gadget chains" automatically.
Default typing is not enabled by default in Jackson, but that's not enough. Your team needs to actively prevent it from being enabled. Add a linting rule that flags enableDefaultTyping() calls. If you absolutely need polymorphic type handling, use @JsonTypeInfo annotations on specific classes with a whitelist of allowed subtypes. Never let the JSON payload itself determine which types get instantiated.
Myth 3: If Your API Validates Input Schema, Deserialization Attacks Don't Matter
Reality: Schema validation happens after deserialization, when the malicious code has already executed.
Consider your typical request handling flow: the web framework deserializes the JSON body into objects, then your validation logic checks field values. But deserialization vulnerabilities trigger during that first step. The malicious payload executes code through the deserialization process itself—your validators never get a chance to run.
This is why deserialization vulnerabilities appear in OWASP's Top 10 and why PCI DSS v4.0.1 Requirement 6.2.4 requires you to address vulnerabilities based on risk rankings. A deserialization vulnerability gives an attacker code execution before any of your security controls engage.
Your input validation still matters for business logic attacks, but it provides zero protection against deserialization exploits. You need to secure the deserialization configuration itself.
Myth 4: Dependency Scanning Will Catch These Issues Automatically
Reality: SCA tools find known CVEs, not dangerous configurations in your code.
Tools like Snyk scan your dependencies for published vulnerabilities and alert you when a new CVE affects a library version you're using. This catches known exploits in Jackson itself—critical for your security posture.
But these tools don't analyze how you've configured Jackson in your application code. If you've enabled default typing or implemented custom deserializers with security flaws, your SCA scanner won't flag it. The vulnerability is in your configuration choices, not in the library.
You need both: SCA tools to manage library vulnerabilities and code review practices that catch dangerous deserialization patterns. Train your team to recognize risky ObjectMapper configurations during pull request reviews. Better yet, create a secure ObjectMapper factory that your entire codebase uses, so you control the configuration in one place.
Myth 5: This Only Matters for Public-Facing APIs
Reality: Internal services processing JSON from other systems face the same risks.
Your microservices communicate via JSON. Your message queues carry JSON payloads. Your internal admin tools accept JSON from frontend applications. Every service that deserializes JSON is a potential entry point.
An attacker who compromises one service can pivot to others by sending malicious JSON through your internal APIs. If your external API is locked down but your internal service mesh trusts all input, you've just moved the vulnerability one hop deeper into your infrastructure.
Apply the same deserialization security standards to internal services. Your threat model should assume that an attacker has already breached your perimeter and is attempting lateral movement. Defense in depth means securing deserialization everywhere, not just at the edge.
What to Do Instead
Start with an inventory. Search your codebase for enableDefaultTyping() calls and document why each instance exists. In most cases, you'll find it was enabled to solve a problem that has better solutions.
Create a secure ObjectMapper configuration that your entire team uses. Disable default typing explicitly. Configure specific type handling with whitelists when you need polymorphism. Version this configuration in a shared library so changes get reviewed and tested.
Integrate SCA scanning into your CI/CD pipeline. Configure Snyk or an equivalent tool to fail builds when high-severity vulnerabilities appear in your dependencies. This catches library-level CVEs before they reach production.
Add deserialization security to your code review checklist. Train developers to recognize dangerous patterns: default typing enabled, custom deserializers that execute code, ObjectMapper configurations that change based on user input.
Finally, test your deserialization logic with malicious payloads. Security testing shouldn't stop at SQL injection and XSS. Build test cases that attempt to exploit deserialization vulnerabilities, and verify that your configurations block them.
Your Jackson configuration is security-critical infrastructure. Treat it that way.
