Brute Force Attack in Feathersjs (Javascript)

A brute force attack against a FeathersJS application in JavaScript typically targets authentication endpoints, often those using local authentication (e.g., @feathersjs/authentication-local). Because FeathersJS is unopinionated by default about rate limiting and account lockout, an unauthenticated attacker can send many sequential requests to /authentication or a custom login service to guess credentials.

In JavaScript, common patterns that increase risk include defining the authentication service with default configuration that does not enforce login attempt throttling. For example, creating a service with app.use('/authentication', authentication({ entity: 'user', service: 'users', secret: process.env.AUTH_SECRET })) without additional guards exposes a predictable endpoint. If the underlying user store does not enforce per-account attempt limits, an attacker can iterate over passwords or use credential-stuffing payloads without immediate detection.

FeathersJS hooks and middleware in JavaScript can inadvertently expose timing differences. If a login hook performs asynchronous operations that resolve faster for invalid usernames than for invalid passwords, an attacker may infer valid accounts. Also, using JavaScript objects for query filters without strict validation may allow attackers to probe account existence via timing or error messages returned by the service.

The framework’s flexibility means developers must explicitly add protections; FeathersJS does not automatically enforce account lockouts, CAPTCHA, or adaptive delays. Without integrating rate limiting at the FeathersJS application layer (e.g., using a hook or external gateway), the authentication path remains susceptible to high-volume brute force attempts. The use of JavaScript on both server and client can also expose verbose error messages that aid attackers in refining guesses.

To mitigate brute force risks in FeathersJS with JavaScript, enforce rate limiting and account lockout logic within service hooks. Below is a robust hook example that tracks failed attempts per identity and introduces progressive delays.

const rateLimit = new Map();

app.service('authentication').hooks({
  before: {
    create: [async context => {
      const { email } = context.data;
      const key = `login_failures:${email}`;
      const now = Date.now();
      const window = 60 * 1000; // 1 minute
      const maxAttempts = 5;

      // Retrieve or initialize failure record
      const failures = rateLimit.get(key) || { count: 0, firstAttemptAt: now };

      // Check if within lockout window
      if (now - failures.firstAttemptAt > window) {
        failures.count = 0;
        failures.firstAttemptAt = now;
      }

      if (failures.count >= maxAttempts) {
        const elapsed = now - failures.firstAttemptAt;
        const delay = Math.min(elapsed, 30000); // cap at 30s
        await new Promise(resolve => setTimeout(resolve, delay));
        // Optionally throw an error to inform client
      }

      // Simulate authentication logic; if fails, record attempt
      const isValid = await validateCredentials(context.data);
      if (!isValid) {
        failures.count += 1;
        rateLimit.set(key, failures);
        // Optional: progressive delay on repeated failures
        if (failures.count >= 3) {
          await new Promise(resolve => setTimeout(resolve, 1000 * (failures.count - 2)));
        }
      return context;
    }]
  }
});

Additionally, integrate an external rate limiter at the application edge or use a store-backed solution to persist counts across process restarts. For production, prefer a robust store such as Redis:

const RedisStore = require('rate-limiter-flexible').RateLimiterRedis;
const { RateLimiterMemory } = require('rate-limiter-flexible');

// Choose Memory for single process or Redis for distributed setups
const rateLimiter = new RedisStore({
  points: 10, // 10 requests
  duration: 60, // per 60 seconds
  storeClient: redisClient,
  keyPrefix: 'middlebrick_ratelimit'
});

app.service('authentication').hooks({
  before: {
    create: [async context => {
      try {
        await rateLimiter.consume(context.data.email || context.connection.remoteAddress);
      } catch (rej) {
        context.result = { error: 'Too many attempts, try later' };
        context.status = 429;
        throw new Error('Rate limit exceeded');
      }
      return context;
    }]
  }
});

Always pair these measures with secure password storage (e.g., bcrypt with appropriate rounds) and consider enabling multi-factor authentication to reduce reliance on password guessing resistance. Regularly review authentication logs for patterns indicative of automated attacks.