A service decodes JSON with a general-purpose object mapper, and someone turns on the mapper's polymorphic type handling globally so that interface-typed fields round-trip. Explain what that configuration changes about which types an incoming document can cause to be constructed, why a global switch differs from declaring permitted subtypes on one field, what a YAML library's "safe load" entry point actually is in the same terms, and what a team has and has not achieved by migrating an endpoint from a native object stream to JSON.

## What the setting actually does A plain JSON document cannot name an application type: the grammar has objects, arrays, strings, numbers, booleans and null, and nothing else. The type-selection channel is created one layer up, by the **binder** — the component that turns the parsed tree into typed objects. Polymorphic type handling is the binder feature that says: when a field is declared as an interface or abstract base, look inside the document for a type discriminator and construct whatever it names. That is the whole change. No byte of the format gained power; the *policy governing the decoder* did. Once that policy is on, the document is choosing the class to instantiate, which is the same authority a runtime's native object stream has always had. ## Global versus per-field: open-world against closed-world This is the distinction interviewers are probing, and it is the same open-world/closed-world argument that governs every injection defence. - **Global** means: any field typed loosely enough is a selection point, and the permitted set is defined negatively — everything the class loader can find that the binder can instantiate. Nobody wrote that set down. It grows every time a dependency is added, including transitively. Its size is unknown to the team by construction. - **Per-field with declared subtypes** means: this one field accepts one of, say, three tags, and a table in code maps each tag to a concrete type. The set is finite, owned by the source tree, and visible in review when someone adds a fourth entry. A filter that blocks "dangerous-looking" type names is not a substitute. A deny pattern is open-world — it still admits every name nobody thought of, exactly as a character pattern over a column name still admits every real column including the sensitive ones. Enumeration is finite; a pattern is not. ## Why type selection alone is sufficient Candidates often assume an attacker needs the application to *use* the decoded object. Usually not, because reconstruction itself executes application code: - a custom read routine the type defines to rebuild its own state; - an object-resolution or restore callback the runtime invokes on a freshly decoded instance; - ordinary constructors, property setters and initialisers the binder calls to populate fields; - lifecycle or cleanup callbacks that fire later, on garbage collection or shutdown; - **hash and equality methods of decoded elements**, invoked while a decoded map or set is being filled — the easiest one to forget, and a favourite because it needs no cooperation from the surrounding code at all. So "we decode it and then validate it" is too late: the interesting work happened during decoding, before any validation statement ran. Validation is a rung below the structural fix for precisely this reason. ## "Safe load" is an enumeration wearing a different name YAML libraries that honour type tags typically ship two entry points: the permissive loader that constructs application types named by the document, and a safe loader restricted to core scalars and collections. Read that safe loader in the vocabulary above and it is not a sanitizer, not an escaper, and not a validator — it is a **closed-world enumeration of permitted types**, hard-coded by the library author. Its safety comes from the same property as the per-field subtype table: someone wrote the finite list, and the document cannot extend it. The practical consequence is that safety here is one function call wide. Two call sites in one codebase, on identical syntax, can sit on opposite sides of the boundary, and only the call site tells you which. ## What the migration buys, and what it does not A team that replaces a native object-stream endpoint with JSON and leaves global polymorphic handling enabled has re-implemented the same defect in nicer syntax. Worse, the migration is usually *reported* as remediation, so the finding closes while the sink stays live. Two conditions make the migration real: 1. **Target types come from code.** Either the endpoint binds to one fixed shape, or a finite code-owned tag→type table supplies the alternatives on the specific field that needs them. 2. **Resource budgets are enforced independently** — nesting depth, element counts, declared sizes, decompression ratio, decode timeout — because none of that changed with the format, and a decoder can still be made to exhaust memory or CPU without constructing a single application type. One more caveat worth a sentence: some decoders carry capabilities that need no type resolution at all, such as an XML processor that resolves external entities or expands nested ones. Same lesson from the other direction — enumerate what your decoder is permitted to do and switch off what you do not need, rather than reasoning about payloads. ## Where this sits on the ladder The ordering is structural separation, then escaping or transformation, then validation, then detection, weakening from guarantee to heuristic at each step. For decoding, the top rung means the wire never selects a type. Where some choice genuinely must be data-driven, closed-world enumeration takes the top rung in its place — for the open-world/closed-world reason above. Post-decode validation and monitoring stay useful, but they operate after the moment that mattered. ## Interview framing "Ask two questions of any decode path: can the document name the type, and does reconstruction run code? Then ask where the permitted set is written down. If the answer is 'wherever the class loader can reach', that is the finding — regardless of whether the payload is JSON, YAML or a native stream."