Container Escape in Sails with Bearer Tokens

A container escape in Sails (a Node.js MVC framework) occurs when a process running inside a container can break out and interact with the host or other containers. When Sails applications rely on Bearer Tokens for API authentication, the presence of these tokens can both enable and exacerbate an escape scenario. If an attacker gains the ability to execute code or control runtime behavior inside the container—through an input validation flaw, SSRF, or an unsafe plugin—they can read configuration files or environment sources that contain Bearer Tokens. Because Sails often stores sensitive credentials in environment variables or configuration files mounted into the container, a container escape can expose these Bearer Tokens. Exposed tokens may then be used to impersonate services, call privileged internal APIs, or access cloud provider metadata, leading to broader compromise.

In the context of the 12 security checks run by middleBrick, this scenario intersects multiple scan categories. Input Validation and Property Authorization checks look for paths that allow reading arbitrary files or environment variables. SSRF and Unsafe Consumption checks assess whether the application can be tricked into reaching internal endpoints that require Bearer Tokens. Data Exposure and Encryption checks determine whether tokens are transmitted or stored insecurely. The scan cross-references the OpenAPI specification to see whether securitySchemes of type http with bearerFormat are declared, and maps findings to OWASP API Top 10 and CWE categories such as CWE-532 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-918 (Server-Side Request Forgery). middleBrick does not fix these issues but provides prioritized findings with remediation guidance to help teams address the root causes.

Real-world Bearer Token patterns in Sails often appear in configuration and request code. For example, a Sails service might read a token from environment variables and use it when forwarding requests. If an attacker escapes the container and can read the environment or mounted secrets, these code patterns reveal exactly where the tokens reside and how they are used. The scanner’s OpenAPI/Swagger analysis (supporting 2.0, 3.0, and 3.1 with full $ref resolution) helps identify whether Bearer Token usage is properly scoped and whether sensitive endpoints lack proper authorization checks. By combining runtime findings with spec analysis, middleBrick highlights misconfigurations such as missing scopes, overly permissive routes, or missing security requirements that make token misuse easier during a container escape.

To reduce the risk of token exposure during a container escape, store Bearer Tokens outside of the container image and avoid committing them to source control. Use runtime injection via secrets management or environment variables that are not persisted in layers visible to attackers. In Sails, configure your application to read tokens securely at startup and ensure they are never logged or echoed. The following examples show secure patterns for Bearer Token usage in Sails controllers and services.

1) Securely read tokens from environment variables and use them in HTTP requests without exposing them in logs:

// api/services/ApiProxyService.js
const axios = require('axios');

module.exports = {
  async callExternalApi(endpoint) {
    const token = process.env.EXTERNAL_API_BEARER_TOKEN;
    if (!token) {
      throw new Error('Missing Bearer Token in environment');
    }
    try {
      const response = await axios.get(endpoint, {
        headers: {
          Authorization: `Bearer ${token}`,
          'Content-Type': 'application/json',
        },
        timeout: 5000,
      });
      return response.data;
    } catch (err) {
      // Avoid logging the token in error output
      sails.log.error('External API call failed:', err.message);
      throw err;
    }
  },
};

2) Enforce authorization checks before using a Bearer Token to access sensitive internal endpoints, preventing token misuse if an attacker escapes and gains runtime access:

// api/controllers/internal/UserDataController.js
module.exports = {
  async getInternalData(req, res) {
    // Authorize the request context, e.g., verify scope or role
    if (!req.user || !req.user.scopes.includes('internal:read')) {
      return res.unauthorized('Insufficient scope to access internal data');
    }
    const token = process.env.INTERNAL_SERVICE_TOKEN;
    if (!token) {
      return res.serverError('Internal service token not configured');
    }
    // Use token to call internal service securely
    // ... implementation omitted for brevity
    return res.ok({ data: 'protected resource' });
  },
};

3) Define security schemes in your OpenAPI spec so scanners and consumers understand the Bearer Token expectations. This does not prevent container escape but improves visibility and automated checks:

# openapi.yaml
openapi: 3.0.3
info:
  title: Sails API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List users
      security:
        - bearerAuth: []
      responses:
        '200':
          description: OK
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

These practices complement the checks provided by tools like middleBrick, which can identify whether your spec declares Bearer security schemes and whether runtime behavior risks exposing tokens. The free tier supports occasional scans to help surface these misconfigurations early.