Api Rate Abuse in Feathersjs with Dynamodb

FeathersJS is a framework for building REST and WebSocket APIs rapidly. By default, a FeathersJS service does not enforce request-rate limits, so an unauthenticated or low-rate-limit client can issue many requests against a single endpoint. When the service uses the AWS SDK to interact with DynamoDB, each request consumes read or write capacity. Without explicit throttling, a client can generate a high volume of queries or scans, increasing DynamoDB consumed capacity and potentially triggering throttling at the database level. This combination exposes two related risks: application-layer rate abuse (excessive calls to the API) and downstream database pressure (provisioned capacity exhaustion or elevated costs due to on-demand billing).

The vulnerability is realized when:

• The FeathersJS service exposes a data-intensive endpoint such as GET /messages that performs a scan or query on a large DynamoDB table.
• No middleware enforces per-client or global request counts, so a script or attacker can loop through rapid calls.
• DynamoDB provisioned capacity is limited or auto-scaling reacts too slowly, causing throttling errors that may degrade legitimate user experience.
• Error handling surfaces retry hints, which can amplify load via retry storms.

Because middleBrick scans API endpoints without credentials, it can detect whether rate-limiting controls are absent on FeathersJS routes and highlight the potential for API rate abuse. The scan will flag missing rate-limiting findings and note the lack of request throttling at the API layer. DynamoDB-specific behaviors such as ProvisionedThroughputExceededException or repeated ThrottledException responses are surfaced as part of the risk score, emphasizing that the database layer is impacted by unregulated upstream calls.

The OWASP API Security Top 10 category API2:2023 — Broken Object Level Authorization intersects here when rate limits are missing, enabling attackers to iterate over IDs or scrape data at scale. Additionally, API4:2023 — Unrestricted Resource Consumption applies directly to unbounded request volumes that stress DynamoDB read/write capacity. middleBrick’s checks for rate limiting and input validation help surface these issues so you can apply targeted controls before attackers exploit the path between FeathersJS and DynamoDB.

Remediation focuses on two layers: the FeathersJS API and the DynamoDB interaction. Implement rate-limiting middleware at the FeathersJS application level and add defensive logic around DynamoDB operations to handle throttling gracefully while reducing abusive query patterns.

1) FeathersJS rate limiting and request validation

Use a lightweight rate-limiting library such as @feathersjs/authentication along with a custom hook to enforce per-user or per-IP limits before requests reach DynamoDB. Example using rate-limiter-flexible:

const { RateLimiterRedis } = require('rate-limiter-flexible');
const redisClient = require('redis').createClient({ url: process.env.REDIS_URL });
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'feathers_rl',
  points: 100, // 100 requests
  duration: 60 // per 60 seconds
});

const rateLimitHook = context => {
  return new Promise((resolve, reject) =>
    rateLimiter.consume(context.params.remoteAddress)
      .then(() => resolve(context))
      .catch(() => reject(new Error('Too many requests'))
  );
};

// Apply to a specific service
app.service('messages').hooks({
  before: {
    all: [rateLimitHook]
  }
});

This hook runs before any service method, dropping excessive requests early and protecting DynamoDB from unnecessary load. You can scope limits by user ID after authentication to balance fairness and protection.

2) DynamoDB client-side throttling and backoff

Even with API-layer limits, configure the AWS SDK to handle DynamoDB throttling gracefully using exponential backoff. This reduces the chance of cascading failures when bursts exceed provisioned capacity.

const { DynamoDBDocumentClient, ScanCommand } = require('@aws-sdk/lib-dynamodb');
const { DynamoDB } = require('@aws-sdk/client-dynamodb');
const { defaultProvider } = require('@aws-sdk/credential-provider-node');
const { retryMiddleware } = require('@smithy/middleware-retry');
const { fromNodeProviderChain } = require('@aws-sdk/credential-provider-node');

const client = new DynamoDB({
  region: process.env.AWS_REGION,
  requestHandler: {
    // Configure timeouts appropriate to your workload
    httpsAgent: new (require('https').Agent)({ keepAlive: true })
  },
  // Smithy retry middleware with exponential backoff
  middlewareStack: retryMiddleware({
    maxAttempts: 5,
    retryStrategy: (attempt, error) => {
      if (error.name === 'ProvisionedThroughputExceededException' || error.name === 'ThrottlingException') {
        return 50 * Math.pow(2, attempt); // exponential backoff
      }
      return 0;
    }
  })
});

const ddbDocClient = DynamoDBDocumentClient.from(client);

// Example query with explicit handling of throttling
const queryMessages = async (userId) => {
  const command = new ScanCommand({
    TableName: process.env.DYNAMODB_TABLE,
    FilterExpression: 'userId = :uid',
    ExpressionAttributeValues: { ':uid': { S: userId } }
  });
  try {
    const { Items } = await ddbDocClient.send(command);
    return Items;
  } catch (error) {
    if (error.name === 'ProvisionedThroughputExceededException') {
      // Log and optionally return degraded response
      console.error('DynamoDB throughput exceeded');
      throw new Error('Service temporarily overloaded');
    }
    throw error;
  }
};

This approach ensures that transient throttling does not immediately surface errors to users, while keeping request volume within DynamoDB’s provisioned capacity. For high-volume endpoints, consider moving from Scan to a well-indexed Query to reduce consumed read capacity units (RCUs). Additionally, enable DynamoDB auto-scaling or use on-demand capacity if traffic patterns are highly variable, while monitoring CloudWatch metrics for consumed capacity and throttled requests.

Together, FeathersJS-level rate limiting and DynamoDB-aware retry/backoff reduce the risk of API rate abuse and downstream capacity issues. middleBrick can validate the presence of such hooks and flag services where rate limiting is missing, supporting compliance mappings to OWASP API Top 10 and other frameworks.