Api Key Exposure in Loopback with Saml

When a Loopback application uses SAML for authentication but also exposes an API key–based mechanism (for example, a service-to-service endpoint or a legacy route), the combination can inadvertently expose secrets and create authorization bypass paths. SAML itself is a protocol that carries assertions via signed SAML tokens, but many Loopback apps add API keys as a lightweight authorization layer for non–browser clients. If the API key is passed in headers, query parameters, or logs alongside SAML-based flows, and if route or model ACLs are not consistently enforced, an attacker may learn or reuse the key through misconfigured endpoints or insecure error messages.

Consider a Loopback model configured with a mix of SAML identity and API key checks where the key is expected in an HTTP header like x-api-key. If the endpoint lacks proper authentication middleware ordering, or if a binding like remoteMethod exposes the key in debug output or error traces, a disclosure can occur. For example, an unauthenticated SSRF or insecure reflection endpoint might echo the key in responses, or an over-permissive CORS setup might allow a browser-based attacker to capture the key via a crafted SAML response or a preflight request. Even when SAML assertions are validated, the API key may be accepted as a fallback, reducing the effective security boundary and enabling privilege escalation via BOLA/IDOR when the key maps to a specific tenant or user.

Another scenario involves OpenAPI/Swagger definitions in Loopback where the x-api-key security scheme is declared but not consistently applied. If the spec advertises the key as a bearer-like credential and runtime routes do not enforce strict scope checks, scanning tools can detect mismatches between declared authentication and actual enforcement. This mismatch can surface as a finding in the Authentication or Property Authorization checks, indicating that an API key intended for internal use may be reachable without proper SAML context. Such findings often map to OWASP API Top 10:2023 A07 — Identification and Authentication Failures, and may intersect with compliance frameworks when keys are considered secrets subject to PCI-DSS or SOC2 controls.

In addition to misconfiguration, the risk can be amplified by logging practices. If Loopback logs incoming headers for observability and the x-api-key header is captured in plaintext, the key can be exfiltrated through log aggregation systems or error pages. MiddleBrick’s scans include Data Exposure checks that flag sensitive data in responses and can surface indicators that API keys are being transmitted or reflected insecurely when SAML flows are active. Since the scanner runs unauthenticated, it can probe endpoints that should require both SAML and an API key, revealing gaps where one factor is accepted in place of the other.

Overall, the interaction between Loopback, SAML, and API keys is risky when authorization logic is fragmented or when keys are accepted without re-verifying the SAML context. The presence of an API key should not weaken the SAML-protected surface; instead, both factors should be required and validated in a coordinated manner. Continuous scanning with a tool like MiddleBrick can highlight these inconsistencies through its Authentication and Property Authorization checks, providing prioritized findings and remediation guidance before real-world abuse occurs.

To remediate Api Key Exposure when using SAML in Loopback, enforce strict authentication ordering, avoid mixing API keys as a fallback, and ensure that every route and model enforces SAML assertions consistently. Below are concrete code examples that demonstrate secure patterns.

First, configure the SAML strategy so that it is the primary authentication mechanism and ensure that the API key is not accepted as an alternative. In server.js or an initializer, set up the passport-based SAML flow without exposing key-based shortcuts for sensitive operations:

// server.js or config/bootstrap.js
const samlStrategy = require('passport-saml').Strategy;
const passport = require('passport');
module.exports = function(app) {
  app.use(passport.initialize());
  passport.use(new samlStrategy({
    entryPoint: 'https://idp.example.com/sso',
    issuer: 'https://app.example.com',
    cert: process.env.SAML_CERT,
    callbackUrl: 'https://app.example.com/saml/consume'
  }, (profile, done) => {
    // Map SAML attributes to a user identity
    return done(null, profile);
  }));
};

Second, secure Loopback models and remote methods by requiring SAML-derived identities and explicitly rejecting requests that rely solely on an API key. Use a custom middleware or operation hook to validate the presence of a valid SAML context before allowing access:

// common/middleware/require-saml.js
module.exports = function requireSaml(ctx, options, next) {
  if (!ctx.req.user || !ctx.req.user.samlAuthenticated) {
    return next(new Error('Authentication required: SAML assertion missing'));
  }
  // Optionally verify scope/roles from the assertion
  if (!ctx.req.user.can('read', 'SensitiveModel')) {
    return next(new Error('Insufficient permissions'));
  }
  return next();
};

Then apply this middleware to models or methods in model.json or programmatically:

// common/models/sensitive-model.json
{
  "name": "SensitiveModel",
  "base": "PersistedModel",
  "acls": [
    {"principalType": "ROLE", "principalId": "$everyone", "permission": "DENY"}
  ],
  "methods": {
    "findSensitive": {
      "accepts": {"arg": "filter", "type": "object", "http": {"source": "query"}},
      "returns": {"arg": "data", "type": "array", "root": true},
      "http": {"path": "/find-sensitive", "verb": "get"}
    }
  }
}

// server/boot/routes.js
const app = require('./app');
app.models.SensitiveModel.beforeRemote('findSensitive', requireSaml);
// Do not register API-key-only fallback for this method

Third, if you must support API keys for legacy clients, treat them as a secondary factor that is checked only after SAML authentication and only for scoped operations. Avoid exposing the key in URLs or logs, and use environment variables with strict rotation:

// server/boot/api-key-check.js
module.exports = function apiKeyCheck(err, req, res, next) {
  const apiKey = req.headers['x-api-key'];
  if (!apiKey) return next();
  if (!req.user) return res.status(401).json({error: 'SAML authentication required before API key check'});
  if (!isValidKeyForUser(apiKey, req.user)) {
    return res.status(403).json({error: 'Invalid API key for user context'});
  }
  return next();
};

function isValidKeyForUser(key, user) {
  // Validate against a scoped key store, e.g., a model mapping userId to hashed keys
  return user.apiKeys && user.apiKeys.includes(hash(key));
}

Finally, ensure that error messages and logs do not leak the API key. Sanitize outputs and configure Loopback’s error handler to mask sensitive headers:

// server/middleware.json
{
  "initializers": {
    "errorHandler": {
      "params": {"disableStackTrace": true}
    }
  },
  "rootMiddleware": {
    "logRequest": {
      "params": {
        "except": ["/saml/consume"],
        "maskHeaders": ["x-api-key"]
      }
    }
  }
}

These steps align with OWASP API Top 10 and help ensure that SAML remains the primary authentication factor while API keys, if retained, are scoped, validated, and protected from exposure.