[docs] Treat caller-supplied parser instances as trusted configuration

[ppkarwasz]

Why

A recurring vulnerability-report shape builds its own permissively configured XMLReader (external entities enabled), hands it to the library inside a SAXSource, and reports the resulting entity resolution as XXE. A recent report of this shape against Batik's SAXDocumentFactory.createDocument(..., XMLReader) is typical.

The code already takes a position on this channel: HardeningTransformerFactory documents that a SAXSource carrying its own XMLReader is trusted as-is, with the caller expected to supply a hardened reader. The threat model, however, never said it: it covers loosened reserved settings, installed resolvers and caller-supplied top-level URIs, but not caller-constructed parser objects, so such a report could only land in MODEL-GAP.

What

Docs-only change to src/site/markdown/threat_model.md, four edits:

• Adversary model and trust boundary: parser objects the caller constructs outside the library (an XMLReader in a SAXSource, StAX readers in a StAXSource, a pre-parsed DOMSource) sit on the trusted side of the boundary, like the factory configuration; the library hardens what it creates and does not re-harden what the caller built.
• What is out of scope: a new Caller-supplied parser instances bullet, paired with the safe alternative (route your reader through XmlFactories.harden(XMLReader), or build it from XmlFactories.newSAXParserFactory(), before wrapping it in a SAXSource).
• Known non-findings: a bullet describing the report shape itself (permissive self-built reader in a SAXSource, entity resolves), so triage can cite it directly.
• Triage dispositions: the OUT-OF-SCOPE: caller input row now covers a parser instance the caller constructed outside the library.

The added prose follows semantic line breaks, so the rendered page is unchanged in structure and future diffs stay per-sentence.

🤖 Generated with Claude Code