Prototype Pollution in Feathersjs with Api Keys

Prototype pollution in a FeathersJS application that uses API keys can arise when user-supplied data—such as query parameters, headers, or JSON payloads—is merged into objects that later influence authorization decisions. Because API keys are often stored in request context or passed through service hooks, an attacker who can inject properties into the key-handling objects may escalate privileges or bypass intended access controls.

Consider a FeathersJS service that retrieves a key from a request header and uses it to look up permissions. If the application copies header values into a mutable shared object without sanitization, an attacker can supply a payload like _proto[admin]=true or constructor.prototype.polluted=true. When the key-matching logic traverses or extends this object, the injected property can affect other instances or alter behavior, potentially allowing an unauthenticated or low-privilege caller to assume administrative rights.

In practice, this can intersect with BOLA/IDOR and BFLA/Privilege Escalation checks. For example, an API key validation routine that relies on Object.assign or spread syntax on user-controlled input may inadvertently overwrite critical properties such as role or scope. If the key is later used to gate access to a “/admin” endpoint, the pollution can cause the gate to evaluate incorrectly, granting access to unauthorized operations.

The risk is compounded when OpenAPI specs define parameters that map directly into mutable JavaScript objects. If the spec includes a header or query parameter for an API key and the runtime merges this into a prototype chain, the resulting object may carry tainted properties into downstream hooks or validators. This can lead to authentication bypasses or inconsistent enforcement, even when the API key itself is syntactically valid.

Because middleBrick tests input validation and BOLA/IDOR in parallel, such an issue would typically be surfaced with a high severity finding and guidance to treat API key inputs as immutable. Developers should ensure that key handling logic does not extend native prototypes or merge user data into shared objects, and should validate and transform keys within isolated, plain objects.

Remediation focuses on strict isolation of API key data and avoidance of prototype-mutable operations. Use plain-object copies, validate key formats, and enforce strict equality checks rather than relying on merged prototypes.

1. Avoid prototype pollution by using safe merging

Replace Object.assign and spread syntax on request-derived data with a safe deep-merge that does not traverse prototypes. For example:

// Unsafe: can pollute prototypes
// const merged = { ...req.headers };

// Safe: use a custom merge that copies only own enumerable properties
function safeMerge(target, source) {
  if (source && typeof source === 'object') {
    for (const key of Object.keys(source)) {
      if (Object.prototype.hasOwnProperty.call(source, key)) {
        target[key] = source[key];
      }
    }
  }
  return target;
}

const context = safeMerge({}, req.headers);
context.apiKey = req.headers['x-api-key'];

2. Validate and normalize API keys in a dedicated, isolated service

Create a small, pure function to parse and validate the API key without relying on request objects that may be polluted:

// apiKeys.js
function parseApiKey(headers) {
  const key = headers['x-api-key'];
  if (typeof key !== 'string' || !/^[A-F0-9]{32}$/i.test(key)) {
    throw new Error('Invalid API key');
  }
  // Return a plain, minimal object; no prototype chain dependencies
  return { key, scope: 'public', expiresAt: null };
}

// In your service hook
app.hooks.before.push(async context => {
  const { apiKey } = context.params; // ensure params are explicitly set
  try {
    const parsed = parseApiKey(context.headers);
    context.result = { authenticated: true, ...parsed };
  } catch (err) {
    throw new Error('Unauthorized');
  }
});

3. Enforce immutable checks and explicit roles

When using API keys to determine permissions, avoid dynamic property lookups on shared objects. Instead, use explicit mappings:

const keyScopes = new Map();
keyScopes.set('A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5', 'admin');
keyScopes.set('P6Q7R8S9T0U1V2W3X4Y5Z6A7B8C9', 'user');

app.hooks.before.push(context => {
  const key = context.headers['x-api-key'];
  const scope = keyScopes.get(key);
  if (!scope) {
    throw new Error('Forbidden');
  }
  // Attach a plain value, not a prototypal chain
  context.params.userRole = scope;
  return context;
});

4. Harden hooks and validators against polluted inputs

Ensure that any validator or hook that inspects API keys does not rely on __proto__, constructor, or other prototype-level properties. Use Object.prototype.hasOwnProperty or Map/Set for lookups:

// Validate without prototype-dependent methods
function hasOwn(obj, key) {
  return Object.prototype.hasOwnProperty.call(obj, key);
}

app.hooks.before.push(context => {
  const headers = context.headers;
  if (!hasOwn(headers, 'x-api-key')) {
    throw new Error('Missing API key');
  }
  // Further checks...
  return context;
});

By treating API keys as opaque, validated values and avoiding mutation of shared or prototypal objects, you reduce the attack surface for prototype pollution in FeathersJS services. These practices align with the remediation guidance that middleBrick would provide, emphasizing input validation and minimizing the reach of injected properties.