Ssrf Server Side in Feathersjs with Cockroachdb

Server-side SSRF (Server-Side Request Forgery) in a FeathersJS application that uses CockroachDB arises from how Feathers services resolve external inputs into HTTP calls and how those calls interact with your database layer. FeathersJS is a framework that encourages building services around hooks and models; if a hook or service method dynamically builds a URL from user-controlled data and performs an HTTP request (for example to validate, enrich, or proxy data), an attacker can supply a hostname such as http://cockroachdb-admin:26257 or the Cloud Console metadata address to force the server to make internal requests.

In a CockroachDB-backed Feathers service, SSRF becomes especially risky because the database connection strings and admin interfaces are often reachable internally. A common vulnerable pattern is using a user-supplied URL to call an external validation API; if that external API internally resolves service names like cockroachdb or queries internal endpoints, an attacker can pivot to the database admin UI (:8080), the SQL endpoint (:26257), or the internal status endpoints (/_status/vars). Because Feathers hooks run in the server process, any SSRF-triggered request can read or modify data that the app’s CockroachDB client is authorized to access, potentially leading to sensitive data exposure or unauthorized writes.

Real attack patterns include probing internal Kubernetes DNS names (e.g., http://kubernetes.default.svc) to reach the database pod IPs, or using SSRF to bypass network ACLs that otherwise restrict direct access to the CockroachDB node ports. The OWASP API Security Top 10 categorizes this under API1:2023 Broken Object Level Authorization when the SSRF enables horizontal or vertical privilege escalation across service boundaries. Because Feathers services often unify business logic and data access in one runtime, an SSRF that reaches CockroachDB can expose not only data but also configuration and operational endpoints that should never be externally reachable.

To illustrate the risk in practice, consider a Feathers hook that fetches an external URL provided by a client:

// ❌ Vulnerable Feathers hook
app.service('external').hooks({
  before: {
    create: [async context => {
      const url = context.data.url; // user-controlled
      const response = await fetch(url); // SSRF possible
      context.data.result = await response.text();
      return context;
    }]
  }
});

If the caller sends url=http://cockroachdb-admin:8080/_admin/v1/databases, the server performs an internal HTTP call to the CockroachDB Admin UI. Even if the Feathers service uses a separate CockroachDB client for queries, the SSRF can expose admin functionality that would otherwise be isolated.

Middleware and service design choices in FeathersJS can inadvertently create SSRF surfaces. For example, dynamic URL building from user input, lack of hostname denylists for internal addresses, and missing egress network controls all contribute. Because CockroachDB often runs in a private network with tightly scoped credentials, SSRF effectively grants a foothold to the database layer, turning an API vulnerability into a data compromise path.

Remediation focuses on strict input validation, egress controls, and service isolation. For FeathersJS services that must perform outbound HTTP, avoid using any user-controlled data to form URLs. If external calls are unavoidable, use an allowlist of permitted hostnames and ports, and resolve hostnames to IPs before initiating the request to prevent DNS rebinding. Explicitly disable redirects and enforce timeouts to limit abuse windows.

Below is a hardened Feathers hook that validates the target domain against an allowlist and uses a low-level HTTP client with strict controls:

// ✅ Secure Feathers hook with allowlist
const ALLOWED_HOSTS = new Set(['api.example.com', 'data.example.com']);
const { HttpsProxyAgent } = require('hpagent');
const fetch = require('node-fetch');

app.service('external').hooks({
  before: {
    create: [async context => {
      const url = new URL(context.data.url);
      if (!ALLOWED_HOSTS.has(url.hostname)) {
        throw new Error('Request to unauthorized host');
      }
      const agent = new HttpsProxyAgent({ rejectUnauthorized: true });
      const response = await fetch(url.toString(), {
        agent,
        redirect: 'manual',
        timeout: 5000,
        headers: { 'User-Agent': 'middleBrick-demo/1.0' }
      });
      context.data.result = await response.text();
      return context;
    }]
  }
});

Network-level controls are essential. In Kubernetes, use NetworkPolicy to restrict egress from the Feathers pod to only known IP ranges and deny traffic to CockroachDB internal ports unless explicitly required. In environments without Kubernetes, enforce egress firewall rules that block outbound connections to private address ranges (RFC 1918) unless they are explicitly required for service operation.

When integrating with CockroachDB directly, ensure your Feathers service uses connection strings that reference secure, scoped credentials. Avoid embedding usernames or passwords in URLs that could be logged or exposed. Instead, use environment variables and secret management, and configure the CockroachDB client with strict TLS settings:

// ✅ Secure CockroachDB client in Feathers
const { Client } = require('pg'); // CockroachDB wire-compatible
const client = new Client({
  connectionString: process.env.COCKROACH_URI, // injected secret
  ssl: {
    rejectUnauthorized: true,
    ca: process.env.CA_CERT // explicit CA
  },
  application_name: 'feathers-service'
});
await client.connect();
const result = await client.query('SELECT table_name FROM information_schema.tables WHERE table_schema=$1', ['public']);
await client.end();

For deployments that use the middleBrick ecosystem, the CLI can be integrated into scripts to validate configurations and the GitHub Action can enforce security gates in CI/CD pipelines. By scanning your API definitions and runtime behavior, middleBrick helps identify SSRF-prone endpoints before they reach production. The MCP Server enables these checks directly from your IDE, providing rapid feedback during development. None of these integrations modify or block traffic; they report findings and guidance so your team can make informed decisions.

Finally, complement SSRF defenses with runtime monitoring for unexpected outbound connections and audit logs from CockroachDB. Ensure that any remediation guidance from middleBrick is reviewed in the context of your service architecture, because secure design requires coordinated controls across the API layer, network, and database.