A SAML security vulnerability handbook for developers

One surefire way to get stuck in developer purgatory is developing a custom implementation of the Security Assertion Markup Language (SAML) protocol to enable enterprise single sign-on (SSO) authentication… without knowing exactly what you’re getting into.

Even if you’ve read our primer amd gone thorough our step by step guide on SAML implementation, you still need to fully understand the scope of possible SAML vulnerabilities and the intricate requirements of developing proper and reliable resolutions. To give you a sense of that scope, let’s examine the common vulnerabilities you need to be aware of—not as a checklist that will declare your implementation ready to handle the stringent requirements of enterprise SSO, but as a peek into how many developer hours go into a secure SAML implementation.

What makes SAML open to vulnerabilities?

As an open standard for exchanging authentication and authorization information between IdPs and SPs, SAML is not inherently vulnerable—it’s merely a description of the handshake between your B2B SaaS product (Service Provider or SP) and the Identity Provider (IdP).

Still, the default SAML response, which is both unsigned and unencrypted, is an extraordinarily complex document:

As a developer, your first task—implementing an authentication system that can properly construct and parse assertions like the above SAML content—is easier said than done.

SAML is based on XML, which has no semantics or defined structure, making it difficult to write and harder to read at a glance. You’ll want to rely on parsers and helper libraries to do the heavy lifting, but there are hundreds of implementations covering all popular programming languages. Some might be wildly popular and seem vetted by the open-source community, but you have no guarantee they’ll work as expected. They could easily introduce new unexpected vulnerabilities into your authentication infrastructure.

Your second task is establishing a security baseline in your SAML implementation by enforcing signed and encrypted assertions, using an XML Signature (XMLDSig) and SHA-256 encryption, respectively. For your authentication system to exchange signed and encrypted messages, you’re dealing now with the infrastructure required to decrypt assertions using keys and safely store certificates, which goes far beyond most developers’ know-how.

These measures help protect your users’ data, but change the contents of your SAML responses and assertions dramatically:

Think of these SAML snippets, and the language as a whole, like a recipe. They give you all the ingredients you need to implement secure authentication, and detail which steps your system must take at each phase of the SSO process… but if you mess up even one small detail, there’s no one to blame but yourself.

The most common SAML security vulnerabilities

An exhaustive exploration of all possible SAML vulnerabilities and viable remedies could take weeks, but if you’re just getting started with validation solutions and deciding whether to build or buy, here are 10 vulnerabilities you need to investigate.

We haven’t ordered these based on any definitions of severity, complexity, or ease of remediation. Why? Because when you’re dealing with enterprise-grade authentication, even the “smallest” vulnerability hurts your trust, costs you customers, and exposes their confidential information to attackers.

XML signature wrapping (XSW)

• What is it? Attackers can use XSW to inject forged elements into a SAML assertion while not affecting the validity of the signature. For example, every SAML assertion contains an attribute relating to a user’s privileges within your SaaS, like ^user, ^editor, and ^admin. Using an XSW attack, an attacker could change a user’s privileges from user to ^admin, giving them widespread access to read or download confidential data from one of your customers.
• How do you prevent it? At a minimum, you need to validate the schema of SAML assertions using local, trusted copies and verify all signatures with a trusted certificate. You should also validate user input for unexpected values.

Lateral movements from non-intended responses

• What is it? An improper SAML implementation might validate an assertion signed with a shared private signing key. After being authenticated once for SSO, the attacker could then move across all SaaS apps integrated into your IdP.
• How do you prevent it? Validate whether the SAML response is intended for your app and discard any mismatches using zero-trust or least-privilege methodology.

Eavesdropping, theft, and man-in-the-middle attacks

• What is it? SAML messages often contain details about the user and their attributes, similar to the XSW vulnerability and an admin account. An attacker capable of accessing these attributes of user accounts gains valuable information about the logic behind your authentication system and narrows their targets for social engineering attacks directly against users with the most privileges.
• How do you prevent it? Ensure your SAML implementation sends all assertions over HTTPS at a minimum. You should also extend your protection with strong encryption like AES-256 with the Algorithm attribute like so:

Expired messages

• What is it? If an attacker intercepts or steals a SAML message, they can exploit that later to impersonate a real user. If your SAML implementation doesn’t expire assertions after a specific time, you’ve given your attacker far more time to fine-tune and perfect their strategy for exploiting your authentication system or your users’ data.
• How do you prevent it? Use the ^NotBefore and ^NotOnOrAfter attributes available from the SAML standard to create a timeline in which your SAML implementation will validate assertions. Given some leeway for clock skew, any messages outside the window must be rejected.

Open redirects

• What is it? For the best user experience, most authentication mechanisms redirect users directly into the SaaS after they successfully log in. When you’re working with enterprise-grade SSO, you can use the RelayState attribute in SAML to specify the redirect URL. If an attacker learns how your SAML implementation processes redirects using query strings, they can inject a new URL to redirect users toward a phishing site.
• How do you prevent it? Create an allowlist of trusted URLs in your SAML implementation to redirect users after they complete authentication for the best balance of user experience and user security. Always validate whether the SAML assertion’s ^RelayState attribute contains one of these hardcoded URLs.

