Understand how SAML Shield’s validation engine protects your application.
SAML Shield protects your SSO infrastructure from protocol-level vulnerabilities to keep you safe even if there are vulnerabilities in your SAML library or implementation. Our validation engine is built to detect and block malformed, manipulated, or dangerous assertions in real time—before they reach your application logic.
SAML exploits tend to repeat across ecosystems (Node, Python, Ruby, Java) because they target structural weaknesses in the protocol itself—not just individual library bugs. The SAML spec is complex and nuanced, which makes it easy to accidentally introduce edge-case vulnerabilities even in well-maintained libraries. SAML Shield enforces a hardened ruleset that proactively defends against these categories.
| Exploit | How it works | SAML Shield's defense |
|---|---|---|
| Algorithm Downgrade | The assertion uses outdated or weak cryptographic algorithms that are easier to forge. | Only allows modern cryptographic algorithms (e.g., SHA-256, RSA-PSS, ECDSA). |
| Replay Attacks | Valid assertions are reused within their expiration window (or long after), bypassing user authentication. | Validates NotBefore, NotOnOrAfter, and InResponseTo with tight skew enforcement and replay detection. |
| Unsigned or Partially Signed Assertions CVE-2025-25291, CVE-2020-29511 | Only parts of the assertion are signed—or not signed at all—allowing silent modification of key fields. | Requires full, correct digital signatures on assertions and their fields. |
| XML External Entity (XXE) & Entity Injection CVE-2013-6440, CVE-2016-10127, CVE-2020-29509, CVE-2020-29510, CVE-2025-46573, CVE-2025-25293 | Maliciously crafted assertions exploit XML parsers to access internal files, cause denial of service, or exfiltrate data. | Uses secure XML parsing with external entities and DTDs disabled. |
| XML Signature Wrapping (XSW) CVE-2017-1000452, CVE-2017-11427, CVE-2020-5390, CVE-2020-15216, CVE-2024-45409, CVE-2025-29775 | Attackers move or clone signed elements to trick the signature check into passing while modifying critical data. | Strict canonicalization rules and element scope enforcement ensure the signed content is exactly what is expected. |
Stytch-hosted SAML Shield is continuously updated with the latest protections as new CVEs and attack patterns emerge. Self-hosted open source users can manually update the core ruleset by pulling the latest package version.
SAML is broad and attackers are creative. If you have a novel use case, edge-case assertion, or CVE not listed, reach out to us—we’d love to evaluate it and expand SAML Shield’s coverage.
SAML Shield is designed to harden the protocol layer—but it’s not a complete SAML solution. It doesn’t replace your identity provider or your existing SAML library. Instead, it complements them by proactively blocking malformed or malicious assertions before they reach your app.
To fully secure your SAML flow, there are key responsibilities that still live outside of SAML Shield:
Keep Your SAML Library Up to Date
SAML Shield defends against a wide class of protocol-level attacks, but you should still upgrade your underlying SAML library to the latest stable version to practice defense in depth. Open source maintainers do the hard work of regularly patching logic bugs, dependency issues, and implementation-specific vulnerabilities that fall outside SAML Shield’s scope.
(OSS Only) Keep SAML Shield up to date
If you’re using the managed version of SAML Shield, you’re always protected with the latest rules and CVE coverage—updates are applied automatically as new threats emerge.
For open source users, make sure to regularly update the package to receive the latest security checks and improvements. Staying current ensures you’re protected against the evolving landscape of SAML vulnerabilities.
(OSS Only) XML Size Limits over 1MB
The OSS version cannot enforce size limits since it doesn’t have access to the raw HTTP body. Large payload filtering must be done at your proxy or app layer.
Assertion ID Replay Detection
SAML Shield currently does not track assertion IDs for detecting replayed tokens. You’ll need to implement assertion ID tracking in your own session or cache layer.
Encrypted SAML Assertions
SAML Shield does not currently support validation of signatures within encrypted SAML assertions. To preserve its drop-in simplicity, it avoids handling private decryption keys, which would introduce complexity and security risks. As a result, encrypted assertions are allowed to pass through unvalidated, and users should decrypt the SAML response before passing it to SAML Shield for validation. This decryption step must be handled in application code and is not possible when using the proxy-based integration.
Audience & Issuer Validation
We don’t have context about your Service Provider configuration, so audience and issuer checks must be enforced by your SAML library or business logic.