Brute Force Attack in Feathersjs with Jwt Tokens

A brute force attack against a FeathersJS service that uses JWT tokens attempts to discover valid tokens or session secrets by systematically trying many values. Because FeathersJS often uses JWT for stateless authentication, the attack surface centers on token generation, validation, and rate limiting rather than traditional password guessing alone.

When JWTs are used, a common misconfiguration is accepting any well-formed token without tying verification to a per-user or per-session context. If token validation does not enforce strict issuer, audience, or expiration checks, an attacker can submit many crafted tokens quickly and observe differences in response behavior (for example, 401 versus 403, or timing differences) to infer validity. This is especially risky when the secret or public key is weak, leaked, or predictable.

FeathersJS typically relies on libraries like jsonwebtoken to sign and verify tokens. If the application does not implement rate limiting on authentication endpoints or token verification paths, an attacker can send many requests with different token values in a short period. The lack of rate limiting enables online brute force attempts against tokens or the underlying signing secret. Additionally, if token IDs (jti) or user identifiers are guessable (e.g., sequential integers or UUIDv1), an attacker can iterate through possible IDs and test token validity via endpoints that require authentication.

Another vector arises from unauthenticated endpoints that leak information about token validity. For example, an endpoint that introspects a token or returns metadata might provide different responses for valid versus invalid tokens. Combined with missing or weak input validation, this can guide an attacker in refining guesses. The absence of per-request nonces or replay protection can also allow captured tokens to be reused, amplifying the impact of discovered tokens.

The interaction of FeathersJS hooks and JWT verification increases complexity. If before hooks validate tokens but do not consistently enforce rate limits or error handling, attackers can probe the hook chain to identify timing differences or exception paths. Poorly configured CORS or exposed introspection routes further broaden the attack surface. The key vulnerability is not JWT itself, but how FeathersJS integrates token verification without protections such as rate limiting, strict validation, and anti-replay mechanisms.

Remediation focuses on hardening token validation, enforcing rate limits, and reducing information leakage in FeathersJS applications that use JWT.

• Enforce strict JWT validation options and never accept unsigned tokens. Always verify issuer (iss), audience (aud), and expiration (exp). Use strong algorithms such as RS256 with a proper public key, and avoid symmetric secrets that are weak or leaked.
• Implement rate limiting on authentication and token verification endpoints. For FeathersJS, this can be done via a custom hook that tracks request counts per IP or per user identifier using a transient store like Redis.
• Make token identifiers (jti) unpredictable and avoid exposing validity hints through error messages. Return uniform error responses for authentication failures and ensure timing does not leak verification state.

Example: Configure JWT verification in a FeathersJS service hook with strict options and a rate-limiting hook.

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

// Use memory store for simplicity in this example; prefer Redis in production
const rateLimiter = new RateLimiterMemory({
  points: 5, // 5 requests
  duration: 1, // per second
});

// Rate limiting hook for authentication routes
const rateLimitHook = context => {
  const { ip = 'unknown' } = context.params;
  return rateLimiter.consume(ip)
    .then(() => context)
    .catch(() => {
      throw new Error('Too many requests');
    });
};

// JWT verification hook with strict options
const jwtVerifyHook = context => {
  const authHeader = context.params.headers.authorization || '';
  const token = authHeader.startsWith('Bearer ') ? authHeader.slice(7) : null;
  if (!token) {
    return context; // Let authentication strategy handle missing token
  }
  try {
    const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY || process.env.JWT_SECRET, {
      algorithms: ['RS256'],
      issuer: 'https://api.example.com',
      audience: 'https://api.example.com/audience',
    });
    context.params.account = decoded; // attach decoded payload for downstream use
    return context;
  } catch (err) {
    // Avoid leaking token validity details
    throw new Error('Invalid token');
  }
};

// Apply hooks to the authentication service
app.service('authentication').hooks({
  before: {
    create: [rateLimitHook, jwtVerifyHook],
  },
});

// Example of a token with a non-guessable jti
const payload = {
  sub: 'usr_abc123',
  jti: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
  iss: 'https://api.example.com',
  aud: 'https://api.example.com/audience',
  iat: Math.floor(Date.now() / 1000),
  exp: Math.floor(Date.now() / 1000) + 3600,
};
const token = jwt.sign(payload, process.env.JWT_PRIVATE_KEY || process.env.JWT_SECRET, { algorithm: 'RS256' });
console.log(token);

Additional measures include rotating signing keys, using short token lifetimes, and binding tokens to a device or IP where appropriate. For continuous monitoring of API security posture, consider integrating the middleBrick Web Dashboard to track risk scores and findings over time, or use the middleBrick CLI to automate scans from your terminal.