Introducing SAML Shield: open source protection for SAML CVEs

Today, we’re thrilled to launch SAML Shield, a simple way to secure every SAML-based service your team uses. Never worry about waiting weeks or months on an upstream maintainer or service provider to patch a SAML Common Vulnerability and Exposure (CVE) again. Protection is instant.

SAML Shield works out of the box with proxies like Nginx, Envoy, or Istio and any Assertion Consumer Service (ACS) endpoint through either our easy to use API or self-hosted OSS offering. Getting started is as simple as an API call or NPM install to deploy SAML Shield for comprehensive protections against CVEs and common vulnerability patterns, using regularly updated SAML-specific security rules.

The broken state of SAML security

It’s the on-call message no engineer ever wants to wake up to. You check your SAML implementation, sure enough the library you use is vulnerable and you need to upgrade to the patched version. But what about the apps you use internally that are accessed via SAML? You scan the vendor changelogs, and realize half of your SAML apps are vulnerable and haven't been patched yet. You're stuck waiting on their teams to implement the same patch. Meanwhile, the vulnerability is live and being actively exploited.

SAML security is inherently fragile due to its foundation on XML, leading to consistent patterns of vulnerabilities across various implementations and libraries. These vulnerabilities often arise not from negligence, but from the inherent difficulty of correctly implementing a spec as open-ended and inconsistent as SAML. Attackers will use the same methods between different libraries, moving onto the next one after the exploit has been patched in the original target. Some of the common methods used include:

• Signature Wrapping Attacks (XSW): Where attackers inject malicious assertions and exploit the library's incorrect validation of a legitimate signature elsewhere in the document.
• XML External Entity (XXE) vulnerabilities: Exploiting how XML parsers process external entities, leading to information disclosure, denial of service, or remote code execution.
• Replay Attacks: Where legitimate SAML responses are intercepted and reused by attackers to gain unauthorized access.

These vulnerabilities repeatedly emerge across different SAML libraries (e.g., ruby-saml, PySAML2, node-saml, etc.) and platforms.

What makes this worse is that typical patch cycles for vulnerabilities like these are often weeks long, sometimes months. Every minute waiting for a vendor patch is time attackers can spend exploiting the flaw, and this story is unfortunately common in the lifecycle of mitigating critical SAML vulnerabilities (which it turns out are quite common).

A recent real world example & inspiration

At Stytch, we recently encountered a vulnerability in our own service stemming from the open-source SAML library we use. While we patched our service promptly when we received a responsible disclosure from a security researcher, anyone else relying on the same SAML library remained exposed, waiting on a single, overburdened volunteer maintainer to release an official patch. As is the case with many OSS libraries, SAML libraries are often maintained by one, maybe a couple, engineers whose work is incredibly valuable to keeping the ecosystem running.

As a Customer Identity and Access Management (CIAM) provider, we see this issue repeatedly across engineering teams. SAML remains the de facto standard for enterprise SSO, but its foundation in XML makes it fragile and complex to keep secure. Most teams don’t own the SAML stack—they inherit it through internal services, legacy systems, or third-party tools.

To protect our own infrastructure at Stytch, we built a hardened SAML layer with aggressive isolation: compute, network, and permissions are fully sandboxed. It guards against XML-based exploits like signature wrapping and RCE.

As we’ve seen countless critical SAML vulnerabilities become public, we’ve been able to promptly patch those issues in our internal SAML service and protect customers rather than waiting on upstream maintainers.

This protects Stytch customers automatically, but we saw an opportunity to decouple this core infrastructure and provide other teams using SAML the same protection, even if they aren’t using Stytch for auth. This means you can easily add an extra layer of protection to help shield against SAML vulnerabilities with defense in depth, the perfect complement to any existing SAML implementation or library.

Introducing SAML Shield: Hardened SAML protection with 1 API call

SAML Shield is a linter that provides robust protection for SAML vulnerabilities without forcing anyone to upgrade software, migrate customer SAML connections, or rewrite code.

Whether you run your own SAML stack or depend on third-party tools, SAML Shield acts as a drop-in layer that inspects, validates, and blocks malicious SAML Responses in real time before they are processed by your SAML library.

Here’s how it works:

Step 1: Deploy (pick your flavor)

Option A: API Mode

SAML Shield currently supports SDKs for Python and Node.js. For other language support, SAML Shield can be called via HTTP API using curl or any HTTP client.

Here’s how integrating SAML Shield in Node.js is done:

// npm install stytch
const stytch = require("stytch");
const client = new stytch.SamlShieldClient({
  // Retrieved from SAML Shield Dashboard
  public_token: "public-token-live-x0xxx000-1x11-0x0x-0000-x00x0x000x00",
})
const params = {
  SAMLResponse: req.body.SAMLResponse, // Base64 encoded SAML Response
};
client.saml.validate(params)
.then(resp => { console.log(resp) })
.catch(err => { console.log(err) });

Option B: Proxy Mode (nginx, Istio, Envoy)

Follow the instructions for the proxy you are using. This option is best for when you want to protect applications that you don’t control, such as 3rd-party platforms or apps. Here’s how the flow will look:

Adding SAMLshield to your nginx config is then done by a lua file, which can be referenced as such:

