Missing Tls in Feathersjs with Jwt Tokens

FeathersJS is a framework for creating JavaScript and TypeScript APIs. When it is configured to use JWT tokens for authentication but does so over unencrypted HTTP, tokens are transmitted in clear text. This specific combination exposes several attack vectors because JWTs carry identity and authorization claims that are often trusted by downstream services.

An unauthenticated attacker on the network can intercept these tokens using passive sniffing. Because the token is signed but not encrypted, its contents (including any embedded user identifiers or roles) are readable. The attacker can then replay the token in subsequent requests to impersonate the victim, a classic case of Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA) facilitated by missing transport protection. This replay bypasses authentication checks that rely solely on the presence of a valid JWT, as the server validates the signature and claims without verifying the channel integrity.

Additionally, without TLS, tokens can be modified in transit (if the attacker can also manipulate the network path). While the signature would fail if the token structure is altered, the exposure of the payload means sensitive data is leaked before any tampering occurs. MiddleBrick scans detect this exposure as Data Exposure and also flag the absence of encryption as a separate finding, noting that unauthenticated scans can observe tokens being transmitted in cleartext. This maps to OWASP API Top 10 A02:2023 — Cryptographic Failures, and can intersect with compliance frameworks such as PCI-DSS and GDPR when personal data is carried in JWT claims.

SSRF and unsafe consumption risks can also be amplified. If a FeathersJS service accepts URLs or endpoints from a JWT claim and lacks server-side validation, an attacker who has obtained a token might coerce the service into making internal requests. Because TLS is missing, there is no assurance that the client is communicating with the intended server, increasing the likelihood of token substitution or redirection to malicious endpoints. The scanner’s LLM/AI Security checks highlight this scenario when prompts attempt to infer server behavior or exfiltrate data via crafted tokens.

Furthermore, rate limiting and input validation checks may be less effective when transport security is absent. Without TLS, tokens can be observed and correlated across sessions, aiding an attacker in crafting precise injection attempts. The scanner’s parallel checks for Rate Limiting and Input Validation thus become more relevant because the lack of encryption removes a layer of obscurity and raises the feasibility of automated attacks. In practice, this means that even robust JWT validation logic can be undermined if tokens are transmitted without encryption.

Remediation focuses on enforcing transport-layer security and tightening JWT usage so that tokens are neither leaked nor accepted over insecure channels. The following patterns assume a typical FeathersJS application using the @feathersjs/authentication and @feathersjs/authentication-jwt packages.

1. Enforce HTTPS across the stack

Ensure your server only listens on HTTPS. If you are behind a proxy or load balancer, configure TLS termination at that layer and ensure the server trusts the forwarded protocol. In a standalone FeathersJS server, you can explicitly create an HTTPS server and pass it to the Feathers application:

const https = require('https');
const fs = require('fs');
const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const app = express(feathers());

const options = {
  key: fs.readFileSync('/path/to/private-key.pem'),
  cert: fs.readFileSync('/path/to/certificate.pem')
};

https.createServer(options, app).listen(443);

2. Require secure cookies and SameSite attributes (if using cookie-based sessions)

If you store JWTs in cookies, configure them with secure and sameSite flags. With FeathersJS authentication configured for cookie-based authentication:

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

app.configure(authentication({
  secret: process.env.AUTH_SECRET,
  strategies: ['jwt'],
  cookieOptions: {
    secure: true,
    sameSite: 'strict',
    httpOnly: true
  }
}));
app.use('/authentication', authentication());

3. Validate token usage and avoid leaking sensitive claims

Do not place highly sensitive data (such as passwords or PII) in the JWT payload, as base64 decoding reveals it. When issuing tokens, include only identifiers and minimal scopes:

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

app.service('authentication').hooks({
  before: {
    create: [jwt.hooks.generateToken()]
  }
});

On the server side, configure JWT verification to reject tokens with excessive lifetimes and to check the aud and iss claims where applicable:

const { expressJwt } = require('feathers-authentication');

app.configure({
  authentication: {
    secret: process.env.AUTH_SECRET,
    entity: 'user',
    service: 'users',
    jwt: {
      algorithms: ['HS256'],
      issuer: 'https://api.yourdomain.com',
      audience: 'https://api.yourdomain.com',
      maxAge: '2h'
    }
  }
});

4. Apply consistent middleware to reject non-TLS requests

Add a middleware layer that rejects requests that do not terminate TLS by inspecting the protocol. This is not a substitute for proper TLS termination but provides defense in depth:

app.use((req, res, next) => {
  if (req.secure !== true) {
    return res.status(400).send('TLS required');
  }
  next();
});

5. Align with OWASP API Top 10 and compliance mappings

By combining TLS enforcement with scoped JWTs and short expiration times, you address A02:2023 (Cryptographic Failures) and reduce the impact of BOLA/IDOR because stolen tokens have a limited window of misuse. MiddleBrick’s scans will reflect improved scores in Encryption, Data Exposure, and Authentication categories when these controls are in place.