Container Escape in Express with Bearer Tokens

A container escape in an Express API that uses Bearer tokens occurs when an attacker who obtains or manipulates a token can move beyond the intended request-scope and interact with the host system, container runtime, or other containers. This typically maps to the BFLA/Privilege Escalation and SSRF checks in middleBrick’s scan, because the issue arises from insufficient authorization around token usage and unchecked network interactions from the API.

Express apps often rely on Bearer tokens for authentication and to gate routes. If authorization checks are incomplete, an attacker can leverage a low-privilege token to call administrative routes, access internal services, or trigger metadata endpoints that lead to container escape. For example, an endpoint that accepts a token but does not re-validate scope or role may allow horizontal privilege escalation: one user’s token is used to reach another user’s data or an admin route. A more severe variant involves server-side request forgery induced by the app making requests from inside the container using the same token, reaching the container metadata service at http://169.254.169.254 on cloud environments.

Consider an Express route that trusts a Bearer token without verifying its scopes or binding to the correct user identity. An attacker could copy a valid token from a legitimate client, then craft requests to internal endpoints that perform file operations or invoke container runtime APIs. If the app runs with elevated capabilities inside the container (e.g., mounting the Docker socket at /var/run/docker.sock), a compromised token can lead to container escape via the Docker API. middleBrick’s BFLA/Privilege Escalation and SSRF checks surface such risky endpoints by correlating OpenAPI definitions with runtime behavior, identifying routes that accept Bearer tokens yet lack proper authorization and can reach internal or sensitive targets.

Insecure deserialization or unsafe consumption of user-supplied data combined with Bearer token usage can further widen the attack surface. For instance, an endpoint that parses the token payload without strict validation may be tricked into escalating privileges or leaking internal service URLs. The presence of untrusted input and overly permissive route handlers enables attackers to exploit the token to probe internal networks, leading to data exposure or SSRF that can culminate in container escape.

middleBrick’s LLM/AI Security checks are not directly aimed at container escape, but they detect system prompt leakage and jailbreak attempts that could be used alongside API exploits to manipulate AI components of the service. By scanning unauthenticated attack surfaces and running checks in parallel, middleBrick provides per-category breakdowns and prioritized findings with remediation guidance, helping teams identify weak authorization around Bearer tokens and risky network paths before an escape path is exploited.

Remediation focuses on strict token validation, scope-based authorization, and avoiding internal network calls when a Bearer token is present. Below are concrete Express examples that demonstrate insecure patterns and their secure fixes.

Insecure Example: Trusting the Token Without Scope Validation

// BAD: No scope or role check
app.get('/admin/users', (req, res) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).send('Unauthorized');
  }
  const token = auth.split(' ')[1];
  // Verify token signature and extract payload (simplified)
  const payload = verifyToken(token); // hypothetical verify
  // Missing: ensure payload.scope includes 'admin' or similar
  const users = db.getAllUsers();
  res.json(users);
});

Secure Example: Validate Token and Enforce Scope-Based Authorization

// GOOD: Validate token and enforce scope
app.get('/admin/users', (req, res) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).send('Unauthorized');
  }
  const token = auth.split(' ')[1];
  let payload;
  try {
    payload = verifyToken(token); // returns { sub, scope, role }
  } catch (err) {
    return res.status(401).send('Invalid token');
  }
  if (!payload.scope || !payload.scope.split(' ').includes('admin:users')) {
    return res.status(403).send('Insufficient scope');
  }
  const users = db.getAllUsers();
  res.json(users);
});

Avoid Using Token to Call Internal Services Unconditionally

Do not use the same Bearer token to call internal metadata or container runtime endpoints. If you must call internal services, use a separate service identity and never forward the client token.

// BAD: Forwarding client token to internal service
app.get('/reports', (req, res) => {
  const token = extractToken(req);
  axios.get('http://169.254.169.254/metadata/identity/oauth2/token', {
    headers: { Authorization: `Bearer ${token}` }
  }).then(r => { /* risky */ });
});

// GOOD: Use a server-side credential and do not forward client token
const INTERNAL_TOKEN = process.env.INTERNAL_TOKEN; // managed secret
app.get('/reports', async (req, res) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).send('Unauthorized');
  }
  // Validate and authorize the request token first
  const payload = verifyToken(auth.split(' ')[1]);
  if (!hasPermission(payload, 'view_reports')) {
    return res.status(403).send('Forbidden');
  }
  try {
    const response = await axios.get('http://internal-service/report', {
      headers: { Authorization: `Bearer ${INTERNAL_TOKEN}` }
    });
    res.json(response.data);
  } catch (err) {
    res.status(500).send('Internal error');
  }
});

Additional Hardening Practices

• Always verify token signatures and enforce audience and issuer claims.
• Apply least privilege: assign minimal scopes per route and validate them server-side.
• Do not mount sensitive sockets (e.g., Docker socket) in containers that serve user-facing APIs.
• Use network policies to restrict outbound calls from containers, especially to metadata endpoints.
• Log and monitor token usage anomalies to detect token replay or abuse.

middleBrick’s CLI tool can be used to scan endpoints from the terminal: middlebrick scan <url>. The GitHub Action adds API security checks to your CI/CD pipeline, failing builds if risk scores drop below your chosen threshold. For continuous monitoring, the Pro plan supports configurable scans and alerts, while the Dashboard lets you track security scores over time.