Round-trip attacks in vulnerable XML parsers

• What is it? When your SAML implementation parses and serializes an assertion multiple times during the required handshakes between the user, IdP, and SP, bugs in XML parsers can introduce bugs that change the assertion’s shape. Attackers can use stolen or forged assertions to explore your authentication system for the presence of buggy XML parsers. With that information, they can craft specific strings to bypass your authentication system and log in as a real user.
• How do you prevent it? Use only well-known and recently updated open-source libraries for parsing XML. Run ^{npm audit}, or a similar command for your language/framework, to find vulnerable versions of SAML libraries you use in production.

Signature exclusion

• What is it? Poorly-designed SAML implementations can entirely skip signature validation, or check only the signature in the first assertion of many. Attackers can use forged and unsigned documents to bypass those insufficient checks and access your users’ data.
• How do you prevent it? Only allow SAML responses that are fully signed, and validate that every assertion in the SAML exchange is signed.

Replay attacks

• What is it? These are like a distributed denial of service (DDoS) attack but targeting authentication providers, taking down your authentication services or dramatically spending what you spend on authentication requests.
• How do you prevent it? Implement HTTPs in all your requests and responses and never expose the SAML response to the browser.

XML External Entity (XXE)

• What is it? SAML assertions can reference external entities through a Document Type Definition (DTD). An improperly configured XML parser would access the external entity and execute its payload, putting your authentication system at risk of a DDoS attack or attackers access to confidential information.

• How do you prevent it? Disallow your XML parser from fetching and processing DTDs and enforce Content Security Policy (CSP) headers on all SAML requests. Implement monitoring for filesystem reads or unexpected network requests.

Certificate faking

• What is it? Attackers can use self-signed certificates with their SAML assertions to help them figure out whether a SP verifies that a trusted IdP signs your SAML. Certificate faking is not an attack itself but reveals opportunities for attackers to perform one of the above attacks more knowledgeably.
• How do you prevent it? Ensure your implementation only validates SAML messages signed by a trusted IdP.

How do you identify SAML security vulnerabilities?

Part of the problem with developing an in-house SAML implementation is that you’re not only diving deep into an extraordinarily complex protocol and parser ecosystem but also constantly weighing security versus user experience. Automatically redirecting authenticated users into your SaaS is a positive and now-expected user experience, but implementing it as a developer is non-trivial.

Every nicety and feature you deliver to your SaaS users has downstream effects that could dramatically increase the horizon in which you can develop, secure, and deploy your SAML implementation.

You must still decide whether to build or buy your path toward enterprise-ready authentication with SAML. That starts with estimating the developer hours you’d need and weighing that against the all-in cost of going with an existing provider—and the time you’d win back by not doing it yourself.

Read this before you implement SAML

If you’re going to build your own SAML implementation:

Start by understanding all the vulnerabilities and preventative measures listed above, but recognize that these are just a small subset of the possible SAML vulnerabilities and SSO security measures you should be concerned about. Stay on top of the latest security research from OASIS Open and OWASP regarding newly discovered vulnerabilities.

First off, do not attempt to write your own XML parser. XML and SAML have been around for decades, and security researchers are still discovering and fixing new exploits in popular parsers—you won’t be able to build a more secure implementation without tens of thousands of hours at extraordinary cost.

During your development work, use only modern and updated SAML/XML libraries, and beware when implementing backward compatibility with older XML parsers, which may introduce vulnerabilities you thought you’d solved. To actively test your implementation, use dynamic application security testing (DAST) tools, a SAML-specific tool like SAML Raider, or webapps like Mock SAML.

Your concerns then go beyond pure development work. After deployment, you should also implement a complimentary observability platform for real-time insights into the volume and nature of your SAML requests. To help your DevOps/SecOps/IT administration peers, you should also implement error handling and logging—they’ll need this valuable information in a user-friendly environment to troubleshoot issues and catch incidents before they become outages.

Finally, consider the ongoing maintenance cost—not just of keeping your SSO service functioning but also of regularly auditing your IdP and SP configurations for SAML best practices.

If you’re buying a SAML implementation:

You’ll be in luck with a product like Scalekit, which uses SAML for enterprise-ready SSO authentication. Instead of wading through vulnerability scans and maintaining a massively complex security posture, you can leverage all the expertise and constant improvement of a dedicated team focused solely on building the most secure B2B authentication.

Without upfront development and maintenance costs, you can achieve your goal of providing seamless authentication for your users in a fraction of the time—time you could spend far more profitably building a product your users can’t help but log in to again and again.

‍

