Api Key Exposure in Strapi with Saml

When Strapi is configured to use SAML for identity federation, an API key exposure risk can arise if the service provider (SP) metadata or integration settings inadvertently expose long-lived credentials or secrets. In a typical SAML flow, Strapi acts as the service provider and relies on an identity provider (IdP) to assert user identity. Misconfiguration—such as placing a shared API key or signing secret in metadata files, environment variables that are logged, or in JavaScript bundles—can allow an unauthenticated attacker who discovers these artifacts to impersonate services or escalate privileges.

Consider a Strapi instance that exposes its SAML metadata endpoint publicly. The metadata may contain an X.509 certificate or a signing key intended only for backend SAML processing. If an API key—used here as a stand-in for any backend integration secret, such as a shared token or a service credential—is stored alongside SAML settings and accidentally exposed through debug endpoints, source control, or insecure deployment artifacts, an attacker can reuse it to call other protected APIs that rely on the same credential for authorization. This compounds the SAML misconfiguration by turning a federated identity setup into a vector for unauthorized API access.

For example, a Strapi application might define SAML settings in a configuration file that also includes an API key for a third-party service. If an attacker runs a middleBrick scan on the public Strapi endpoint, one of the 12 parallel checks—Property Authorization and Data Exposure—can detect that metadata or configuration endpoints reveal sensitive artifacts. The scanner cross-references the OpenAPI spec (if available) with runtime responses and may find that GET /admin/config returns a JSON structure containing a key labeled externalApiKey. Even though the SAML flow itself is separate, the presence of this key in the same runtime context means that compromising the exposed configuration yields both identity federation confusion and direct API access, bypassing intended isolation between identity and resource layers.

Real-world patterns include the use of certificate-based signing without proper key protection, or the inclusion of secrets in package.json or build outputs that are served statically. middleBrick’s LLM/AI Security checks do not apply here, but its unauthenticated black-box scanning does surface these classes of risk: the scanner tests for unauthenticated access to admin panels, metadata endpoints, and configuration routes, then maps findings to frameworks like OWASP API Top 10 and PCI-DSS to prioritize remediation.

Using the middleBrick CLI, you can verify your setup by running middlebrick scan https://your-strapi.example.com. The tool returns a letter grade and a finding such as Data Exposure: API Key in Metadata, with remediation guidance to move secrets to a secure vault, restrict admin endpoints to authenticated access, and ensure SAML metadata does not contain or reference long-lived tokens.

Remediation focuses on isolating SAML configuration from any API key usage, tightening access to metadata, and ensuring secrets are never stored in code or exposed via endpoints. Below are concrete steps and code examples you can apply in Strapi.

1. Separate SAML configuration from API keys

Do not store third-party API keys in the same configuration files that contain SAML settings. Use environment variables with strict scopes and avoid logging them.

// config/server.js
module.exports = ({ env }) => ({
  host: env('HOST', '0.0.0.0'),
  port: env.int('PORT', 1337),
  // SAML settings isolated from external API keys
  saml: {
    entityID: env('SAML_ENTITY_ID', 'https://your-strapi.example.com/saml/metadata'),
    entryPoint: env('SAML_ENTRY_POINT'),
    cert: env('SAML_CERT'),
  },
  // External API keys kept separate and injected only where needed
  external: {
    apiKey: env('EXTERNAL_API_KEY'),
  },
});

2. Protect metadata endpoints

If your Strapi instance exposes SAML metadata, ensure the endpoint is not publicly accessible unless required. Use route-level policies to restrict who can fetch metadata.

// src/api/saml/config/routes.json
{
  "routes": [
    {
      "method": "GET",
      "path": "/saml/metadata",
      "handler": "saml.metadata",
      "config": {
        "policies": ["admin"]
      }
    }
  ]
}

3. Use certificate-based signing and avoid storing private keys in source

Generate and manage signing certificates outside of your codebase. Reference them via environment variables and ensure file permissions are restrictive on the host.

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://your-strapi.example.com/saml/metadata"
    validUntil="2026-01-01T00:00:00Z"
    >
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIC...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        Location="https://idp.example.com/sso"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

4. Validate audience and recipient in SAML responses

Ensure Strapi validates the Audience and Recipient conditions in SAML responses to prevent token misuse across services.

// src/api/saml/controllers/saml.js
module.exports = {
  samlResponse: async (ctx) => {
    const samlResponse = ctx.request.body.SAMLResponse;
    const decoded = validateSamlAudience(samlResponse, process.env.SAML_AUDIENCE);
    if (!decoded) {
      ctx.throw(400, 'Invalid audience');
    }
    // proceed with login
  },
};

5. Audit and rotate secrets

Regularly rotate any external API keys and review access logs. Use the middleBrick dashboard to track changes to your Strapi endpoints over time and detect new exposures early.

By isolating SAML configuration from API keys, restricting metadata access, and validating SAML responses, you reduce the chance that a misconfiguration leads to unauthorized API access. middleBrick scans can confirm that metadata endpoints do not leak secrets and that admin panels are not publicly accessible.