Common SAML security vulnerabilities and how to defend against them

SAML is widely used in the enterprise world. It’s also common knowledge that it’s prone to vulnerabilities. There are a few reasons for that:

• SAML is XML-based, which makes its assertions hard to form, hard to read, and hard to parse (more on why XML sucks).
• The SAML spec is highly complex.
• Developers implementing SAML often lack the knowledge and time to properly build SAML SSO. That’s evident from the fact that most SAML SSO security vulnerabilities are introduced by service providers (SPs) improperly validating and processing SAML responses received from identity providers (IdPs).

In this article we will review some of the most common SAML security vulnerabilities and see how you can defend against them.

We assume that since you are here, you are already familiar with SAML, but if you are not, read this first: What is SAML and how does it work?

‍Common SAML security vulnerabilities

Assertion manipulation

When SAML assertions are not signed bad things can happen. Without a signature an assertion’s validity cannot be verified, allowing an attacker to take advantage of that and manipulate it.

XML Signature Wrapping (XSW) is a security vulnerability targeting XML signatures. The attacker manipulates the signature to sneak unauthorized changes into the content. It exploits weaknesses in how XML signatures are processed and can lead to malicious data manipulation. Depending on the injection's location and the service provider's configuration, it may be possible to inject additional roles, elevate the privileges of the user, or inject an entirely new username in an attempt to compromise another user’s account.

To defend against this issue, make sure that:

• All SAML assertions are always digitally signed by the IdP. When an IdP signs a SAML assertion, it uses a private key to create a digital signature. This signature enables the service provider to verify that the assertion has not been altered in transit and that it comes from the legitimate IdP.
• As a service provider, you validate SAML messages signed only by a trusted IdP.
• As a service provider, you check the signature of each assertion.
• As a service provider, you validate the schema of SAML assertions using local, trusted copies.

Weak encryption

SAML assertions, which are used to verify the user's identity and permissions, must always be encrypted. Data encryption is achieved by using a public key to encrypt the information. Only the party possessing the corresponding private key can decrypt the data. In the SAML context, this means that the IdP can encrypt certain parts of the assertion before sending it to the SP. This ensures that only the SP with the corresponding private key can read the information.

To defend against this, SAML assertions that contain sensitive data should always be encrypted. Use strong encryption algorithms, like AES-256, and ensure regular key rotation.

Replay attacks

SAML messages are vulnerable to replay attacks: the attacker intercepts a valid SAML message and uses it to impersonate a legitimate SAML action (like a user signing in). This type of attack is possible if the system does not implement adequate mechanisms to prevent the reuse of SAML messages, such as timestamps.

To defend against these attacks, make sure to set timestamps for the SAML assertions using the NotBefore and NotOnOrAfter attributes in the samlConditions tag:

• The NotBefore attribute defines the earliest time at which the SAML assertion can be considered valid. Before that time the assertion is considered invalid.
• The NotOnOrAfter attribute specifies the latest time at which the SAML assertion remains valid. After that time has passed, the assertion should not be used for authentication or authorization.

SAML assertions must have very short validity periods and be invalidated as soon as they are used. Typically, one minute is enough time for the IdP to generate a SAML assertion and send it to the SP.

In addition to timestamps, validate the InResponseTo attribute in the SAML response against an ID cache to prevent the reuse of assertions.

Open redirect

SAML is an asynchronous protocol. When an SSO action is initiated by the service provider, the user is directed to the identity provider and forgets about it. The identity provider knows where to send the response using RelayState, an HTTP parameter incorporated in both the SAML request and response. The parameter holds a URL pointing to where the identity provider should send the response. However, an attacker can use this parameter to conduct open redirect attacks.

To defend against such attacks, confirm the value of the RelayState is a trusted URL before redirection.

Man-in-the-middle attacks

If your communications are not encrypted, an attacker might intercept assertions and get valuable information about your app and your users.

To defend against these attacks, send all assertions over HTTPS and use encryption.

XML External Entity (XXE) attacks

These attacks exploit vulnerabilities in misconfigured parsers' processing of XML documents. An XXE attack occurs when untrusted XML input with a reference to an external entity is processed by a weakly configured XML parser. If the SP uses a custom XML parser or one that is vulnerable to XXE, a payload can be injected into the SAML assertion.

The best way to defend against these attacks is to disable DTDs (External Entities) completely. If this is not possible, then external entities and external document type declarations must be disabled in a way that's specific to each parser.

XML round-trip

When your SAML implementation parses and serializes an assertion multiple times, bugs in XML parsers can change the assertion’s shape. Attackers can use stolen or forged assertions to identify such buggy XML parsers. With that information, they can craft specific strings to bypass your security.

To defend against these attacks, use only well-known and recently updated open-source libraries for parsing XML.

Signature exclusion

If a SAML implementation is not properly implemented, it can skip signature validation entirely or check only the signature in the first assertion of many. Attackers can then bypass those insufficient checks and access your users’ data.

To defend against this attack:

• Validate that every assertion in the SAML exchange is signed.
• Validate that the entire SAML response itself is signed.
• Only accept encryption schemes from an explicitly defined set of algorithms (e.g., RS256).

SAML best practices

Let’s summarize some best practices when it comes to SAML:

• Validate the SAML response schema first.
• Check that you’re the intended recipient.
• Disable DTD processing.
• Validate every signature (every assertion + the entire SAML response itself).
• Validate SAML messages signed only by a trusted IdP.
• Validate the schema of SAML assertions using local, trusted copies.
• Use the canonicalized XML.
• Use HTTPS.
• Only accept encryption schemes from an explicitly defined set of algorithms (e.g., RS256).
• Use only well-known and recently updated open-source libraries for parsing XML.
• Disallow your XML parser from fetching and processing DTDs.
• Enforce Content Security Policy (CSP) headers on all SAML requests.
• Confirm the value of the RelayState is a trusted URL before redirection.
• Set timestamps for the SAML assertions using the NotBefore and NotOnOrAfter attributes in the samlConditions tag.
• Always encrypt SAML assertions that contain sensitive data.

For more, check the OWASP SAML Security Cheat Sheet.

The safest way to use SAML

Doing SAML SSO right is an uphill battle, and if you fail, you expose your application and customers to potentially huge security risks. There is a ton of work involved if you want to sleep at night. In this article, we saw some of the vulnerabilities and how to defend against them. However, this is only a subset.

If possible, avoid SAML altogether. Choose OpenID Connect (OIDC) instead, which is more secure and avoids the pitfalls we just saw. If SAML is a hard requirement (and it will be if you plan to sell to enterprise customers), consider using a vendor, like WorkOS, instead of building in-house.

WorkOS allows you to connect to dozens of identity providers like Microsoft Entra, Okta, and any other identity provider that supports OIDC or SAML, complete with session management and user provisioning features.

• Get started fast: With SDKs in every popular language, easy-to-follow documentation, and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Get enterprise-grade SSO up and running in your app within minutes and start closing those enterprise deals.