Api Key Exposure in Restify with Postgresql

When a Restify server interacts with a Postgresql database, api key exposure typically occurs because application code or configuration intended for server-side use is inadvertently surfaced to API consumers. Common patterns include storing database credentials, third-party service keys, or internal tokens in environment variables, configuration files, or within route handlers, and then failing to prevent these values from being returned in API responses.

In a Restify application using Postgresql, a vulnerability can emerge when developer endpoints or error handlers expose sensitive data. For example, an endpoint that returns connection settings or debug information might include the Postgresql connection string or an API key used to authorize access to another service. If route handlers concatenate user input directly into database queries or responses without proper sanitization, keys may be reflected in output.

Consider a route that queries Postgresql for a user’s integrations and returns third-party credentials as part of the payload:

server.get('/integrations', async (req, res) => {
  const { rows } = await client.query('SELECT name, api_key FROM integrations WHERE user_id = $1', [req.query.userId]);
  res.send(rows);
});

If the api_key column contains sensitive tokens and the endpoint does not filter these fields, the keys are exposed to the API caller. Additionally, misconfigured logging or debugging routes in Restify can dump environment variables, including Postgresql passwords or external API keys, into logs or responses. MiddleBrick’s scans detect such exposure by analyzing the unauthenticated attack surface and identifying endpoints that return high-entropy strings or known key patterns in JSON responses.

The LLM/AI Security checks are particularly effective at identifying subtle exposures, such as when an endpoint inadvertently includes an API key in an error message or when a debug route returns configuration objects containing database credentials. These checks test for system prompt leakage and output scanning, ensuring that keys are not present in responses that could be extracted via prompt injection or standard API calls.

Furthermore, because Restify APIs often integrate with external services, any exposed key can be leveraged for privilege escalation or data exfiltration. The scanner correlates findings from the Authentication, Data Exposure, and Unsafe Consumption checks to highlight routes where sensitive material may leak, providing prioritized findings with severity and remediation guidance mapped to frameworks like OWASP API Top 10.

To prevent api key exposure when using Postgresql with Restify, apply strict data handling and response filtering. Never return raw query results that may contain sensitive columns, and ensure secrets are managed outside the request/response lifecycle.

Use parameterized queries to avoid injection, and explicitly select only necessary, safe fields. For example, instead of returning all columns, project only required data:

server.get('/integrations', async (req, res) => {
  const { rows } = await client.query(
    'SELECT name, connected_at FROM integrations WHERE user_id = $1',
    [req.query.userId]
  );
  res.send(rows);
});

If you must store and use API keys for downstream services, keep them in server-side environment variables and reference them securely without echoing them back to the client:

const fetchExternalData = async (apiKey) => {
  const response = await fetch('https://api.external.com/data', {
    headers: { Authorization: `Bearer ${apiKey}` }
  });
  return response.json();
};

server.get('/data', async (req, res) => {
  const { rows } = await client.query('SELECT ext_id FROM user_ext WHERE user_id = $1', [req.query.userId]);
  const apiKey = process.env.EXTERNAL_API_KEY;
  const data = await fetchExternalData(apiKey);
  res.send({ items: data.items });
});

For Postgresql connection strings, store them in environment variables and reference them via a secure configuration module, ensuring they are never included in response bodies or logs:

// server.js
const postgresConfig = {
  user: process.env.PG_USER,
  host: process.env.PG_HOST,
  database: process.env.PG_DATABASE,
  password: process.env.PG_PASSWORD,
  port: process.env.PG_PORT,
};

const client = new Client(postgresConfig);
await client.connect();

// Do not log or expose connection details
server.on('after', (req, res, route, err) => {
  // Avoid logging sensitive headers or payloads
});

Implement schema-level protections by revoking public access to sensitive columns in Postgresql and using views to expose safe subsets:

-- In Postgresql
CREATE VIEW public.integrations_view AS
SELECT id, name, connected_at
FROM integrations
WHERE is_public = true;

REVOKE ALL ON integrations FROM public;
GRANT SELECT ON integrations_view TO web_user;

Validate all inputs rigorously to prevent injection that could lead to key leakage, and apply consistent output filtering in Restify routes. Combine these practices with MiddleBrick’s dashboard and CLI to continuously monitor your endpoints and ensure compliance with security frameworks.