A SAML service provider should accept a login only after it verifies a trusted signature on the content it actually uses, then checks Destination, Audience, validity times, Recipient and InResponseTo, and guards against replay. Most SAML bypass bugs come from skipping one of these or from checking the wrong part of the XML.
Signature validation
- Validate the XML against a local, trusted schema before using it for any security decision. Do not download schemas from third parties.
- Take the signing key from your configured IdP metadata. Ignore
KeyInfoinside the message, which an attacker controls. - Use a static key selector when you expect one key, or an X509 selector when the IdP rotates among several.
- Require at least RSA-SHA-256 and reject SHA-1 based signature and digest algorithms.
Guard against signature wrapping
XML signature wrapping moves or duplicates elements so that the part that is signed is not the part your code reads. The OWASP SAML cheat sheet advises:
- Do not use
getElementsByTagNameto pick security relevant elements before validation. - Use absolute XPath expressions unless you rely on a hardened schema.
- Confirm that the signature's Reference URI points at the Assertion or Response you are consuming, and reject assertions outside the signed content.
The simplest rule: only read data from the exact node whose signature you verified.
Message field checks
| Field | Check |
|---|---|
| Destination | Exactly matches your Assertion Consumer Service URL. Reject if missing or different. |
| Audience | Matches your SP entity ID. |
| NotBefore, NotOnOrAfter | Current time is inside the window, allowing small clock skew. |
| Recipient | Matches your ACS URL, in the subject confirmation data. |
| InResponseTo | Matches an authentication request you issued, for SP initiated flows. |
Replay prevention
For IdP initiated sign in there is no request ID to match, so detect replay at the response or assertion level, for example by remembering assertion IDs until they expire. Prefer short lifetimes and OneTimeUse, and avoid caching SAML protocol messages, since a cached message can be replayed.
Transport
Exchange assertions only over TLS.
Operational points
- Keep IdP metadata and certificates under change control. When the IdP rotates certificates, update before the old one expires.
- Log failed validations with reason codes, but not whole assertions, which hold personal data.
- Map the user by a stable identifier from the assertion, and be careful with email addresses as keys.
- Keep the SAML library patched. Parsing and signature libraries have had serious flaws, so subscribe to their advisories.
Test list
Write tests that must fail: an unsigned response, a response with a wrapped second assertion, a wrong audience, an expired assertion, a replayed assertion, and a different Destination.
Quick check
Is signing the Response enough, or must the Assertion be signed?
Either can be valid in a deployment, but you must verify whichever you read from, and confirm the signature covers that exact element.
Why ignore KeyInfo in the message?
An attacker can put their own key there. Use keys from IdP metadata that you obtained and trust out of band.
Sources
Last reviewed: 19 October 2026.