local http = require "resty.http"
-- Define the SAML Shield API endpoint and token
local samlshield_url = "https://api.samlshield.com/v1/saml/validate"
# retrieved from SAML Shield Dashboard
local bearer_token = "Bearer public-token-live-x0xxx000-1x11-0x0x-0000-x00x0x000x00"
-- Only check on the ACS endpoint
if ngx.var.request_uri == "/saml/callback" then
  local httpc = http.new()
  httpc:set_timeout(3000) -- 3 seconds timeout
  -- Read request body
  ngx.req.read_body()
  local body = ngx.req.get_body_data()
  local res, err = httpc:request_uri(samlshield_url, {
      method = "POST",
      body = body,
      headers = {
          ["Authorization"] = bearer_token,
          ["Content-Type"] = ngx.req.get_headers()["Content-Type"],
      }
  })
  if not res or not  then
      ngx.log(ngx.ERR, "Failed to connect to SAML Shield: ", err)
      return ngx.exit(ngx.HTTP_FORBIDDEN)
  end

  if res.status ~= 200 then
      ngx.log(ngx.WARN, "SAML Shield rejected request with status: ", res.status)
      return ngx.exit(ngx.HTTP_FORBIDDEN)
  end

end

Option C: Open Source

If you prefer a self-hosted solution, SAML Shield’s open-source Node.js library lets you validate SAML responses locally, directly within your authentication flow. It gives you full control over how and where validation happens without calling external servers.

Here's an example of what integration looks like:

// npm install @stytch/samlshield
import { validateSAMLResponse } from "@stytch/samlshield";

// Basic usage - throws errors on validation failure
try {
  await validateSAMLResponse({
      response_xml: req.body.SAMLResponse, // Base64 encoded SAML Response
  });
  console.log("SAML response is valid!");
} catch (error) {
  console.error("SAML validation failed:", error.message);
}

Read the documentation for in depth instructions to set up SAML Shield’s OSS offering.

Step 2: Instant Hard-Validation

Every assertion is checked rigorously against known exploit patterns and validation flaws including the common ones mentioned above. We update these rules continuously, pushing protections live within hours of new vulnerabilities appearing.

Note: If you’re using the OSS version, you will still need to manually update the NPM package, as is customary for self-hosted solutions.

When the last SAML CVE hit, we didn’t lose a sprint, or a minute of sleep. SAML Shield blocked the exploit before it ever reached us, and now we can drop that same protection in front of any app, even ones we don’t control.
— Kshitij Grover, Co-Founder and CTO at Orb

FAQ

• Who is SAML Shield for?
  • Security, platform, and infrastructure teams that need to protect against SAML vulnerabilities—especially when they don’t own or control every app in their environment.
• Does SAML Shield validate signatures?
  • No—SAML Shield does not perform cryptographic signature validation. Instead, it focuses on structural and protocol-level validation to catch malformed assertions, protocol abuse, and known attack patterns before they reach your service provider.
  • You should continue relying on your SAML library or identity provider for signature verification. SAML Shield is designed to complement, not replace, signature validation by enforcing strict protocol checks at the edge.
• How does it compare to patching upstream libraries?
  • SAML Shield doesn’t wait for upstream maintainers to ship fixes. It inspects and blocks malicious assertions at runtime, giving you zero-day protection even for unpatched or third-party services.
• How hard is it to integrate?
  • Most teams get it running in under 30 minutes. You can deploy as a sidecar with Envoy/Istio or use a one-line API call in front of your SAML apps.
• What happens when a new CVE drops?
  • We update our rules within 24 hours—often faster. Your services stay protected with no code changes and no app restarts.
• Can we use it with software we didn’t build (like ArgoCD or Elastic)?
  • Yes. That’s one of SAML Shield’s superpowers—you can wrap legacy or third-party apps with zero rewrites.
• What if we want to test before enforcing?
  • No problem. Begin by observing the logs for suspicious assertions before enforcing the verdicts in your validation logic.
• Do we need to send you sensitive data or signing keys?
  • No, SAMLShield does not require signing keys or other sensitive authentication credentials. The library only needs access to the base64-encoded SAML response XML that your application receives during the authentication flow.
  • While SAMLShield does process the SAML assertion content for validation (checking structure, signatures, and security vulnerabilities), it does not store or persist any of this data. The validation happens entirely in-memory and the data is discarded after processing.
• Will SAML Shield disrupt our current flows?
  • No. It's passive by default until it detects malicious assertions.
• What is SAML Shield’s impact on latency?
  • We have found that latency sits around 100-200ms on average, though your mileage may vary, with no noticeable differences per integration method.
• What does this cost?
  • SAML Shield has a permanent free tier with 500 SAML responses per month, and usage beyond that is just $0.10 per response with no minimums or lock-in. Enterprise plans offer volume discounts and SLAs, and the first two months after launch are completely free. The open-source version is always free; see our pricing page for full details.

Conclusion

SAML vulnerabilities aren't slowing down, but with SAML Shield, protecting against them doesn't have to be a frantic scramble. Stop playing whack-a-mole with vulnerabilities, and get comprehensive protection against entire classes of vulnerabilities with SAML Shield. Want to get involved? Star the Github repo and start contributing.

Ready to secure your use of SAML? Contact us to try SAML Shield today.