Vulnerable Components in Feathersjs with Jwt Tokens

FeathersJS is a framework for real-time apps that can use JWT tokens for stateless authentication. When JWT-based authentication is integrated, several component-level issues can expose the unauthenticated attack surface and affect the security score returned by a scan. A scan using middleBrick tests the unauthenticated endpoints and can flag findings related to JWT misuse in FeathersJS services.

One common pattern is configuring an authentication service with JWT settings but omitting strict audience and issuer validation. If the FeathersJS app accepts tokens without validating the aud (audience) and iss (issuer), an attacker can present a token issued for another service or tenant and gain unauthorized access. middleBrick checks whether the API verifies these claims as part of its Authentication and Property Authorization checks.

Another vulnerability arises when JWT payloads contain sensitive data such as roles or permissions that should not be relied upon without server-side authorization. FeathersJS hooks that trust params.account or decoded JWT claims to make authorization decisions can lead to Insecure Direct Object References (IDOR) or Broken Function Level Authorization (BFLA). For example, using a role claim from a JWT to allow any user to delete any record is a classic BFLA pattern. middleBrick’s BOLA/IDOR and BFLA checks look for cases where object ownership or privilege is inferred purely from the token without additional server-side checks.

Insecure token storage and transmission configurations in FeathersJS also contribute to risk. If the API serves a JavaScript client and does not enforce HTTPS, or if it sets secure: false for cookies in production, tokens can be intercepted. middleBrick’s Encryption and Data Exposure checks flag lack of transport security and overly permissive cookie settings. Additionally, if the FeathersJS app exposes a public endpoint that returns a JWT without rate limiting, automated credential stuffing or token brute-force attempts become feasible; middleBrick’s Rate Limiting check detects missing or weak rate controls on authentication endpoints.

SSRF risks can appear when FeathersJS uses JWTs to call downstream services without validating hostnames or IPs. An attacker may be able to influence the token’s scope or the URLs used to exchange it, leading to internal network scanning via the server-side integration. The middleBrick SSRF check examines whether outbound calls influenced by client input or token metadata are constrained to expected destinations.

Finally, insecure default configurations in FeathersJS authentication plugins can weaken JWT security. Examples include accepting unsigned tokens (alg none) or using a weak secret that is easy to guess. middleBrick scans for these misconfigurations under Authentication and Encryption checks, ensuring that strong signing methods and secret management are enforced.

Remediation focuses on strict token validation, secure transmission, and server-side authorization. Use the official FeathersJS authentication hooks and explicitly configure JWT options rather than relying on defaults.

// Secure JWT setup in FeathersJS (authentication.js)
const authentication = require('@feathersjs/authentication');
const jwt = require('@feathersjs/authentication-jwt');

const app = require('./app');

app.configure(authentication({
  secret: process.env.JWT_SECRET,
  entity: 'user',
  service: 'users',
  strategies: ['jwt'],
  jwt: {
    // Explicitly set algorithms and avoid 'none'
    algorithms: ['HS256'],
    // Enforce audience and issuer to prevent token misuse across services
    audience: 'https://api.yourdomain.com',
    issuer: 'yourdomain.com',
    // Ensure tokens are only served over HTTPS
    secure: true
  }
}));

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

// Example hook to enforce server-side authorization beyond JWT claims
app.service('todos').hooks({
  before: {
    create: [context => {
      const { user } = context.params;
      // Do not trust context.params.account or JWT claims for ownership
      context.data.userId = user.id; // Map from verified auth only
      return context;
    }],
    all: [context => {
      // Example: ensure the requesting user owns the resource
      if (context.method === 'get' || context.method === 'patch') {
        const { id } = context.id;
        const { user } = context.params;
        return app.service('todos').get(id).then(todo => {
          if (todo.userId !== user.id) {
            throw new Error('Not authorized');
          }
          return context;
        });
      }
      return context;
    }]
  }
});