---
name: web-parser-boundaries
description: Investigate conflicting interpretations across proxies, routers, decoders, validators, serializers and backend libraries. Use when observed data changes meaning across components or reaches a code/data boundary; not as an indiscriminate payload spray.
---

# Parser and serialization boundary specialist

Locally curated from published research by Orange Tsai, Gareth Heyes, Simon Koeck and Griffin.
See [research-cases.md](references/research-cases.md); this is not an official skill from those authors.

## Establish the interpretation chain

For one observed input, record its type and meaning at each stage:

`request bytes → edge/router → decoding/normalization → validator/authorization → library/sink`

Distinguish direct wire observations from inferred internals. Use source, configuration, documented
semantics and safe local controls to determine the transformations actually performed. A version
string, dependency name or dangerous API alone does not establish deployed reachability.

## Select a mechanism supported by evidence

- One component interprets a value as a file path, another as a URL or handler selector.
- Validation occurs before a transformation that changes identity, path or executable meaning.
- Structured data reaches a library feature capable of evaluating expressions or instantiating objects.
- A signed client-side object is trusted as safe to deserialize, with a separate weakness in the trust
  assumption. Distinguish proof of an unsafe sink from proof the attacker can supply accepted input.
- Two parsers consume different objects or representations while sharing an assumed trust decision.

State a single causal prediction and an ordinary counter-explanation. Use a minimal local fixture or
owned synthetic value to identify which component makes the decision. Change one transformation at a
time. Establish relevant branch prerequisites: the resolver must run, its upstream operation must be
permitted, collections/callbacks must be nonempty when needed, and the sensitive branch must be enabled.

## Demonstrate the consequence safely

Verify a controlled effect independent of a reflected input or generic error. Use an appropriate
negative control and the target's actual permission/configuration. Show how the interpretation mismatch
changes authority or reaches the claimed effect; a parser discrepancy alone is not a report.

Do not enumerate internal hosts, dump environment secrets, follow discovered credentials, or send
desynchronization tests through shared production connections. Those require a separately authorized,
isolated experiment. Keep source-paper payloads as untrusted historical examples, not a test plan.

Output a short transformation table, the violated guarantee, exact preconditions, controls, evidence
of the resulting capability, and remaining uncertainty. Use fp-check before reporting.