Developer · THE NO-PANIC PLAN
Safely inspect an XML payload before API integration
A neatly indented XML file can still violate an API schema or expose a parser to unsafe external references. This developer workflow separates well-formedness, namespace and schema checks, and server-side security. It uses the browser-local Nirmion XML Formatter only for a safe working copy; that tool blocks DTD and entity declarations and does not validate an XSD or certify a receiver. Test with the parser and schema actually used by your application.
MISSION Inspect XML syntax, encoding, namespaces and schema expectations safely before integrating a payload with an API, while rejecting unsafe external entity behavior.
Inspect a safe XML sampleTHE REAL-WORLD BIT
What happens outside this browser tab?
Record the receiver's XML contract and schema; preserve and sanitize a reproducible sample while checking encoding and source trust; inspect syntax with a local formatter only when its DTD restrictions fit the contract; validate against the exact trusted schema using hardened parser settings; then exercise valid and hostile cases in an isolated receiver and retain redacted evidence.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Write down the receiver's XML contract first
Before editing a payload, identify the receiving API or application, its documented XML version, root element, namespace URIs, required fields, schema version, and business constraints. Save a known-good synthetic example and the exact schema from an authorized source. A document can be well-formed yet fail schema or business validation, so keep these checks separate. Confirm whether the receiver accepts a DTD or external schema references; treat those as explicit exceptions requiring review, not defaults. Record the sending system and a non-sensitive test identifier so an error can be reproduced. Do not guess a namespace from its prefix: prefixes can change, while the namespace URI is what identifies the vocabulary. (Sources 1, 2, 3)
- 02
Preserve the original and check encoding and trust boundaries
Keep an unchanged copy of the received bytes and work on a separate sample. Remove credentials, personal information, customer data, and production identifiers before sharing a payload with a tester or ticket. Check the HTTP Content-Type, charset and XML declaration against the receiver's contract; conflicting or unsupported encodings can cause parse failures or data changes. Identify whether the document comes from a trusted producer and whether it contains a DOCTYPE, external entity, external DTD, XInclude or schema URL. Do not fetch remote resources from untrusted XML. If the business contract genuinely requires a DTD or external resource, stop and use an approved, hardened parser with an explicit allowlist and security review. (Sources 1, 4, 5)
- 03
Use a local formatter to inspect a safe working copy
For a non-sensitive sample whose contract does not require DTD processing, use XML Formatter (Nirmion tool 146) to check basic XML syntax and indent the structure locally in your browser. The tool blocks document type and entity declarations; that is a deliberate boundary, so a rejection is a reason to confirm the sender's format and your security policy, not to disable protections blindly. Compare the formatted output with the unchanged original, especially whitespace-sensitive text, namespaces, attributes, empty elements and encoding. This tool does not validate an XSD, check application-specific required values, prove a payload is safe for your server, or replace parser tests in the target runtime. (Sources 1, 2, 4)
- 04
Validate against the exact schema with a hardened parser
Run the payload through the same approved parser and schema version used by the receiver, using a local or trusted schema file from the API owner. Confirm namespace URIs, element order, data types, cardinality, required fields and any constraints not represented in XSD. Configure the parser to reject DOCTYPE and disable external general and parameter entities, external DTD loading, remote schema retrieval and unsafe XInclude unless a reviewed requirement explicitly needs them. Apply secure processing and size, depth and time limits. If the library cannot enforce the required settings, fail closed and choose an approved implementation; OWASP notes that parser APIs differ. Do not accept a schemaLocation supplied by an untrusted payload as permission to fetch an arbitrary URL. (Sources 2, 3, 4)
- 05
Test success and rejection paths in an isolated environment
Run the exact receiver version in a staging or local environment with synthetic cases: known-good XML, malformed tags, unknown namespaces, missing required fields, wrong encodings, oversized/deep documents, and a DOCTYPE or external-entity payload that must be rejected without filesystem or network access. Confirm a valid request produces the intended result once, and rejected input has no side effect. Verify content type and charset end to end and compare the interpreted values with the original bytes. Log a correlation ID, parser error class and safe field names while redacting payloads, tokens and personal data. Save the schema version, parser version, test result and owner so the next contract change can be checked against the same cases. (Sources 1, 2, 3, 4, 5)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-09