Denial Of Service in Feathersjs with Jwt Tokens

FeathersJS services that use JWT tokens for authentication can be susceptible to Denial of Service (DoS) when token validation or decoding logic is computationally expensive or not properly constrained. A common pattern is to verify the token and attach the payload to the connection or request object on every incoming call. If the token contains a large payload, many claims, or uses asymmetric algorithms with large keys, the repeated cryptographic verification on each request can consume significant CPU time. Under high concurrency, this can lead to thread or event loop saturation, increasing response latency and causing service instability.

Another DoS angle arises from how FeathersJS handles authentication errors and unauthenticated requests when JWT is enforced. If the service performs expensive operations, such as fetching user data or resolving roles from a database during the authentication hook before validating token integrity, an attacker can force these operations to run repeatedly with invalid or malformed tokens. This amplifies resource usage per request. Additionally, if token validation logic does not enforce strict input constraints (e.g., expected header algorithms), an attacker may submit tokens with algorithms like none or force asymmetric verification to use a computationally heavier algorithm than intended, further stressing the service.

OpenAPI/Swagger spec analysis can highlight endpoints with authentication-heavy operations, but runtime behavior under malformed or high-volume token submissions is best observed through active testing. middleBrick scans an API endpoint to detect authentication configurations that may expose a larger attack surface when paired with JWT, including missing rate limiting on authentication routes and overly permissive CORS settings that allow token probing from unexpected origins. These findings map to the Authentication and Rate Limiting checks in the 12 security checks, which run in parallel to identify conditions that can contribute to DoS scenarios.

In the context of LLM/AI Security, an unauthenticated LLM endpoint exposed through a FeathersJS service can be probed with prompt injection techniques to observe how the system behaves under malformed or resource-intensive inputs. Although this does not directly test JWT token validation, it can reveal whether error handling or logging leaks information that assists an attacker in constructing resource-heavy requests. middleBrick’s active prompt injection testing and output scanning help identify whether error messages or responses expose details that could be leveraged to amplify DoS against JWT-secured endpoints.

To reduce DoS risk when using JWT tokens in FeathersJS, focus on making token validation lightweight and predictable. Use synchronous decoding for header and algorithm checks before full verification, enforce strict algorithm lists, and avoid expensive per-request data lookups during authentication. Apply rate limiting specifically on authentication paths and ensure errors are handled without triggering additional work.

Example FeathersJS authentication hook with safe JWT handling:

const { AuthenticationError } = require('@feathersjs/errors');
const jwt = require('@feathersjs/authentication-jwt');
const jwksClient = require('jwks-rsa');

// Use a cached JSON Web Key Set client to avoid repeated network or crypto operations
const client = jwksClient({
  jwksUri: 'https://your-auth-provider/.well-known/jwks.json',
  cache: true,
  rateLimit: true,
  jwksRequestsPerMinute: 5
});

function getKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    if (err) {
      return callback(err);
    }
    const signingKey = key.publicKey || key.rsaPublicKey;
    callback(null, signingKey);
  });
}

module.exports = {
  before: {
    all: [jwt({\n      secret: getKey,\n      algorithms: ['RS256'], // enforce a single, efficient algorithm
      iss: 'https://your-auth-provider/',\n      aud: 'your-api-audience',\n      maxAge: '2h' // reject tokens that are too old to reduce re-validation overhead
    })],
    find: [],
    get: [],
    create: [],
    update: [],
    patch: [],
    remove: []
  },
  after: {
    all: [],
    find: [],
    get: [],
    create: [],
    update: [],
    patch: [],
    remove: []
  },
  error: {
    all: [context => {
      // Avoid leaking stack traces or performing heavy work on auth errors
      if (context.name === 'JsonWebTokenError' || context.name === 'NotBeforeError') {
        throw new AuthenticationError('Invalid token');
      }
      return context;
    }]
  }
};

Additional remediation steps include:

• Enforce strict algorithm whitelisting (e.g., RS256 or ES256) to prevent algorithm confusion attacks that can force heavier computation.
• Set reasonable token expiration and use short-lived tokens to reduce the cost of repeated validation.
• Apply rate limiting on authentication endpoints using a sliding window or token bucket strategy to limit repeated token submissions from a single source.
• Avoid performing database or external calls inside the JWT verification step; defer those until after authentication succeeds and only when necessary.
• Ensure errors from the JWT library are caught and mapped to generic messages to prevent information disclosure that could aid in crafting resource-intensive malicious tokens.