Hallucination Attacks in Feathersjs with Basic Auth

FeathersJS is a framework for real-time web applications that commonly exposes REST and WebSocket endpoints. When Basic Authentication is implemented at the transport layer (e.g., via an authentication hook or middleware) without strict schema enforcement and authorization checks on individual service methods, it can enable hallucination attacks. In this context, hallucination refers to an attacker inducing the server to fabricate or infer information through crafted requests that bypass intended access controls.

With Basic Auth, credentials are sent in an Authorization header (Base64-encoded, not encrypted). If a Feathers service does not validate scope, role, or ownership for each operation and relies only on the presence of a valid user, an authenticated user may exploit weak or missing service-level checks to access or manipulate resources that should be restricted. For example, a /messages service that only checks authentication but not record ownership might allow an authenticated user to query another user’s messages simply by iterating IDs or guessing references.

In a Feathers setup using Basic Auth, hallucination attacks can manifest as ID enumeration, privilege escalation via misapplied hooks, or data leakage through overly permissive queries. If the service exposes a find method without filtering by the authenticated user’s identity, an attacker can submit a request with a crafted query (e.g., { $limit: 0, query: {} }) to infer the existence or count of other users’ records. The attack leverages the fact that Basic Auth provides identity but not authorization context; the server must enforce tenant or user boundaries explicitly. Without these boundaries, an authenticated user can probe the API surface and construct inferences about data relationships, availability, and structure, effectively hallucinating information that should be opaque.

Moreover, Feathers hooks that apply globally may not differentiate between operations (create, read, update, delete). If a before hook sets the user id from the Basic Auth credentials but subsequent service methods do not scope queries to that user, the attacker can bypass intended isolation. This becomes critical when combined with mass assignment or unsafe consumption vulnerabilities, where input filtering is insufficient. The attacker may submit nested payloads or ambiguous parameters that the service misinterprets, leading to unintended data exposure or logic flaws.

Real-world patterns include missing $select or field-level restrictions, lack of row-level security policies, and improper use of query filters. For instance, a service might allow filtering on non-sensitive fields but fail to enforce that the authenticated user can only see their own records. An attacker can iterate through plausible identifiers, observe differences in response times or status codes, and infer data existence — a form of hallucination driven by weak access controls rather than cryptographic weaknesses.

To map this to known weaknesses, consider references to OWASP API Top 10 2023:2024 — Broken Object Level Authorization (BOLA) and 2023:2024 — Broken User Authentication (if misconfigured). These amplify the risk when combined with Basic Auth, which does not inherently bind the session to a scoped context. Unlike token-based flows with explicit scopes, Basic Auth requires additional guards to ensure each request is constrained to the subject’s permitted resources.

Remediation centers on enforcing user-specific scoping at the service layer and tightening hook logic. Do not rely on Basic Auth alone for authorization. Combine it with explicit query filters that tie resources to the authenticated subject. Below are concrete, syntactically correct examples for FeathersJS that demonstrate secure patterns.

Example 1: Scoped find with Basic Auth hook

const { iff, isProvider, preventChanges } = require('feathers-hooks-common');

// Hook to restrict queries to the authenticated user’s records
const restrictToUser = context => {
  if (context.params.user) {
    // Ensure the query only returns records belonging to the user
    context.params.query.userId = context.params.user.id;
    // Explicitly remove userId from query if provided maliciously
    delete context.params.query.userId;
  }
  return context;
};

module.exports = {
  before: {
    all: [iff(isProvider('external'), preventChanges(['password']))],
    find: [restrictToUser],
    get: [restrictToUser]
  },
  after: {
    all: []
  },
  error: {
    all: []
  }
};

Example 2: Service method with user binding and input validation

const { Validator } = require('fastest-validator');
const v = new Validator();

module.exports = function (app) {
  const messages = app.service('messages');

  // Define a schema for safe query parameters
  const schema = {
    $filter: { type: 'object', optional: true, props: {
      status: { type: 'string', optional: true },
      $limit: { type: 'number', positive: true, optional: true }
    }}
  };

  messages.hooks({
    before: {
      async find(context) {
        // Validate input to prevent query smuggling
        const valid = v.validate(context.params.query, schema);
        if (valid !== true) {
          throw new Error('Invalid query parameters');
        }
        // Enforce user scoping at the service level
        if (context.params.user) {
          context.params.query.userId = context.params.user.id;
        }
        return context;
      }
    }
  });
};

Example 3: Basic Auth setup with user verification and safe authentication hook

const auth = require('feathers-authentication');
const { iff, isProvider } = require('feathers-hooks-common');

const authentication = auth({
  entity: 'user',
  service: 'users',
  secret: process.env.AUTH_SECRET,
  authStrategies: ['local'],
  authProvider: {
    local: {
      usernameField: 'email',
      passwordField: 'password',
      passReqToCallback: false
    }
  }
});

// Hook to ensure user exists and bind minimal profile data
const setUserContext = context => {
  const { user } = context;
  if (user && user.id) {
    // Attach a safe, minimal user object to params
    context.params.user = {
      id: user.id,
      email: user.email,
      role: user.role || 'user'
    };
  }
  return context;
};

module.exports = {
  before: {
    all: [iff(isProvider('external'), authentication)],
    find: [setUserContext],
    get: [setUserContext]
  },
  after: {
    all: []
  },
  error: {
    all: []
  }
};

Operational guidance

• Always scope queries to the authenticated subject (e.g., userId) in service methods.
• Validate and sanitize all inputs to prevent injection or query manipulation.
• Use hooks to centralize authorization logic rather than repeating checks in routes.
• Combine Basic Auth with HTTPS to protect credentials in transit, as Basic Auth sends credentials in an easily decoded header.
• Audit service definitions for permissive queries and ensure that $select or projection limits sensitive fields.

These practices reduce the surface for hallucination attacks by ensuring that an authenticated identity cannot infer or access records outside their scope. They align with OWASP API Top 10 guidance on BOLA and complement the transport security provided by Basic Auth when properly implemented.