Signature verification proves that some referenced XML content was signed. It does not automatically guarantee that the application will use that same content. If the code later reads the first Assertion in the document, or pulls values through a global XPath or tag query, an attacker can supply unsigned data that bypasses the signature check.
Why signature verification and assertion use are not the same control
In SAML processing, the signature check and the application’s data selection logic are separate steps. A signature can confirm that a specific XML node was signed, but the application still has to ensure it reads values from that exact signed node. If the parser trusts document structure instead of the verified element, the security promise of the signature is lost.
The practical failure mode is not “signature missing,” it is “signature verified on one part of the XML, but business logic consumed another part.” That is why SAML handling must be treated as a parsing and binding problem as much as a cryptographic one. A secure implementation binds the verified signature to the assertion actually used for authentication and authorization.
For teams testing or reviewing this class of issue, the relevant question is whether the code performs a strict reference check from the signature to the consumed Assertion, or whether it later resolves the first matching tag, an unconstrained XPath result, or another globally searched node. The latter pattern can let attacker-controlled content survive even when a signature was technically validated.
See also the XML-security lesson that underlies this class of bug in Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, where token trust, downstream use, and access scope mattered as much as the initial credential or assertion source.
For a broader identity and trust reference point, the Ultimate Guide to NHIs is useful because it frames how signed or tokenised material only has value when the consuming system actually binds it to the right subject and scope.
Where the bypass happens in real implementations
Most failures come from one of three mistakes: validating one XML element while reading another, trusting any Assertion in the document after validation, or using a broad XPath or tag query that does not preserve the signed reference. All three create a gap between cryptographic proof and application trust, which is exactly where attackers insert unsigned or attacker-controlled fields.
This is why canonicalisation, reference validation, and parser discipline matter. If the assertion can be duplicated, reordered, wrapped, or shadowed, the application must still resolve the exact signed object rather than the first object that looks semantically correct. Otherwise, the signature check becomes a false sense of safety.
In practice, the safest pattern is to validate the signature, confirm the signed reference matches the intended Assertion ID, and then pass only that verified object into business logic. Any design that lets the parser “find” identity data after the fact should be treated as suspicious until proven otherwise.
For comparison, the problem is similar to reading a certificate field or token claim from a general document store after validating only one source object. The trust decision must follow the verified reference, not whichever value is easiest to extract.
For implementation and testing guidance, the most relevant external references are the OWASP ASVS and the OWASP Web Security Testing Guide, both of which reinforce strict validation and security testing of parser-dependent controls.
The broader control principle is also captured in NIST SP 800-207 Zero Trust Architecture, which treats verification as something that must precede trust decisions rather than merely accompany them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Access decisions must be bound to the verified SAML subject and claims. |
| Recommendation — Enforce least-privilege access decisions from the verified assertion only. | ||
| OWASP Agentic AI Top 10 | A1 — Prompt Injection | Parser trust failures mirror unsafe consumption of attacker-controlled content after validation. |
| Recommendation — Verify the consumed object matches the trusted source before acting on it. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question concerns whether authenticated identity data is actually trusted by the application. |
| Recommendation — Bind authentication results to the exact identity object used by the application. | ||
| NIST SP 800-63 | 5 — Assertion and Federation | SAML assertions are federation artifacts whose integrity and binding must be validated before use. |
| Recommendation — Validate federation assertions and consume only the verified assertion reference. | ||
| NIST Zero Trust (SP 800-207) | 3 — Verify Explicitly | The issue is whether verification and trust are separated correctly in the access path. |
| Recommendation — Require explicit verification of the exact assertion before any trust decision. | ||
Practitioner Guidance
What to verify: Confirm that the application binds the verified signature to the exact Assertion object it later consumes. If the code uses a general XML search, a first-match rule, or a separate parsing path, treat that as a design defect until the trust chain is proven end-to-end.
Common mistake: Teams often stop at “signature validated” and never test whether the authenticated subject, NameID, audience, and other claims came from the same signed element. That gap is where assertion wrapping and related XML-trust failures become exploitable.
Practitioner takeaway: A SAML signature is only meaningful when the application consumes the same signed content it verified, because cryptographic validity without strict object binding is not a trust guarantee.
Related resources from NHI Mgmt Group
- What is the difference between enforcing MFA on GitHub and enforcing SAML SSO?
- What is the difference between trusting a User-Agent header and verifying request provenance?
- What is the difference between decoding a SAML assertion and validating a SAML assertion?
- What is the difference between trusting a user signal and verifying behaviour in access decisions?
