Api Rate Abuse in Restify with Saml

Rate abuse in Restify when SAML authentication is used can allow an attacker to exhaust server-side resources by sending many authentication requests without being effectively throttled. This typically occurs when rate limiting is applied before authentication or is not enforced per SAML session or per identity provider (IdP) subject. Because SAML exchanges involve redirects and POST bindings at the endpoint, an unauthenticated attacker can repeatedly initiate login flows, triggering repeated parsing and validation of SAML responses.

In a black-box scan, middleBrick tests unauthenticated endpoints and checks whether rate limiting applies to the authentication path itself. If the SAML consumer endpoint (e.g., /saml/consume) lacks strict request caps, an attacker can induce high CPU usage due to XML parsing and signature validation, or cause session table exhaustion. This maps to the Authentication and Rate Limiting checks in the 12 security checks, and findings will highlight missing granular limits on SAML-related routes.

Consider a Restify service that uses passport-saml. Without per-session or per-NameID throttling, the same SAML response signature validation routine is invoked for each forged request. Because the scan tests the unauthenticated attack surface, middleBrick’s authentication check will note that the endpoint does not require credentials, while the rate limiting check will detect missing or coarse limits. The scanner also cross-references the OpenAPI spec if available; if the SAML endpoints are omitted or not annotated with rate-limit metadata, this gap is surfaced in the findings with remediation guidance to apply token-bucket or sliding-window controls specifically on the SAML assertion consumer path.

Real-world attack patterns include credential stuffing against IdP-provisioned identities or forcing repeated Single Logout requests to amplify server load. Because SAML often relies on redirects and POST bindings, attackers can craft loops that exploit missing origin/referer checks and incomplete session binding. The scanner’s authentication and rate limiting checks will surface these gaps, emphasizing the need to tie rate limits to SAML session identifiers or NameIDs rather than only IP addresses.

To mitigate rate abuse in Restify with SAML, apply strict, identity-aware throttling on SAML endpoints and ensure validation steps are bounded. Below are concrete steps and code examples aligned with how middleBrick reports findings and remediation guidance.

1. Apply rate limits on the SAML consumer route

Ensure the route that receives SAML responses has request caps per identity provider subject or per session. Use a sliding window or token bucket implementation that operates on a normalized identifier (e.g., NameID or in-session subject).

const restify = require('restify');
const rateLimit = require('rolling-rate-limiter');

// Define per-NameID rate limiter: 5 requests per 60 seconds
const nameIdLimiter = rateLimit({
  interval: 60 * 1000,
  maxInInterval: 5
});

const server = restify.createServer();
server.post('/saml/consume', (req, res, next) => {
  const subject = req.body.nameID; // extract SAML subject
  if (!subject) {
    return next(new restify.UnauthorizedError('Missing SAML subject'));
  }
  const allowed = nameIdLimiter(subject);
  if (!allowed) {
    return next(new restify.TooManyRequestsError('Rate limit exceeded for SAML subject'));
  }
  // proceed with SAML validation
  next();
});
server.listen(8080, () => console.log('SAML consumer listening on 8080'));

2. Enforce limits on the initiation endpoint as well

The SAML request initiation step (where the browser is redirected to the IdP) should also be bounded to prevent link-sharing abuse. Use IP-based limits combined with short-lived nonces to keep validation costs bounded.

const ipLimiter = rateLimit({
  interval: 60 * 1000,
  maxInInterval: 30
});

server.get('/saml/login', (req, res, next) => {
  const ip = req.ip;
  if (!ipLimiter(ip)) {
    return next(new restify.TooManyRequestsError('Too many login initiation requests'));
  }
  // generate request and redirect to IdP
  const nonce = crypto.randomBytes(16).toString('hex');
  req.session.nonce = nonce;
  const samlRequest = buildSamlRequest({ issuer: 'https://sp.example.com', nonce });
  res.redirect(302, 'https://idp.example.com/sso?' + qs.stringify({ SAMLRequest: samlRequest }));
  next();
});

3. Normalize identifiers and avoid unbounded session creation

Ensure that session or nonce storage does not grow indefinitely. Use short expirations and clean up entries after SAML response validation. middleBrick’s findings will often highlight missing bounds on such stateful operations during the Property Authorization and Data Exposure checks.

const sessions = new Map(); // in production, use a bounded LRU cache
server.post('/saml/consume', (req, res, next) => {
  const { SAMLResponse, RelayState } = req.body;
  const subject = extractNameIdFromResponse(SAMLResponse); // implement signature validation
  const key = subject;
  if (sessions.has(key)) {
    // already processed within expiry window; reject duplicate to prevent replay
    return next(new restify.ForbiddenError('Duplicate SAML response detected'));
  }
  sessions.set(key, { issued: Date.now() });
  setTimeout(() => sessions.delete(key), 5 * 60 * 1000); // cleanup after 5 minutes
  // continue auth flow
  res.redirect(RelayState || '/');
  next();
});

4. Align with compliance mappings referenced in findings

When configuring limits, reference frameworks mentioned in middleBrick findings such as OWASP API Top 10 and PCI-DSS. For example, OWASP API Top 10:2023 A5 – Security Misconfiguration often highlights missing rate limits on authentication flows. Use the dashboard and compliance reports available in the Pro plan to track remediation progress across SAML endpoints.