Vulnerable Components in Feathersjs with Basic Auth

FeathersJS is a framework for real-time APIs that often exposes service endpoints over HTTP. When Basic Authentication is used naively, several classes of vulnerability become more likely. A common pattern is to rely on an authentication hook that checks a static username and password or a simple database lookup without enforcing transport security and without additional context checks.

One vulnerability pattern is weak authentication material. If the Basic Auth credentials are embedded in client-side code, stored in environment files without protection, or transmitted over non-TLS connections, they are trivial to intercept. An attacker can capture the base64-encoded credentials using a network sniffer or by compromising a misconfigured host, then reuse them to authenticate as any allowed user.

A second vulnerability pattern is the lack of rate limiting combined with open authentication. Because Basic Auth sends credentials with every request, an unauthenticated attacker can attempt many usernames and passwords against the endpoint. Without rate limiting or account lockout, brute-force or credential-stuffing attacks become practical, especially if weak passwords are used.

A third pattern is over-permissive service configuration. In Feathers, a service can be registered globally and inadvertently allowed to authenticate with Basic Auth while still exposing create, update, and delete operations to any authenticated user. This can lead to privilege escalation if the same credentials are shared across roles or if role-based access control is not enforced at the service or route level.

Additionally, if the authentication hook does not validate the scope of permissions for each request, an authenticated user may perform actions outside their intended authorization boundary. This becomes a Broken Level of Authorization (BOLA/IDOR) vector when a user can modify or read other users’ resources simply by knowing an identifier, and the service relies only on Basic Auth without per-instance checks.

These issues are detectable by security scanners such as middleBrick, which runs checks for Authentication, BOLA/IDOR, Rate Limiting, and Data Exposure in parallel. The scanner does not rely on internal architecture but validates observable behaviors, such as whether credentials are transmitted over cleartext HTTP, whether authentication succeeds without proper rate controls, and whether authenticated endpoints expose sensitive data in responses or error messages.

Remediation focuses on enforcing transport security, protecting credentials, and adding contextual authorization. The following examples assume a typical FeathersJS app using @feathersjs/authentication and @feathersjs/authentication-local.

1. Enforce TLS and protect credentials

Always serve Basic Auth over HTTPS. Never accept cleartext HTTP for authenticated endpoints. Store credentials using a salted hash rather than plain text. Example server setup:

const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const app = express(feathers());

// Use secure transport in production (e.g., terminate TLS at load balancer or use HTTPS server)
if (process.env.NODE_ENV === 'production') {
  // Ensure redirects from HTTP to HTTPS are handled at the infrastructure level
  app.use((req, res, next) => {
    if (!req.secure) {
      return res.status(403).send('HTTPS required');
    }
    next();
  });
}

module.exports = app;

2. Secure Basic Auth credentials

Do not embed credentials in source code. Use environment variables and validate them at startup. Example with hashed passwords:

const { AuthenticationService } = require('@feathersjs/authentication');
const { LocalStrategy } = require('@feathersjs/authentication-local');
const bcrypt = require('bcrypt');

const authService = new AuthenticationService(app);
app.configure(authService);

// During initialization, ensure the user store uses hashed passwords
app.service('users').hooks({
  before: {
    create: [authService.hooks.authenticate(['local'])],
    async beforeHash(password) {
      if (password) {
        const saltRounds = 10;
        return bcrypt.hash(password, saltRounds);
      }
      return password;
    }
  }
});

// Validate credentials from environment at startup
const validateAdminCreds = () => {
  const user = process.env.BASIC_AUTH_USER;
  const pass = process.env.BASIC_AUTH_PASS_HASH;
  if (!user || !pass) throw new Error('Basic Auth credentials must be set');
  // Optionally verify hash parses
  return { user, pass };
};

3. Add rate limiting to mitigate brute-force

Use a rate limiter middleware before the authentication hook to limit attempts per IP or API key.

const rateLimit = require('express-rate-limit');

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 30, // limit each IP to 30 requests per windowMs
  message: 'Too many requests, try again later.',
  standardHeaders: true,
  legacyHeaders: false,
});

app.use('/api/*', apiLimiter);

4. Combine with role-based access control

Ensure that even after authentication, each service enforces roles and scopes. Do not rely on Basic Auth alone for authorization.

app.service('messages').hooks({
  before: {
    get: [context => {
      const { user } = context;
      if (!user || !user.roles || !user.roles.includes('reader')) {
        throw new Error('Not authorized');
      }
      return context;
    }],
    find: [context => {
      const { user, params } = context;
      // Example: restrict users to their own data unless admin
      if (!user) throw new Error('Unauthenticated');
      if (!user.roles.includes('admin') && params.query.userId !== user.userId) {
        params.query.$and = [{ userId: user.userId }];
      }
      return context;
    }]
  }
});

By combining transport security, credential protection, rate limiting, and explicit authorization checks, the risks associated with Basic Auth in FeathersJS are substantially reduced while maintaining compatibility with existing clients that use the scheme.