Security guide
Verify an XML Signature safely
Separate reference digest validation, SignatureValue verification, key trust, and application meaning so a valid XML signature protects the intended data.
11 min read · Updated 2026-08-21
The short answer
Verify every Reference digest and the SignatureValue with a maintained XML security library, establish trust in the verification key independently, restrict algorithms and dereferencing, and then consume the exact node that the validated reference identified. A cryptographically valid Signature element does not by itself prove who signed it, that every security-relevant node was covered, or that the application later read the signed node.Understand the four separate verdicts
Reference validation proves the transformed, canonicalized referenced data matches each DigestValue. Signature validation proves SignatureValue matches canonicalized SignedInfo. Trust validation decides whether the key is acceptable. Application validation decides whether the signed content is fresh, intended for this recipient, and authorized for this operation.
- Reject duplicate IDs before resolving same-document references.
- Allow only expected digest, signature, canonicalization, and transform algorithms.
- Disable external URI dereferencing unless the protocol requires an allowlisted target.
- Treat KeyInfo as a hint, not automatic trust in a message-supplied key.
Verify what the application will use
After the library resolves and verifies a Reference, carry that exact node or immutable object into authorization and business logic. Do not validate one node and then run a new broad XPath such as //Assertion or //Body that an attacker can redirect to an unsigned sibling.
Require the signed node's expected local name, namespace, document location, and relationship to the protocol container. Cryptography protects bytes after transforms; the application still owns structural expectations.
1. Parse with DTDs, entities, and network access disabled.
2. Reject duplicate ID values and unexpected Signature locations.
3. Resolve each allowed Reference and verify every digest.
4. Verify SignatureValue with a trusted, policy-approved key.
5. Validate time, audience, recipient, issuer, and replay state.
6. Process the exact verified node — do not search for it again.Canonicalize only through the signature library
Canonicalization turns an XML node set into the octets that are digested or signed. Reformatting, reparsing with different entity behavior, or serializing through an object mapper can change those octets. Let the XML security library execute the declared, policy-approved canonicalization and transforms.
Log identifiers and algorithms, not keys or sensitive assertion values. Keep negative tests for altered content, missing references, duplicate IDs, untrusted keys, disallowed algorithms, and a valid signature over the wrong node.
Prove the fix
- Inspect the signature vocabularyTrace references, algorithms, digest values, and key information.
- Review SAML consumptionBind application processing to the verified assertion or response.
- Review platform securityKeep parsing, storage, transport, and application controls layered.
Related guides
- Prevent SAML XML signature wrappingValidate SAML structure, signatures, destination, audience, time, request correlation, and replay without consuming an unsigned sibling assertion.
- Build and validate WS-Security UsernameToken and TimestampPlace WS-Security headers correctly, validate freshness and replay state, and understand what PasswordDigest and TLS each protect.
- XML namespace prefix vs URIUnderstand why prefixes are replaceable aliases, why namespace URIs are compared literally, and how expanded names keep documents interoperable.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.