Security guide
Prevent SAML XML signature wrapping
Validate SAML structure, signatures, destination, audience, time, request correlation, and replay without consuming an unsigned sibling assertion.
12 min read · Updated 2026-08-21
The short answer
Parse SAML with dangerous XML features disabled, reject duplicate IDs, verify the required Response or Assertion signature against trusted IdP metadata, and pass the exact verified node into claim processing. Then validate issuer, Destination, Recipient, AudienceRestriction, time conditions, InResponseTo, SubjectConfirmation, and replay state. Never verify one assertion and later select another with //Assertion or a first-match DOM lookup.Bind verification to one protocol node
A wrapping attack exploits a gap between the node a signature library validates and the node application code consumes. Close that gap by requiring the expected signature location and returning the verified element itself from the verification layer.
- Reject duplicate ID values before reference resolution.
- Require a same-document reference to the expected Response or Assertion ID.
- Require the signed node's namespace, local name, and protocol parent.
- Do not search the original document again after verification.
Apply every relying-party condition
A valid signature authenticates protected bytes, not their suitability for this login. Match the issuer to trusted metadata and the verification key, require the expected Destination and recipient, and compare the audience to this service provider's exact entity ID.
Enforce NotBefore and NotOnOrAfter with a narrow documented skew. For solicited SSO, match InResponseTo against an outstanding request and consume it once. Cache assertion or response IDs through the acceptance window to prevent replay.
parse safely → reject duplicate IDs → verify required signature
→ bind trusted key to issuer → validate destination and recipient
→ validate audience and time conditions → correlate InResponseTo
→ reject replay → map claims from the exact verified nodeConstrain metadata and algorithms
Load IdP metadata through an authenticated administrative path, pin the expected entity, and handle certificate rotation deliberately. A certificate embedded in the incoming assertion is not trusted merely because it verifies the signature it accompanies.
Use a maintained SAML library with secure defaults and an explicit algorithm policy. Test unsigned responses, unsigned sibling assertions, duplicate IDs, wrong audience, wrong recipient, expiry, unsolicited responses, and replay—not only the happy path from the identity provider.
Prove the fix
- Inspect SAML structureMap the signed container and every relying-party condition.
- Review signature verificationConsume the exact node whose reference and signature were verified.
- Check namespace identityDo not authorize based on a familiar but attacker-controlled prefix.
Related guides
- Verify an XML Signature safelySeparate reference digest validation, SignatureValue verification, key trust, and application meaning so a valid XML signature protects the intended data.
- 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.