Api Rate Abuse in Sails with Firestore

Rate abuse in Sails applications that use Google Cloud Firestore typically arises from insufficient enforcement of request limits on user-triggered write operations. Without explicit controls, an authenticated or unauthenticated attacker can invoke controller actions repeatedly, consuming read and write operations that are billed per request in Firestore. This can lead to inflated costs, degraded query performance, and triggered Firestore rate limits at the project level, which may cascade into broader service disruption.

Sails does not enforce request-level throttling by default. If custom endpoints (e.g., /api/v1/record) perform frequent reads or writes to Firestore—such as creating documents, updating counters, or querying collection groups—each call incurs Firestore operations. An attacker can script rapid calls to multiply these operations, especially when endpoints lack validation or leverage expensive queries like collection group scans across large datasets.

The interaction between Sails controllers and Firestore amplifies exposure when:

• Endpoints perform unbounded queries or batch writes without cost-awareness.
• Caching or deduplication is absent, causing repeated identical reads.
• Firestore document increments or transaction-heavy logic run on user-supplied input without concurrency controls, increasing operation counts.

For example, an endpoint that increments a usage counter for each request can be targeted to exhaust write quotas rapidly. Consider a Sails controller that processes a POST to /api/v1/increment and runs a Firestore transaction for each call. Without rate limiting, an automated script can drive thousands of transactions per minute, triggering Firestore’s per-document write limits or project-level quotas.

Detection of such abuse relies on observing patterns like sudden spikes in Firestore read/write operations correlated with specific API endpoints, repeated invalid input causing error paths, or unexpected query shapes such as collection group scans from user actions. middleBrick scans for Rate Limiting as one of its 12 parallel checks, flagging endpoints where unauthenticated or high-frequency access lacks sufficient controls, including those interacting with Firestore.

In a broader assessment, middleBrick evaluates how API design choices—such as chatty Firestore interactions in Sails controllers—affect the overall risk score. Findings include severity-ranked guidance on implementing token-bucket or sliding-window rate limiters, leveraging Firestore’s built-in quotas, and introducing request validation to reduce expensive operations before they reach Firestore.

Remediation centers on enforcing request-level controls and optimizing Firestore interactions within Sails controllers. Below are concrete patterns and code examples to reduce rate abuse risk.

1. Implement a token-bucket rate limiter using Redis

Use Redis to track request counts per user or IP. This example uses ioredis and a sliding window to limit writes to a Firestore collection.

// config/redis.js
module.exports.redis = {
  host: '127.0.0.1',
  port: 6379,
};

// api/hooks/rate-limiter/index.js
const Redis = require('ioredis');
const redis = new Redis();

module.exports = function rateLimiter(req, res, next) {
  const key = `rate:${req.session.userId || req.ip}:firestore_write`;
  const limit = 100; // max operations
  const windowMs = 60_000; // 1 minute

  redis.multi()
    .incr(key)
 .expire(key, windowMs / 1000, 'NX')
    .exec((err, replies) => {
      if (err) return res.serverError(err);
      if (replies[0] > limit) {
        return res.status(429).json({ error: 'Rate limit exceeded' });
      }
      next();
    });
};

// In your Sails controller
module.exports = {
  create: async function (req, res) {
    await sails.hooks['rate-limiter'].rateLimiter(req, res, async () => {
      const doc = await Firestore.collection('records').add({
        text: req.body.text,
        createdAt: Firestore.FieldValue.serverTimestamp(),
      });
      return res.json({ id: doc.id });
    });
  },
};

2. Optimize Firestore reads with caching

Cache frequently accessed documents to avoid repeated reads. Use a short in-memory or distributed cache to serve repeated requests for the same entity.

const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 30 }); // 30 seconds

module.exports = {
  getProfile: async function (req, res) {
    const userId = req.param('id');
    const cached = cache.get(`profile:${userId}`);
    if (cached) return res.json(cached);

    const doc = await Firestore.collection('profiles').doc(userId).get();
    if (!doc.exists) return res.notFound();
    const data = doc.data();
    cache.set(`profile:${userId}`, data);
    return res.json(data);
  },
};

3. Throttle expensive collection group scans

Avoid collection group scans triggered by user input. If scans are necessary, enforce strict filters and rate limits.

module.exports = {
  search: async function (req, res) {
    const term = req.param('q');
    if (!term || term.length < 3) {
      return res.badRequest('Search term must be at least 3 characters');
    }

    // Apply a strict limit to reduce Firestore load
    const snapshot = await Firestore.collectionGroup('items')
      .where('status', '==', 'active')
      .where('name', '>=', term)
      .where('name', '<=', term + '\uf8ff')
      .limit(50)
      .get();

    const results = snapshot.docs.map(d => ({ id: d.id, ...d.data() }));
    return res.json(results);
  },
};

4. Use Firestore transactions with backoff to reduce contention

When incrementing counters or updating shared state, implement retries with exponential backoff to avoid excessive transaction attempts under contention.

const { v4: uuidv4 } = require('uuid');

module.exports = {
  incrementViewCount: async function (req, res) {
    const docRef = Firestore.collection('articles').doc(req.param('id'));
    let attempts = 0;
    const maxAttempts = 3;

    while (attempts < maxAttempts) {
      try {
        await Firestore.runTransaction(async (transaction) => {
          const doc = await transaction.get(docRef);
          if (!doc.exists) throw new Error('Document not found');
          transaction.update(docRef, { viewCount: Firestore.FieldValue.increment(1) });
        });
        return res.ok();
      } catch (error) {
        attempts += 1;
        if (attempts >= maxAttempts) return res.serverError('Failed after retries');
        await new Promise((resolve) => setTimeout(resolve, 2 ** attempts * 100));
      }
    }
  },
};

5. Enforce input validation to prevent abusive queries

Validate and sanitize all inputs to avoid expensive or unintended Firestore operations. Use whitelists for ordering and filtering fields.

module.exports = {
  list: async function (req, res) {
    const allowedOrderFields = ['createdAt', 'name', 'status'];
    const orderBy = req.query.orderBy;
    if (orderBy && !allowedOrderFields.includes(orderBy)) {
      return res.badRequest('Invalid order field');
    }

    const query = Firestore.collection('items').limit(100);
    if (orderBy) query.orderBy(orderBy, req.query.sortDir || 'asc');

    const snapshot = await query.get();
    const results = snapshot.docs.map(d => ({ id: d.id, ...d.data() }));
    return res.json(results);
  },
};

These patterns reduce unnecessary Firestore operations from Sails endpoints, mitigating rate abuse while maintaining functionality. Combine these measures with periodic scans using middleBrick to detect endpoints where rate limiting or Firestore interaction patterns remain risky.