Ssrf Server Side in Feathersjs with Basic Auth

Server-side request forgery (SSRF) in a FeathersJS application that uses Basic Authentication can occur when user-supplied input is used to construct HTTP requests to arbitrary hosts. FeathersJS services often integrate with external APIs or fetch resources on behalf of clients. If an endpoint accepts a URL or host configuration from an attacker and then performs an outbound HTTP call without strict validation, SSRF can be triggered. Basic Auth compounds the risk because credentials may be embedded in the request or reused across internal and external calls, potentially exposing secrets to an internal attacker who forces the server to reach an unintended internal service.

Consider a Feathers service that retrieves a remote resource based on a user-provided URL. Without proper allowlisting, an attacker can supply an internal address such as http://169.169.169.254/latest/meta-data/iam/security-credentials/ (AWS instance metadata) or http://redis:6379 (internal Redis). If the Feathers service adds Basic Auth headers to these outbound calls using credentials supplied or configured at runtime, an attacker may learn whether the backend responds differently based on auth presence, or exfiltrate data via a malicious internal endpoint that leaks credentials in logs or responses. The OpenAPI spec analysis integrated by middleBrick helps surface such risky integrations by correlating runtime calls defined in the spec with observed behavior, revealing endpoints that perform outbound HTTP operations without sufficient input validation.

The combination of SSRF and Basic Auth is particularly dangerous when the same credentials are reused across internal services or when authentication logic is handled inconsistently across Feathers hooks. For example, a before hook might attach an Authorization header derived from request parameters to an HTTP client used for downstream calls. If an attacker can control the destination URL, they can coerce the server into authenticating to an internal service and capturing or relaying credentials. middleBrick’s LLM/AI Security checks include active prompt injection testing and system prompt leakage detection, but for API security, the scanner’s 12 parallel checks—such as Input Validation, Property Authorization, and Unsafe Consumption—help identify endpoints that accept untrusted URLs or headers without proper allowlists or schema enforcement.

In Feathers, an SSRF-prone service might look like this simplified example where a remote URL is passed directly to an HTTP client without validation:

const axios = require('axios');
app.use('/fetch', {
  async create(data, params) {
    const { url } = data; // user-controlled
    const response = await axios.get(url, {
      auth: {
        username: process.exports.EXT_BASIC_USER,
        password: process.exports.EXT_BASIC_PASS
      }
    });
    return response.data;
  }
});

An attacker providing url=http://127.0.0.1:80/internal-admin could cause the server to make an authenticated request to an internal endpoint, potentially leaking sensitive data or triggering side effects. middleBrick’s scan would flag this as an Unsafe Consumption and Input Validation finding, providing remediation guidance such as host allowlisting, removing credentials from code, and using short-lived tokens instead of static Basic Auth credentials.

Remediation focuses on removing hardcoded credentials, avoiding Basic Auth for outbound calls when possible, and strictly validating and allowlisting any user-controlled URL inputs. Do not embed secrets in source code; use environment variables or a secrets manager, and ensure that outbound HTTP clients are configured with the least privilege necessary. Where Basic Auth is required, scope credentials to specific external hosts and rotate them regularly. The following code examples illustrate secure patterns within a FeathersJS service.

1. Validate and allowlist the host. Use a schema to ensure the URL belongs to an approved set of domains or IP ranges. This prevents redirection to internal resources.

const Ajv = require('ajv');
const addFormats = require('ajv-formats');
const axios = require('axios');

const ajv = new Ajv();
addFormats(ajv);
const isAllowedHost = (host) => {
  const allowed = new Set(['api.example.com', 'partner.example.org']);
  return allowed.has(host);
};
const validateUrl = (url) => {
  const schema = {
    type: 'object',
    required: ['url'],
    properties: {
      url: {
        type: 'string',
        format: 'uri',
        pattern: '^https://(api|partner)\\.example\\.com/'
      }
    }
  };
  const validate = ajv.compile(schema);
  const valid = validate({ url });
  if (!valid) throw new Error('Invalid URL');
  const host = new URL(url).host;
  if (!isAllowedHost(host)) throw new Error('Host not allowed');
  return url;
};

app.use('/fetch', {
  async create(data, params) {
    const { url } = validateUrl(data.url);
    const response = await axios.get(url, {
      // Avoid Basic Auth if the target does not require it
      // If required, use per-request credentials sourced securely
      auth: {
        username: process.env.EXT_BASIC_USER,
        password: process.env.EXT_BASIC_PASS
      },
      timeout: 5000
    });
    return response.data;
  }
});

2. Avoid embedding credentials in code and prefer token-based auth. If you must use Basic Auth, keep credentials out of the source and inject them via environment variables. Rotate credentials and scope them to specific integrations.

// server/config.js
module.exports = {
  externalAuth: {
    user: process.env.EXT_BASIC_USER,
    pass: process.env.EXT_BASIC_PASS
  }
};

// server/services/integration/integration.class.js
const axios = require('axios');
const { externalAuth } = require('../../config');

class IntegrationService {
  async getResource(url) {
    const validatedUrl = this.validateExternalUrl(url);
    return axios.get(validatedUrl, {
      auth: externalAuth,
      headers: { 'Accept': 'application/json' },
      timeout: 8000
    });
  }
  validateExternalUrl(url) {
    try {
      const u = new URL(url);
      if (!u.hostname.endsWith('example.com')) throw new Error('Disallowed host');
      return u.toString();
    } catch (err) {
      throw new Error('Invalid external URL');
    }
  }
}

module.exports = function () {
  this.service = new IntegrationService();
  this.find = async (params) => {
    return this.service.getResource(params.query.url);
  };
};

3. Use hooks to sanitize and log safely. Apply before hooks to enforce allowlists and remove risky headers or parameters before the request is made. Do not forward raw user input to the HTTP client.

app.hooks.push({
  name: 'sanitize-outbound',
  before: async context => {
    const { url } = context.data;
    if (!url) return;
    const allowedHosts = ['api.example.com'];
    const host = new URL(url).host;
    if (!allowedHosts.includes(host)) {
      throw new Error('Outbound host not permitted');
    }
    // Ensure no internal host leakage
    if (host.endsWith('.internal')) {
      throw new Error('Internal host blocked');
    }
    // Optionally log metadata without credentials
    context.params.meta = { outboundHost: host };
  }
});

middleBrick’s CLI can be used to verify that such remediation reduces the risk score. Run middlebrick scan <url> to obtain a security risk grade and prioritized findings. For teams managing many endpoints, the Pro plan adds continuous monitoring and the GitHub Action to fail builds if the score drops below a chosen threshold, while the Dashboard lets you track improvements over time.