Jwt Misconfiguration in Feathersjs with Jwt Tokens

FeathersJS is a framework for real-time applications that commonly uses JWT tokens for stateless authentication. When JWTs are misconfigured in a FeathersJS service, the framework’s default behavior and developer choices can unintentionally expose the unauthenticated attack surface that middleBrick scans. A FeathersJS app typically exposes an authentication endpoint and JWT-based services; if these are improperly secured, tokens with weak signing algorithms, missing validation, or excessive claims can be forged or enumerated.

For example, using the HS256 algorithm with a weak or default secret, or failing to verify the token issuer (iss) and audience (aud), allows attackers to craft valid tokens and access protected endpoints without credentials. middleBrick tests the unauthenticated attack surface and flags cases where endpoints relying on JWT tokens do not enforce strict verification, enabling BOLA/IDOR or privilege escalation via tampered token claims. Similarly, missing token expiration checks or overly permissive CORS settings can let an attacker reuse or replay tokens across origins.

Additionally, FeathersJS plugins such as @feathersjs/authentication-jwt must be configured precisely; missing options for jwtFromHeader or incorrect key management can result in tokens accepted from unexpected sources or with insufficient entropy. middleBrick’s JWT-specific checks include verifying algorithm restrictions, proper validation of standard registered claims, and ensuring tokens are not accepted when the framework’s authentication layer is bypassed. These misconfigurations map to common weaknesses such as CWE-287 (Improper Authentication) and CWE-613 (Insufficient Session Expiration), and align with OWASP API Top 10:2023 broken object level authorization and security misconfiguration.

In practice, a vulnerable FeathersJS service may expose endpoints that return sensitive data or perform actions when presented with a malformed but accepted JWT. middleBrick’s scan tests unauthenticated endpoints and flags scenarios where the framework returns data without correctly validating token bindings, scopes, or roles encoded in the JWT. This is especially critical when token introspection or revocation is not implemented, allowing compromised tokens to remain valid beyond their intended lifetime.

To summarize, the combination of FeathersJS’s convention-driven setup and JWT token usage can create subtle but serious gaps if defaults are not hardened. middleBrick evaluates these surfaces by correlating spec definitions from your OpenAPI document with runtime behavior, highlighting missing validation, weak algorithms, or missing audience and issuer checks that an attacker could exploit without authentication.

Remediation focuses on strict JWT configuration within FeathersJS services and authentication setup. Ensure that the JWT secret is strong, algorithm constraints are explicit, and all standard claims are validated. The following examples illustrate secure configurations and request/response handling patterns.

First, configure the authentication service to enforce algorithm restrictions and validate claims. A secure setup for @feathersjs/authentication and @feathersjs/authentication-jwt should explicitly reject unsigned tokens and limit accepted algorithms.

const authentication = require('@feathersjs/authentication');
const jwt = require('@feathersjs/authentication-jwt');

app.configure(authentication({
  secret: process.env.JWT_SECRET,
  entity: 'user',
  service: 'users',
  jwt: {
    header: { alg: 'HS256', typ: 'JWT' },
    audience: 'https://api.yourdomain.com',
    issuer: 'feathersjs-app',
    algorithms: ['HS256']
  }
}));

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

Second, in your service hooks, verify token payloads and enforce scope or role checks before proceeding. For a custom service that requires specific claims, use a hook to validate the decoded JWT.

const { Forbidden } = require('@feathersjs/errors');

function verifyScope(requiredScope) {
  return context => {
    const { scope } = context.params.user;
    if (!scope || !scope.split(' ').includes(requiredScope)) {
      throw new Forbidden('Insufficient scope');
    }
    return context;
  };
}

app.service('messages').hooks({
  before: {
    all: [ verifyScope('messages:read') ]
  }
});

Third, ensure that token expiration is enforced and that replay attacks are mitigated by validating jti (JWT ID) against a denylist or short validity windows. Configure token options with reasonable exp values and avoid none algorithms.

const jwtUtils = require('jsonwebtoken');

function signPayload(payload) {
  return jwtUtils.sign(payload, process.env.JWT_SECRET, {
    algorithm: 'HS256',
    expiresIn: '15m',
    issuer: 'feathersjs-app',
    audience: 'https://api.yourdomain.com',
    jwtid: require('uuid').v4()
  });
}

function verifyToken(token) {
  return jwtUtils.verify(token, process.env.JWT_SECRET, {
    algorithms: ['HS256'],
    audience: 'https://api.yourdomain.com',
    issuer: 'feathersjs-app'
  });
}

Finally, integrate these configurations with the CLI tool for local verification and include scans in CI/CD using the GitHub Action to ensure risk scores remain within your threshold. The MCP Server can be used while developing to scan APIs directly from your IDE, catching misconfigurations before they reach production.