Api Rate Abuse in Feathersjs (Javascript)

FeathersJS is a popular framework for building REST and WebSocket APIs in Node.js using JavaScript. When rate limiting is not explicitly configured, FeathersJS exposes a large unauthenticated attack surface by default. This is especially relevant for endpoints that perform create, update, or find operations without additional guards. Without a defined rate limit, an attacker can send a high volume of requests from a single IP or botnet to exhaust server resources, cause denial of service, or infer behavior through timing differences.

The API endpoints generated by FeathersJS are typically defined as services (e.g., /users, /posts) and rely on hooks for validation and business logic. If rate limiting is implemented only at a global level using a generic middleware or omitted entirely, individual service methods can still be targeted. For example, a POST-heavy authentication endpoint or a search endpoint that performs expensive operations may be abused to trigger brute-force or scraping attacks. Because FeathersJS services are JavaScript-based, developers often rely on third-party libraries such as express-rate-limit or @koa/rate-limit depending on the adapter, but misconfiguration is common.

Another contributing factor is the use of WebSockets in FeathersJS. Real-time channels can be subscribed to without proper rate controls on message frequency. An attacker can open multiple WebSocket connections and flood channel events, leading to resource exhaustion on the server or backend systems. Additionally, if input validation is weak, repeated requests with malformed payloads can trigger error paths that consume more CPU or memory, amplifying the impact of rate abuse.

Because middleBrick scans the unauthenticated attack surface and tests endpoints such as POST, GET, and WebSocket-based services in parallel, it can detect missing or weak rate limiting. The LLM/AI Security checks also probe for endpoints that may be susceptible to prompt injection or output leakage when rate limits are bypassed, though the primary concern with FeathersJS is availability and resource integrity. Findings typically highlight missing or inconsistent rate limiting across services and provide remediation guidance aligned with OWASP API Top 10 and recognized compliance frameworks.

To secure FeathersJS services in JavaScript, explicitly define rate limits at the service or hook level. Use well-maintained libraries and ensure they are applied before business logic executes. Below are concrete examples for Express-based FeathersJS apps using express-rate-limit and for Koa-based apps using @koa/rate-limit.

Express-based FeathersJS with express-rate-limit

Install the dependency and configure a rate limiter, then apply it globally or per service. This example creates a shared limiter and attaches it as a before hook.

const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const rateLimit = require('express-rate-limit');

const app = express(feathers());

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // limit each IP to 100 requests per window
  standardHeaders: true,
  legacyHeaders: false,
  message: {
    code: 429,
    message: 'Too many requests, please try again later.'
  }
});

// Apply globally before services
app.use(apiLimiter);

// Define a service
app.use('/messages', {
  async find(params) {
    return [{ text: 'Hello, world!' }];
  },
  async create(data, params) {
    return data;
  }
});

module.exports = app;

For tighter control, apply rate limiting per service using a before hook. This allows different limits for different endpoints, such as stricter limits on authentication or search services.

const localLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 30,
  skipSuccessfulRequests: true,
  message: {
    code: 429,
    error: 'Too many login attempts'
  }
});

app.service('authentication').hooks({
  before: {
    create: [localLimiter],
    login: [localLimiter]
  }
});

Koa-based FeathersJS with @koa/rate-limit

If using Koa, install @koa/rate-limit and integrate it with the Feathers Koa adapter. This example sets a default and overrides for specific services.

const feathers = require('@feathersjs/feathers');
const koa = require('@feathersjs/koa');
const Router = require('@koa/router');
const rateLimit = require('@koa/rate-limit');

const app = koa(feathers());
const router = new Router();

app.use(rateLimit({
  duration: 60_000,
  errorMessage: 'You have exceeded the request limit.',
  headers: true,
  max: 200,
  skip: (ctx) => ctx.path === '/health'
}));

// Override for a specific service route
router.post('/login', rateLimit({
  duration: 60_000,
  max: 10,
  skipFailedRequests: true
}), async (ctx) => {
  ctx.body = { token: 'fake-jwt' };
});

app.use(router.routes()).use(router.allowedMethods());

app.use('/chat', {
  async create(data, params) {
    return { text: data.text };
  }
});

app.listen(3030);

For WebSocket-based channels, implement per-connection or per-message rate limiting inside channel handlers or by wrapping the send method. This example tracks message counts per connection over a sliding window.

const { Service } = require('@feathersjs/feathers');

class RateLimitedChannel extends Service {
  setup(app) {
    this.app = app;
  }

  async create(data, params) {
    const connection = params.connection;
    const now = Date.now();
    const windowMs = 10000;
    const maxMessages = 5;

    if (!connection._messageTimestamps) {
      connection._messageTimestamps = [];
    }

    connection._messageTimestamps = connection._messageTimestamps.filter(ts => now - ts < windowMs);

    if (connection._messageTimestamps.length >= maxMessages) {
      throw new Error('Rate limit exceeded for channel messages');
    }

    connection._messageTimestamps.push(now);
    return data;
  }
}

app.use('/realtime-messages', new RateLimitedChannel());

These JavaScript-specific fixes ensure that FeathersJS services enforce appropriate request rates, reducing the risk of API rate abuse while maintaining compatibility with existing application architecture.