A SAML attack in which a forged assertion is inserted into a message so that the application processes the attacker-controlled identity instead of the legitimate one. The vulnerability usually appears when signature checks cover one part of the document while identity extraction reads another part first.
Expanded Definition
Assertion injection is a SAML flaw in which an attacker places a forged assertion into a message so the relying application accepts the attacker’s identity or attributes. The core problem is not just weak authentication, but a mismatch between what is signed, what is parsed, and what the application trusts first. In practice, the security boundary can fail when the signature validates one element while the identity lookup uses another, or when multiple assertions are accepted without strict correlation. Standards guidance on SAML processing makes this an implementation and validation issue, not a feature of the protocol itself, and the same logic appears in broader identity assurance work under NIST Cybersecurity Framework 2.0 identity and access control outcomes. Definitions vary across vendors when the flaw is bundled with XML signature wrapping, but the operational risk is the same: the application makes an authorization decision on attacker-controlled identity material. The most common misapplication is assuming that a valid XML signature alone proves the assertion used by the app is the one that was signed, which occurs when parsers and business logic inspect different nodes.
Examples and Use Cases
Implementing SAML validation rigorously often introduces parser complexity and tighter message handling, requiring organisations to weigh interoperability against the cost of strict canonicalisation and assertion binding.
- A cloud portal accepts a signed response, but the login module reads the first assertion in the document instead of the signed one, letting the attacker impersonate a privileged user.
- An internal SSO gateway validates the response signature yet fails to verify that the assertion ID referenced by the signature matches the assertion used to create the session.
- A federation setup reuses loose XML parsing across services, so a malicious assertion embedded in a nested structure is processed before the legitimate one.
- A security team reviewing identity risk uses the Ultimate Guide to NHIs to compare how identity trust breaks when credentials are accepted without lifecycle controls, then maps the same pattern to SAML trust failures.
- For control testing, teams often align validation steps with NIST Cybersecurity Framework 2.0 outcomes for authenticating identities, authorising access, and logging suspicious federation events.
Why It Matters in NHI Security
Assertion injection matters because a forged identity assertion can become a fast path to privilege escalation, lateral movement, and undetected access inside systems that treat federated login as trusted. For NHI programs, the lesson is broader than SAML alone: any identity pathway that accepts secrets, tokens, or assertions without binding them to the intended subject can be abused by an attacker who understands the parser, not just the protocol. That is especially relevant where service identities, automated workflows, and federated applications depend on tightly controlled trust relationships. NHI governance guidance from the Ultimate Guide to NHIs emphasizes visibility, offboarding, and strict secret handling; those same disciplines help reduce the blast radius when federation is compromised. NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Paired with strong identity governance and NIST Cybersecurity Framework 2.0 logging and access-control practices, that reduces the chance that one forged claim becomes full environment access. Organisations typically encounter the operational cost only after an SSO compromise or incident review, at which point assertion injection becomes unavoidable to investigate and remediate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers identity assertion misuse and trust failures in non-human and federated identity flows. |
| NIST CSF 2.0 | PR.AC-7 | Addresses identity proofing and authentication consistency for access decisions. |
| NIST SP 800-63 | Digital identity assurance depends on validating the authenticator and binding it to the right subject. |
Treat accepted assertions as identity evidence only when signature, audience, and subject checks all align.
