Container Escape in Sails with Api Keys

A container escape in a Sails application that relies on API keys for authentication occurs when an attacker who obtains or manipulates an API key is able to move laterally out of the intended service boundary and interact with the host or other containers. Sails is an MVC framework for Node.js that typically exposes REST or WebSocket endpoints; if those endpoints authenticate only via static or weakly scoped API keys, the risk is that a compromised key grants more than intended, and the runtime environment (containers) may expose additional avenues for escape.

Container escape in this context does not mean Sails itself is bypassing container isolation; it means an attacker leverages an over‑privileged API key to reach an unintended surface—such as a debug endpoint, a management interface, or a shared volume—and from there interacts with the container runtime (for example, via exposed Docker sockets, metadata endpoints, or misconfigured service discovery). In a Sails app, this can happen when routes or policies trust API keys without also validating scope, origin, or intended resource boundaries. If the container host exposes Docker socket at /var/run/docker.sock or a management API, and an API key grants broad access to the app’s controllers, an attacker can enumerate host paths or trigger server-side request forgery that reaches the Docker API, leading to container escape.

Because middleBrick scans test unauthenticated attack surfaces and include checks such as BOLA/IDOR and BFLA/Privilege Escalation, it can surface endpoints that return sensitive data or allow overprivileged API key usage. In combination with input validation checks and SSRF tests, the scanner can detect whether API key–protected routes can be used to probe internal services or trigger actions that should be confined to the container. For instance, if a Sails controller uses an API key only to identify the client but does not enforce that the key limits access to specific resources, an SSRF or path traversal payload could be leveraged to reach the Docker daemon, effectively enabling container escape.

Real-world attack patterns that map to this risk include OWASP API Top 10:2023 Broken Object Level Authorization (BOLA) and Security Misconfiguration, and relevant CVEs often involve SSRF chains leading to Docker API abuse. The scanner’s LLM/AI Security checks are not required here, but the standard checks—Authentication, Input Validation, SSRF, and BFLA/Privilege Escalation—help identify conditions where an API key–based boundary is insufficient to prevent lateral movement within a containerized deployment.

Remediation centers on tightening how API keys are issued, validated, and scoped within Sails, and ensuring runtime container settings do not expose unnecessary surfaces. Below are concrete steps and code examples tailored to Sails v1.x.

• Enforce strict scoping and avoid a single key with broad permissions. Instead of using a global API key, generate per‑client keys that are tied to allowed resources or actions. Store keys securely (e.g., environment variables or a secrets manager) and reference them in config.
• Add key validation middleware and scope checks in policies so that each request verifies not only the presence of a key but also that the key has rights for the target route and HTTP method.
• Harden the container by not exposing the Docker socket to application containers, restricting outbound connections where possible, and ensuring no debug or admin endpoints are reachable without additional authentication.

Example Sails policy with API key scoping and route constraints:

// api/policies/keyScopePolicy.js
module.exports.keyScopePolicy = async function (req, res, next) {
  const apiKey = req.headers['x-api-key'];
  if (!apiKey) {
    return res.unauthorized('Missing API key');
  }

  // Fetch key details from a secure store; this example uses a static map for illustration
  const validKeys = {
    'client-read': { scopes: ['read:devices'], allowedPaths: ['/api/devices'] },
    'client-write': { scopes: ['write:devices'], allowedPaths: ['/api/devices'] },
  };

  const keyMeta = validKeys[apiKey];
  if (!keyMeta) {
    return res.forbidden('Invalid API key');
  }
  // Ensure the requested path is allowed for this key
  if (!keyMeta.allowedPaths.includes(req.path)) {
    return res.forbidden('API key not authorized for this endpoint');
  }
  // Optionally attach scope info to req for downstream policies/controllers
  req.scope = keyMeta.scopes;
  return next();
};

Example Sails route configuration using the scope policy and controller action that respects scopes:

// config/routes.js
module.exports.routes = {
  'GET /api/devices': {
    policy: ['keyScopePolicy'],
    controller: 'DeviceController.list',
  },
  'POST /api/devices': {
    policy: ['keyScopePolicy'],
    controller: 'DeviceController.create',
  },
};

Example controller that checks scope before proceeding:

// api/controllers/DeviceController.js
module.exports = {
  async list(req, res) {
    if (!req.scope || !req.scope.includes('read:devices')) {
      return res.forbidden('Insufficient scope for listing devices');
    }

    const devices = await Device.find();
    return res.ok(devices);
  },

  async create(req, res) {
    if (!req.scope || !req.scope.includes('write:devices')) {
      return res.forbidden('Insufficient scope for creating devices');
    }
    const deviceData = req.allParams();
    const device = await Device.create(deviceData).fetch();
    return res.created(device);
  },
};

In addition to code-level fixes, integrate middleBrick to validate these controls. Use the CLI to scan from terminal with middlebrick scan <url> or add the GitHub Action to perform API security checks in your CI/CD pipeline, failing builds if risk scores drop below your chosen threshold. For continuous monitoring, the Pro plan supports configurable scanning schedules and alerts, which can help detect regressions in key handling or exposed endpoints over time.