Developing a secure SAML stack means navigating an extraordinarily complex protocol, balancing security vs. user experience, and building out XML parsing, encryption and observability infrastructure .  Want to skip the headaches? Sign up for a free Scalekit account to leverage enterprise‑grade SAML SSO and let our dedicated team handle vulnerability mitigation .  Need help designing your SAML security posture? Book a call with our experts.

FAQs

Why are custom XML parsers risky for SAML implementations?

Developing a custom XML parser for SAML is a dangerous undertaking because XML lacks inherent semantic structure and possesses numerous edge cases. Security researchers continuously discover new exploits in even the most mature open source parsers. Attempting to build one from scratch often leads to vulnerabilities like XML External Entity attacks or round trip serialization bugs. These flaws allow attackers to bypass authentication or execute malicious payloads. Instead of investing thousands of hours into a custom parser engineering teams should leverage battle tested libraries or dedicated authentication providers like Scalekit to ensure robust security.

How does XML Signature Wrapping threaten B2B SaaS applications?

XML Signature Wrapping allows attackers to inject forged elements into an assertion without invalidating the digital signature. This vulnerability is particularly dangerous for B2B SaaS products because it enables privilege escalation. An attacker can modify user attributes such as changing a role from guest to administrator to gain unauthorized access to sensitive customer data. To prevent this developers must strictly validate the assertion schema against trusted local copies and verify all signatures using authoritative certificates. Monitoring user input for unexpected values provides an additional layer of defense against these sophisticated manipulation attempts.

Can weak SAML implementations lead to lateral movement attacks?

Yes improper SAML configurations can facilitate lateral movement across different applications within an identity provider ecosystem. If an implementation validates assertions signed with shared private keys without checking the intended audience an attacker authenticated for one app might gain access to others. Preventing this requires a zero trust approach where the service provider confirms the SAML response is specifically intended for that application. By discarding mismatches and enforcing least privilege methodologies architects can ensure that a breach in one service does not automatically compromise the entire integrated enterprise environment.

Why is enforcing SAML message expiration critical for security?

Failing to expire SAML assertions creates a significant window for attackers to exploit intercepted or stolen messages. Without strict time limits an unauthorized party can impersonate a legitimate user repeatedly over an extended period. Developers should utilize the NotBefore and NotOnOrAfter attributes defined in the SAML standard to establish a narrow validation window. While providing slight leeway for clock skew between systems any assertion received outside this designated timeframe must be rejected. This practice minimizes the utility of stolen credentials and forces attackers to find much tighter exploitation windows.

How can developers mitigate open redirect vulnerabilities in SAML?

Open redirects often occur when the RelayState attribute is used to redirect users post authentication without proper validation. Attackers can manipulate query strings to send users to malicious phishing sites compromising their credentials. To secure this process engineering teams should maintain a strict allowlist of trusted destination URLs within their implementation. Every SAML assertion must be checked to ensure its RelayState value matches a safe entry from this list. This balance provides a seamless user experience while preventing the authentication flow from being hijacked for external social engineering attacks.

What are the dangers of signature exclusion in assertions?

Signature exclusion occurs when an authentication system is designed poorly and skips validation for certain assertions or the entire response. Attackers can exploit this by submitting forged unsigned documents that the service provider erroneously trusts. To defend against this your implementation must require that every single assertion within the SAML exchange is fully signed by a trusted identity provider. Validating the integrity of the entire message chain is essential for preventing unauthorized access. Using a managed service like Scalekit ensures these validation checks are always enforced according to modern security best practices.

How do replay attacks affect enterprise authentication providers?

Replay attacks function similarly to distributed denial of service strikes by targeting authentication endpoints with repeated valid requests. This can overwhelm services leading to outages or significantly increasing the operational costs associated with authentication processing. To mitigate these risks developers should always implement HTTPS for every request and response to protect data in transit. Furthermore the SAML response should never be exposed to the browser environment where it can be easily captured. Implementing unique identifiers for each assertion and tracking their usage also helps in identifying and blocking repeated malicious attempts.

What steps prevent XML External Entity attacks in SAML?

XML External Entity attacks exploit parsers that process Document Type Definitions to execute payloads or access sensitive system files. This can lead to data exfiltration or service disruption. Protection starts by configuring your XML parser to completely disallow the fetching and processing of external DTDs. Additionally developers should enforce strict Content Security Policy headers on all SAML related requests. Implementing robust monitoring for unusual filesystem reads or unexpected network activity can provide early warning signs of an attempted breach. Utilizing modern patched libraries is the most effective way to stay ahead of these exploits.

Should engineering teams build or buy their SAML infrastructure?

Building a secure SAML stack requires navigating complex protocols managing encryption keys and maintaining observability infrastructure which consumes significant developer resources. The ongoing maintenance cost of auditing configurations and patching vulnerabilities adds further long term burden. Buying a solution like Scalekit allows teams to offload these security complexities to experts ensuring an enterprise ready posture without the upfront development overhead. This approach enables engineering managers to focus their talent on core product features rather than the intricate details of SAML security. Ultimately leveraging a dedicated provider reduces risk and accelerates the time to market.