Brute Force Attack in Feathersjs with Basic Auth

FeathersJS is a framework that can expose a HTTP REST or Socket API. When Basic Authentication is implemented naively, it typically means the server validates a static username and password on each request. Unlike token-based flows, Basic Auth sends credentials in every HTTP header (base64‑encoded, not encrypted), which can be captured on‑the‑wire without TLS and can be targeted by online brute‑force attempts. A brute‑force attack against Basic Auth in a FeathersJS service often exploits weak account policies (e.g., no account lockout, no per‑user rate limiting, predictable usernames) and the fact that the login check is performed on each authenticated endpoint call rather than at a dedicated login step. If the service does not enforce rate limiting at the authentication boundary, an attacker can iterate passwords rapidly.

In FeathersJS, if you use a custom authentication hook that only checks the header without additional controls, each request becomes an independent guess opportunity. For example, consider a FeathersJS service that protects routes via a hook that validates the Authorization header but does not integrate with a rate limiter or suspicious‑activity detection. The attacker can send many requests with different credentials to the same endpoint (or to a purposely created endpoint that echoes auth results). Because the check is per request, there is no built-in throttling, and the server may respond with 401 or 200 depending on validity, giving feedback to the attacker. This behavior maps to findings in the Authentication and Rate Limiting checks run by middleBrick, which tests unauthenticated attack surfaces and can detect missing rate controls around authentication.

Additionally, if the FeathersJS app exposes an unauthenticated endpoint that reveals user existence or account state (e.g., returns different messages for valid vs invalid users), it assists the attacker in enumerating valid accounts before launching the brute force attempts. The combination of Basic Auth with such endpoints increases the risk of successful online guessing. MiddleBrick’s Authentication and BOLA/IDOR checks can surface whether the API leaks information that facilitates enumeration.

To harden FeathersJS with Basic Auth, apply defense in depth: enforce HTTPS, avoid static shared credentials, prefer dynamic credentials or token flows, and add rate limiting and suspicious response handling. Below are concrete, working snippets that illustrate recommended patterns.

1. Enforce HTTPS and avoid Basic Auth for sensitive flows

Always terminate TLS at your server or load balancer. If you must use Basic Auth, ensure it is only over HTTPS. In Feathers, you can add a hook that rejects HTTP requests early:

// src/hooks/require-https.js
module.exports = function () {
  return async context => {
    if (!context.params.secure) {
      throw new Error('HTTPS required');
    }
    return context;
  };
};

2. Dynamic credentials with limited scope instead of static Basic credentials

Rather than a single static username/password, create users via a service and validate using a proper identity store. Here is a minimal example using a users service and the @feathersjs/authentication-local package:

// src/services/users/users.class.js
const { Service } = require('@feathersjs/feathers');
const { GeneralObjectStorage } = require('@feathersjs/commons');

class UsersService extends Service {
  constructor(options) {
    super({ name: 'users', Model: GeneralObjectStorage });
    this.options = options;
  }

  async create(data, params) {
    // Ensure password is hashed; never store plain text
    if (data.password) {
      data.password = await this.app.passport.hashPassword(data.password);
    }
    return super.create(data, params);
  }
}

module.exports = UsersService;

3. Add rate limiting to authentication endpoints and hooks

Use a rate limiter middleware (e.g., express-rate-limit) and apply it to authentication-related hooks. Example with express-rate-limit in a Feathers server setup:

// src/authentication/rate-limit.js
const rateLimit = require('express-rate-limit');

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

module.exports = function (app) {
  app.use('/login', authLimiter); // adjust path to your auth endpoint if custom
};

4. Feathers hook that validates credentials with rate control and minimal information leakage

Create an authentication hook that validates the Basic Auth header and ensures consistent timing behavior to avoid user enumeration. Also ensure the hook integrates with @feathersjs/authentication:

// src/hooks/authentication.js
const { authenticate } = require('@feathersjs/authentication-local');

module.exports = function () {
  return authenticate('local', (err, authResult, params) => {
    // Always return a generic error to avoid leaking whether user exists
    if (err) {
      // Log the real error internally, but do not expose details
      console.error('Authentication error:', err);
      throw new Error('Invalid credentials');
    }
    return authResult;
  });
};

5. Apply the hook and limit info exposure in services

Ensure your services do not return different HTTP status codes or messages for missing vs incorrect credentials. Combine the authentication hook with the service configuration:

// src/app.js (relevant parts)
const authentication = require('./authentication');
const users = require('./services/users/users.class');

app.configure(authentication);
app.use('/users', users);
app.configure(require('./services/my-service/my-service.class'));

// Protect a specific service with authentication hooks
app.service('my-service').hooks({
  before: {
    all: [app.authentication.hooks.authenticate()],
  },
});

By combining these practices — enforcing HTTPS, avoiding static shared Basic credentials, applying rate limiting on authentication paths, and standardizing error responses — you reduce the feasibility of online brute force attacks against a FeathersJS API using Basic Auth. middleBrick’s Authentication and Rate Limiting checks can validate that these controls are in place and highlight remaining gaps.