Password Spraying in Feathersjs with Jwt Tokens

Password spraying is an authentication attack where one password (commonly Password1 or Welcome123) is tried against many accounts. In FeathersJS applications that use JWT tokens for session management, this combination can expose subtle timing and response-difference vulnerabilities even when the service intentionally delays or generic-errors failed logins.

FeathersJS typically uses an authentication service (e.g., @feathersjs/authentication with JWT) where login results in a JWT being issued upon successful credential verification. In a password spraying scenario, an attacker submits a known username with many different passwords. If the application does not enforce uniform response times and consistent response shapes, subtle differences can leak account existence or state:

• User existence: If the login flow first checks whether the user account exists and only then proceeds to password verification, an attacker can enumerate valid usernames before attempting passwords.
• JWT issuance timing: When a password is incorrect, FeathersJS may still return a 200 with an error payload, whereas a missing user might be handled earlier, producing a different status code or response shape. These differences aid password spraying by allowing the attacker to infer whether a username is valid.
• Rate-limiting gaps: Without global rate limiting on the login endpoint, an attacker can spray many passwords across many accounts within a short window, increasing the chance of a successful guess without triggering account-level protections.

Even with account lockouts or delays, password spraying remains effective when attackers use low-and-slow attempts. In FeathersJS, if authentication routes are not consistently structured and if JWT issuance is not guarded by uniform checks, the unauthenticated attack surface includes username enumeration via timing and response differences. This aligns with the BOLA/IDOR and Authentication categories in middleBrick’s 12 security checks, which would flag inconsistent error handling and missing rate controls during a scan.

middleBrick’s scan can detect these risks by running authentication and rate-limiting checks against your endpoint, highlighting where response behavior diverges between existing and non-existing users. The report includes prioritized findings with severity and remediation guidance, helping you harden the login flow without relying on internal implementation details.

To mitigate password spraying risks in FeathersJS when using JWT tokens, standardize responses, enforce rate limits, and ensure constant-time checks. Below are concrete, working examples you can apply in your FeathersJS service configuration.

1. Standardized login response

Ensure the login endpoint always returns the same HTTP status and response shape, regardless of whether the user exists or the password is incorrect.

// src/services/auth/auth.class.js
const { AuthenticationService, JWTStrategy } = require('@feathersjs/authentication');
const { iff, isProvider } = require('@feathersjs/commons');

class CustomAuthenticationService extends AuthenticationService {
  async create(data, params) {
    const result = await super.create(data, params);
    // Ensure JWT is present on success
    if (result && result.accessToken) {
      return result;
    }
    // If somehow missing, fall back to a safe generic response
    return { message: 'Login failed' };
  }
}

// In src/services/auth/index.js
const authentication = new CustomAuthenticationService({
  name: 'authentication',
  entity: 'user',
  service: app.service('users'),
  paginate: { default: 10, max: 50 },
  strategies: ['jwt'],
  callbackExcludes: ['password'],
  setupJWT: { expiresIn: '1d' }
});

// Override the login hook to normalize responses
authentication.hooks({
  before: {
    async create(hook) {
      const { email, password } = hook.data;
      // Example: always run user lookup to keep timing consistent
      const user = await hook.service.Model.findOne({ query: { email } });
      if (!user) {
        // Still proceed to password verification with a dummy user to keep timing similar
        hook.data.password = password; // will fail verification downstream
      }
      // Continue to super for consistent error handling
    }
  },
  after: {
    async create(hook) {
      if (hook.result && hook.result.accessToken) {
        return hook.result;
      }
      // Return a generic failure shape
      return { message: 'Invalid credentials' };
    }
  }
});

app.use('/authentication', authentication);

2. Enforce rate limiting on authentication endpoints

Apply rate limiting to the login route to slow down spraying attempts. FeathersJS does not include built-in rate limiting, so use a hook or an external proxy; here is a hook-based approach.

// src/hooks/rate-limit.js
const rateLimit = new Map();

function rateLimitHook(options = {}) {
  return async (hook) => {
    const { email } = hook.data || {};
    const key = email || hook.ip || 'unknown';
    const now = Date.now();
    const windowMs = options.windowMs || 60_000;
    const max = options.max || 5; // 5 attempts per window

    if (!rateLimit.has(key)) {
      rateLimit.set(key, []);
    }
    const timestamps = rateLimit.get(key).filter(t => now - t < windowMs);
    if (timestamps.length >= max) {
      const error = new Error('Too many attempts. Try again later.');
      error.code = 429;
      throw error;
    }
    timestamps.push(now);
    rateLimit.set(key, timestamps);
    return hook;
  );
}

// Apply to authentication service
app.service('authentication').hooks({
  before: {
    all: [rateLimitHook({ windowMs: 60_000, max: 5 })]
  }
});

3. Consistent user existence checks

Avoid branching early based on user existence. Use a dummy password verification step when the user is not found to keep timing predictable.

// Example using a before hook for login consistency
app.service('authentication').hooks({
  before: {
    async create(hook) {
      const { email, password } = hook.data;
      const user = await hook.service.Model.findOne({ query: { email } });
      if (!user) {
        // Create a dummy user record model instance to run password compare against
        // This keeps the code path similar to a real user check
        const dummy = new hook.service.Model({ password: 'unused', email: '[email protected]' });
        await dummy.comparePassword(password); // intentionally fails, no timing shortcut
        hook.data.password = 'dummy'; // ensure downstream fails generically
      }
    }
  }
});

4. MiddleBrick integration

Use the CLI to validate your changes: middlebrick scan <url>. The dashboard can track your API security scores over time, and the GitHub Action can add API security checks to your CI/CD pipeline, failing builds if the risk score exceeds your threshold. The MCP Server lets you scan APIs directly from your AI coding assistant within your development environment.

These steps reduce the effectiveness of password spraying by removing cues that distinguish valid accounts and by slowing down high-volume attempts against your JWT-based authentication flow.