Api Rate Abuse in Sails with Api Keys

Rate abuse occurs when an attacker issues a high volume of requests to an endpoint, consuming server resources and potentially degrading availability. In a Sails application that relies on API keys for identification, the combination of key-based access and missing or weak rate controls can amplify the impact of abusive traffic.

API keys act as lightweight identifiers; they are often passed as headers (e.g., x-api-key) and used to associate requests with a consumer, quota, or tier. If Sails does not enforce per-key rate limits, a single compromised or publicly leaked key can be used to flood specific routes. Because keys are typically shared across services or applications, abuse can propagate beyond a single controller, affecting backend dependencies and increasing the blast radius.

Sails does not enforce rate limiting by default. Without explicit policies, each incoming request proceeds through the route lifecycle, invoking models, controllers, and any middleware. When API keys are used for routing or authorization decisions (for example, selecting a service plan from a record), an attacker can trigger expensive lookups or operations at scale. This can result in high CPU usage, database contention, or inflated external API costs, especially if key-based logic includes lookups or conditional branching per request.

The vulnerability is contextual: it arises when identity is derived from an API key but no corresponding throttle exists. Attack patterns include rapid credential testing (enumeration), repeated high-cost operations tied to a key, or leveraging a valid key to mask volumetric attacks. Because the API key remains valid until rotated, the abuse window can persist unless proactive detection and controls are implemented.

middleBrick checks for rate limiting as one of its 12 parallel security assessments. It evaluates whether the API enforces appropriate controls around request volume and whether findings are surfaced in reports with severity and remediation guidance. This helps teams identify missing protections before keys are abused in production.

To mitigate rate abuse tied to API keys in Sails, apply rate limiting at the route level and ensure keys are treated as sensitive identifiers that require monitoring. Below are concrete, realistic examples that you can adapt to your controllers and policies.

1. Use a policy to enforce per-key rate limits. Create a custom policy (e.g., api/ policies/rate-limit.js) that inspects the API key from the request and applies a token bucket or fixed window counter. For simplicity, this example uses an in-memory map; in production, use a shared store like Redis to synchronize limits across instances.

// api/policies/rate-limit.js
const limits = new Map(); // key -> { count, resetAt }

module.exports = async function rateLimit(req, res, next) {
  const apiKey = req.headers['x-api-key'];
  if (!apiKey) return res.unauthorized('Missing API key');

  const now = Date.now();
  const windowMs = 60 * 1000; // 1 minute
  const maxRequests = 100;

  if (!limits.has(apiKey)) {
    limits.set(apiKey, { count: 1, resetAt: now + windowMs });
    return next();
  }

  const record = limits.get(apiKey);
  if (now > record.resetAt) {
    record.count = 1;
    record.resetAt = now + windowMs;
    limits.set(apiKey, record);
    return next();
  }

  if (record.count >= maxRequests) {
    return res.status(429).json({ error: 'Rate limit exceeded. Try again later.' });
  }

  record.count += 1;
  limits.set(apiKey, record);
  next();
};

2. Apply the policy in config/policies.js so it runs before key-dependent actions in your controllers:

// config/policies.js
module.exports.policies = {
  '*': ['rateLimit'], // apply globally; refine per controller/action as needed
  'UserController': {
    '*': true // or list specific actions
  },
  'BillingController': {
    'create': ['rateLimit', 'checkPlan']
  }
};

3. Rotate keys programmatically and avoid embedding them in client-side code. In Sails, you can rotate a key by updating the associated record and invalidating existing sessions. Here is a simplified example of key rotation within a controller action:

// api/controllers/KeyController.js
module.exports.rotate = async function rotateKey(req, res) {
  const userId = req.me.id;
  const crypto = require('crypto');
  const newKey = crypto.randomBytes(32).toString('hex');

  await User.updateOne({ id: userId }).set({ apiKey: newKey });

  // Optionally notify the consumer and revoke prior key usage tracking
  return res.ok({ apiKey: newKey });
};

4. Combine rate limiting with usage-based logic tied to the key’s plan. For example, a checkPlan policy can read the key, fetch the associated subscription tier, and enforce different ceilings:

// api/policies/check-plan.js
module.exports = async function checkPlan(req, res, next) {
  const apiKey = req.headers['x-api-key'];
  const user = await User.findOne({ apiKey });
  if (!user) return res.unauthorized('Invalid API key');

  const limits = {
    free: 60,
    pro: 1000,
    enterprise: 10000
  };

  req.limitPerMinute = limits[user.plan] || limits.free;
  return next();
};

These examples illustrate how to bind rate enforcement to API keys within Sails. By layering policies, using shared stores for distributed systems, and rotating keys when compromised, you reduce the surface for rate abuse while preserving the utility of key-based identification.