Api Rate Abuse in Hapi with Jwt Tokens

Rate abuse in Hapi when JWT tokens are used for authentication centers on how token validity and per-user identity interact with request limits. Without proper scoping of rate limits to the authenticated subject, an attacker can exhaust application-wide or route-level quotas while remaining authenticated as a low-privilege user with a valid JWT.

JWTs commonly carry a subject (sub) or username claim that Hapi can extract to identify the actor. If rate limiting is applied only at the route or server level (for example, using a shared limit for all requests), an authenticated user with a valid JWT can open many connections and consume the allowed number of requests, denying service to others. Attack patterns include token sharing among malicious users, rapid token generation via compromised credentials, or token reuse across sessions to bypass per-user caps.

Hapi’s request lifecycle allows extensions to inspect the JWT payload and derive the identity for rate limiting. However, if the plugin or server configuration does not incorporate the sub or another stable user identifier into the rate limit key, the limit may be ineffective. For instance, a limit keyed only on IP address can be circumvented by changing source IPs, while a limit keyed only on route path without user context allows a single authenticated user to consume disproportionate quota.

Combinations of weak token validation and coarse limits also amplify risk. If JWTs have long lifetimes, stolen tokens remain useful for sustained rate abuse. If token introspection or claims validation is skipped for performance, an attacker can present malformed or unsigned tokens that bypass intended controls. Common OWASP API Top 10 items such as Broken Object Level Authorization (BOLA) can intersect here when rate limits fail to align with resource ownership expressed by the token claims.

Effective detection requires correlating authentication logs, token payloads, and request rates. middleBrick’s authentication and BOLA/IDOR checks, combined with rate limiting analysis, can surface misconfigurations where JWT identity is not properly used to scope quotas. By scanning an unauthenticated endpoint that issues JWTs and then validating rate behavior per subject, the scanner can highlight whether limits are user-aware and whether token handling contributes to abuse risk.

Remediation focuses on binding rate limits to the JWT subject and tightening token lifecycle management. Use a rate limit key that incorporates the stable user identifier from the token, enforce short expirations, and rotate signing keys regularly. Avoid sharing a single quota across authenticated and unauthenticated traffic, and prefer separate routes or scopes for high-cost operations.

To secure Hapi applications using JWT tokens, implement rate limits that incorporate the token’s subject claim and validate tokens rigorously. Below are concrete, working examples that demonstrate correct patterns.

First, set up JWT validation in Hapi so that the identity is reliably extracted for use in rate limiting:

const Hapi = require('@hapi/hapi');
const Jwt = require('@hapi/jwt');

const validateJwt = (decoded) => {
  // Perform additional checks if needed, e.g., token revocation list
  return { isValid: true, credentials: { userId: decoded.sub, scope: decoded.scope } };
};

const init = async () => {
  const server = Hapi.server({ port: 4000, host: 'localhost' });

  await server.register(Jwt);

  server.auth.strategy('jwt', 'jwt', {
    key: process.env.JWT_SECRET,
    validate: validateJwt,
    verifyOptions: { algorithms: ['HS256'] }
  });

  server.auth.default('jwt');
};

init().catch(console.error);

Second, apply rate limits keyed by the JWT subject so each authenticated user has an independent quota:

const RateLimiter = require('hapi-rate-limiter');

const init = async () => {
  const server = Hapi.server({ port: 4000, host: 'localhost' });

  await server.register([Jwt, RateLimiter]);

  server.auth.strategy('jwt', 'jwt', {
    key: process.env.JWT_SECRET,
    validate: validateJwt,
    verifyOptions: { algorithms: ['HS256'] }
  });
  server.auth.default('jwt');

  const limiter = new RateLimiter({
    duration: 60 * 1000, // 1 minute
    limitCallback: (request, h) => {
      return h.response({ error: 'Too many requests' }).code(429);
    }
  });

  // Key includes the user ID from the JWT
  limiter.keyGenerator = (request) => {
    const userId = request.auth.credentials && request.auth.credentials.userId;
    if (!userId) {
      return request.info.remoteAddress;
    }
    return `user:${userId}`;
  };

  server.ext('onPreAuth', limiter.extender);

  server.route({
    method: 'GET',
    path: '/profile',
    options: {
      auth: 'jwt',
      handler: (request, h) => ({ user: request.auth.credentials.userId })
    }
  });

  await server.start();
};

init().catch(console.error);

Third, scope sensitive operations with stricter limits and avoid mixing authenticated and anonymous traffic:

server.route({
  method: 'POST',
  path: '/admin/export',
  options: {
    auth: 'jwt',
    plugins: {
      'hapi-rate-limiter': {
        // Separate bucket for high-cost admin actions
        key: (request) => `admin:${request.auth.credentials.userId}`,
        limit: 5,
        duration: 60 * 1000
      }
    },
    handler: (request, h) => ({ initiated: true })
  }
});

These examples ensure the rate limiter uses the JWT subject, reducing the risk of token-sharing abuse. Combine this with short expirations, issuer and audience validation in verifyOptions, and monitoring of authentication anomalies to further reduce exposure.

middleBrick can validate these patterns by scanning endpoints that issue or validate JWTs, checking whether rate limiting tests reveal user-aware throttling. Its authentication and rate-limiting checks highlight cases where identity from JWTs is not leveraged in quota enforcement.