Duplicate key precedence is the rule a parser uses when a JSON object contains the same field name more than once. Some parsers keep the first value, some keep the last, and some reject the document. When services disagree on precedence, attackers can smuggle one value past validation and another into execution.
What duplicate key precedence means in parsers
Duplicate key precedence describes how a parser resolves repeated field names inside a JSON object. The rule is not universal: some parsers keep the first occurrence, some keep the last, and some reject the payload outright.
The practical significance is that the same document can be interpreted differently at different stages of a request path. If validation, logging, filtering, and downstream execution do not all use the same duplicate-handling rule, the object no longer has a single stable meaning.
Why duplicate key precedence creates security ambiguity
JSON normally presents each field name as if it were unique, so duplicate keys turn a simple data structure into an interpretation problem. That ambiguity matters when one system validates one value while another system later consumes a different value from the same object.
This is especially important in security-sensitive flows such as authorization decisions, request normalization, policy checks, and message mediation. A validator may inspect an apparently safe value, while the application or library that finally executes the request reads the attacker-controlled duplicate instead.
Common parser behaviors and where they differ
Implementations usually fall into one of three behaviors: first-value wins, last-value wins, or reject-on-duplicate. Those choices can appear in parsers, deserializers, gateways, schema validators, and application frameworks, and they may not all agree with each other.
That inconsistency becomes dangerous when a request passes through multiple layers. A reverse proxy, API gateway, schema validator, and backend service may each parse the same JSON body differently, which makes it possible for the meaning of a field to change as the request moves deeper into the stack.
For API-heavy systems, the risk is closely related to authorization and request-shaping failures described in the OWASP API Security Top 10, especially when duplicate fields affect object-level or function-level decisions.
How to reason about duplicate keys in secure design
Duplicate key precedence should be treated as a data-validation and trust-boundary issue, not just a parsing detail. The safest design choice is to make the handling rule explicit and consistent everywhere a JSON object can be accepted or transformed.
Where organizational controls are being defined, secure parsing and input handling fit naturally within NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly controls concerned with input validation, system integrity, and access enforcement. For application teams, the issue is also captured in API security guidance and in parser behavior that must be aligned across all components that consume the same object.
Risk and Threat Considerations
Duplicate key precedence creates a classic interpretation-confusion risk: one value can be used to pass validation while a different value is later used by the business logic. That makes the issue attractive in request smuggling, access-control bypass, and policy-evasion scenarios wherever the same payload is parsed more than once.
Failure mechanism: An attacker supplies repeated field names so that one component enforces a benign value while a downstream component honors the attacker-chosen duplicate.
Impact: The result can be authorization bypass, data corruption, logging inconsistency, or execution of an action that was never approved by the component that performed validation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Duplicate keys can alter which function-level request value is honored. |
| API1 — Broken Object Level Authorization | Conflicting object fields can change the object a request is authorized against. | |
| Recommendation — Reject duplicate fields before function-level authorization is evaluated. Normalize request bodies so object-level authorization uses one canonical field value. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Duplicate JSON keys are an input-validation ambiguity that can change downstream behavior. |
| AC-3 — Access Enforcement | Precedence confusion can undermine enforcement when different components read different values. | |
| Recommendation — Validate inputs to reject ambiguous duplicate fields before processing continues. Enforce access decisions only after the request is canonicalized and unambiguous. | ||
Practitioner Guidance
What to watch for: Treat duplicate keys as an explicit policy decision, not an implementation accident. Teams should verify whether their parser rejects duplicates, preserves the first value, or preserves the last value, then make sure every upstream and downstream component applies the same rule.
Common misunderstanding: It is not enough to assume that “JSON objects should not contain duplicates,” because real parsers often accept them differently. Where ambiguity can affect authorization or business logic, reject duplicates early and ensure the rejected condition is visible in testing, logging, and security review.
