HIGH adonisjsssrf cloud metadata

Ssrf Cloud Metadata in Adonisjs

How SSRF Cloud Metadata Manifests in Adonisjs

Server-side request forgery (SSRF) via cloud metadata endpoints remains a high-risk attack vector when APIs expose internal cloud metadata services without proper authorization checks. In AdonisJS applications, this risk intensifies when developers integrate tightly with cloud providers like AWS, Azure, or GCP and expose metadata endpoints through internal services, reverse proxies, or third-party integrations.

AdonisJS applications often run in containerized or serverless environments where services make outbound HTTP requests to cloud metadata URLs (e.g., http://169.254.169.254/latest/meta-data/ on AWS EC2). If an API endpoint accepts user-supplied URLs or parameters that are used to fetch external resources, and those resources include cloud metadata, the application may inadvertently expose sensitive internal data. For example, an endpoint that allows users to fetch configuration from a remote service may be tricked into retrieving metadata endpoints that return IAM roles, security credentials, or instance identities.

In practice, SSRF via cloud metadata often arises when:

  • An API endpoint processes user-supplied URLs for downloading templates, images, or configuration files.
  • Internal services make HTTP requests based on user-controlled inputs without validation.
  • AdonisJS route handlers use dynamic request generation without restricting outbound destinations.

Because cloud metadata services typically run on link-local IPs like 169.254.169.254 (AWS) or 169.254.168.1 (Azure), and respond to basic HTTP GET requests, attackers can probe these addresses directly if they are reachable from within the application's network context. If an AdonisJS application makes outbound requests to such addresses based on untrusted input, it may leak credentials or allow lateral movement within the cloud environment.

Real-world attack patterns include fetching /latest/meta-data/iam/security-credentials/ on AWS to retrieve temporary credentials, or accessing /latest/meta-data/ to enumerate available metadata keys. These endpoints often do not require authentication when accessed from within the VM, making them prime targets for SSRF exploitation if the application acts as a proxy for user-controlled content.

AdonisJS does not inherently block these requests — it is the developer's responsibility to validate and restrict outbound HTTP destinations. Without proper input sanitization or network egress controls, cloud metadata SSRF can lead to credential leakage, data exfiltration, or privilege escalation within the cloud tenant.

Adonisjs-Specific Detection

Detecting SSRF vulnerabilities related to cloud metadata in AdonisJS applications requires both code-level scrutiny and runtime scanning of exposed attack surfaces. MiddleBrick identifies SSRF risks by analyzing HTTP request paths that originate from user-controllable inputs and target known cloud metadata IP ranges or metadata endpoints.

For example, consider an AdonisJS route that allows users to specify a remote configuration URL:

const Route = use('Route');

Route.get('/config', 'ConfigController.fetch').middleware('auth');

// In ConfigController.js
const axios = require('axios');

class ConfigController {
  async fetch ({ request }) {
    const url = request.input('url');
    const response = await axios.get(url);
    return response.data;
  }
}

This code is vulnerable if url can be set to http://169.254.169.254/latest/meta-data/iam/security-credentials/. MiddleBrick detects such patterns by scanning for:

  • Use of dynamic URLs from user input in axios.get(), fetch(), or http.request() calls.
  • Requests directed toward known cloud metadata IP ranges (e.g., 169.254.0.0/16 for AWS, 169.254.168.0/24 for Azure).
  • Endpoints that match metadata paths like /latest/meta-data/ or /openstack/latest/meta-data/.

MiddleBrick performs black-box scanning of your AdonisJS endpoints by sending crafted requests that probe for SSRF via metadata URLs. If an endpoint returns a successful response when querying http://169.254.169.254/latest/meta-data/iam/security-credentials/, MiddleBrick flags this as a high-severity SSRF finding with a detailed report including:

  • Request path used
  • Response snippet showing metadata access
  • Severity rating (A–F)
  • Remediation guidance specific to AdonisJS

Because MiddleBrick performs 12 parallel security checks — including SSRF detection across 150+ cloud metadata patterns — it can identify these risks without requiring authentication, configuration files, or source code access. Simply provide the public URL of your AdonisJS API endpoint, and MiddleBrick will test for unauthorized access to cloud metadata endpoints in under 15 seconds.

Adonisjs-Specific Remediation

Remediation of SSRF vulnerabilities related to cloud metadata in AdonisJS applications requires strict input validation and network egress control. Developers should never allow user-supplied URLs to influence outbound HTTP requests without rigorous validation.

Here is a secure implementation using AdonisJS's request handling and URL parsing:

const axios = require('axios');
const allowedHosts = ['config.example.com', 'api.trusted-service.internal'];

class ConfigController {
  async fetch ({ request }) {
    const url = request.input('url');
    try {
      const parsedUrl = new URL(url);
      if (!allowedHosts.includes(parsedUrl.hostname)) {
        throw new Error('Unauthorized host');
      }
      const response = await axios.get(url, { timeout: 5000 });
      return response.data;
    } catch (error) {
      return { error: 'Invalid or unauthorized URL' };
    }
  }
}

This approach ensures that only pre-approved hosts can be accessed, blocking attempts to reach private IP ranges like 169.254.169.254. Additionally, developers can disable outbound access to metadata endpoints entirely by configuring cloud provider metadata accessibility settings (e.g., disabling instance metadata service in AWS) or using VPC endpoint policies.

AdonisJS applications can also use middleware to block private IP ranges at the HTTP client level:

const isPrivateIp = (host) => {
  return /^10\.|^192\.168\.|^172\.(1[6-9]|2[0-9]|3[0-1])\.|^127\.|^169\.254\./.test(host);
};

// In a middleware or request interceptor
if (isPrivateIp(parsedUrl.hostname)) {
  return response.reject(403, 'Access to private IP ranges denied');
}

Furthermore, sensitive metadata endpoints should not be exposed to applications that do not require them. When using AdonisJS with Docker or cloud platforms, ensure that metadata endpoints are only accessible from trusted internal services and not from API gateways handling user requests.

By combining input validation, allowlists, and network policies, AdonisJS applications can mitigate SSRF risks associated with cloud metadata exposure. MiddleBrick validates these controls during scanning and confirms whether remediation is effective.

Frequently Asked Questions

Can MiddleBrick detect SSRF in AdonisJS apps without access to source code?
Yes. MiddleBrick performs black-box scanning of your deployed AdonisJS API endpoints. It sends crafted HTTP requests to test for unauthorized access to cloud metadata endpoints like AWS 169.254.169.254 or Azure 169.254.168.1. If an endpoint returns data from these addresses based on user-controllable inputs, MiddleBrick flags it as a high-severity SSRF finding in its report.
Does fixing the SSRF issue require changes to AdonisJS middleware?
Not necessarily middleware — prevention focuses on input validation and network controls. You should validate and sanitize any user-supplied URLs before using them in HTTP requests. Use URL parsing, allowlists for known hosts, and block private IP ranges. MiddleBrick helps verify whether these controls are in place by testing your endpoints after changes.