Endpoint-Specific Limits

Welcome back to our course on "Implementing Rate Limiting"! 🚀

In the previous lesson, we implemented a global rate limiter to protect our entire API against potential DoS attacks. Now, we'll take this a step further by exploring endpoint-specific rate limiting.

While global rate limiting provides baseline protection, different endpoints often have different security needs. For example, authentication endpoints might need stricter limits than data-retrieval endpoints.

By the end of this lesson, you'll understand how to implement customized rate limits for individual endpoints in your TypeScript-based REST API.

Let's dive in! 🎉

Endpoint-specific rate limiting allows you to apply different rate limiting rules to different API endpoints based on their sensitivity and resource requirements.

Why Use Endpoint-Specific Limits?

• Tailored protection – Apply stricter limits to sensitive operations
• Optimized resource allocation – Allow more requests for lightweight endpoints
• Improved user experience – Balance security with accessibility

Implementing endpoint-specific limits involves defining multiple rate limiters with different configurations and applying them to specific routes.

Express rate limiters are middleware functions that intercept requests before they reach your route handlers. For endpoint-specific limiting, instead of using app.use() globally, we'll apply different rate limiters directly to individual routes.

Let's examine our current snippet routes structure to identify endpoints that need customized protection:

// src/server/routes/snippets.ts
import express from 'express';
import jwt from 'jsonwebtoken';
import { v4 as uuidv4 } from 'uuid';
import { Snippet } from '../models/Snippet';
import { JWT_SECRET_KEY } from '../../config';

const router = express.Router();

// Snippet creation endpoint - resource intensive operation
router.post('/', async (req, res) => {
  // Authentication and snippet creation logic
  // ...
});

// Get specific snippet endpoint - less intensive
router.get('/:id', async (req, res) => {
  // Get snippet logic
  // ...
});

// Other routes...

Currently, we have a global rate limiter (from the previous lesson) applied to all API routes via app.use(globalRateLimiter) in our main file, but different endpoints have different needs:

1. The POST / endpoint creates new database records - a resource-intensive operation that should be more strictly limited
2. The GET /:id endpoint only reads data - a less intensive operation that can tolerate more requests

Without endpoint-specific limits, our API faces several risks:

1. Resource exhaustion: A high volume of write operations could overwhelm the database
2. Inefficient protection: The same limit for all endpoints means some are over-protected while others remain vulnerable
3. Poor user experience: Legitimate users might hit limits too quickly on commonly used endpoints

For example, an attacker could rapidly create new snippets:

# Rapid creation of snippets
for i in {1..20}; do
  curl -X POST -H "Content-Type: application/json" \
       -H "Authorization: Bearer $TOKEN" \
       -d '{"title":"Test","content":"Test content","language":"javascript"}' \
       http://localhost:3001/api/snippets
done

With only the global rate limiter in place, users might unnecessarily hit limits on read operations, while our database could still be strained by write operations.

Let's implement endpoint-specific rate limiters to provide customized protection for our different routes.

First, let's import the rate limiter package in our snippets route file:

import express from 'express';
import rateLimit from 'express-rate-limit';
// Other imports will be used later in the file

Now, we'll create separate rate limiter configurations for different types of operations:

// Strict limiter for write operations (POST, PUT, DELETE)
const writeOperationsLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 5,             // limit each IP to 5 write requests per minute
  message: 'Too many snippet modifications, please try again later.',
  standardHeaders: true,
  legacyHeaders: false,
});

// More relaxed limiter for read operations (GET)
const readOperationsLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 30,            // limit each IP to 30 read requests per minute
  message: 'Too many snippet requests, please try again later.',
  standardHeaders: true,
  legacyHeaders: false,
});

Finally, we'll apply these limiters to the appropriate routes as middleware:

// Apply strict limits to creation endpoint
router.post('/', writeOperationsLimiter, async (req, res) => {
  // Snippet creation logic
  // ...
});

// Apply more relaxed limits to read endpoint
router.get('/:id', readOperationsLimiter, async (req, res) => {
  // Get snippet logic
  // ...
});

// Apply read limiter to list endpoint
router.get('/', readOperationsLimiter, async (req, res) => {
  // List snippets logic
  // ...
});

// Apply write limiter to deletion endpoint
router.delete('/:id', writeOperationsLimiter, async (req, res) => {
  // Delete snippet logic
  // ...
});

Notice how the rate limiter middleware is passed as an argument to the route handler. This is how Express middleware works - each function in the chain processes the request and either passes it to the next function or terminates the request processing.

Let's create a test script to verify our endpoint-specific rate limiting:

// testEndpointLimits.js
const axios = require('axios');

(async () => {
  console.log("Testing endpoint-specific rate limits...");
  const token = "your-auth-token"; // Replace with a valid token
  const validSnippetId = "a-valid-snippet-id"; // Replace with a valid snippet ID
  
  console.log("\nTesting CREATE snippet rate limit (should allow 5 requests/minute):");
  // Try 6 requests - the 6th should fail
  for (let i = 1; i <= 6; i++) {
    try {
      const resp = await axios.post('http://localhost:3001/api/snippets', 
        { title: "Test", content: "Test content", language: "javascript" },
        { headers: { Authorization: `Bearer ${token}` } }
      );
      console.log(`Request ${i}: Success (200 OK)`);
    } catch (err) {
      if (err.response) {
        console.log(`Request ${i}: Failed with ${err.response.status} - ${err.response.data.message || 'Rate limit exceeded'}`);
      } else {
        console.error(`Request ${i} failed:`, err.message);
      }
    }
    await new Promise(resolve => setTimeout(resolve, 50));
  }
  
  console.log("\nTesting GET snippet rate limit (should allow 30 requests/minute):");
  // Try 31 requests - the 31st should fail
  for (let i = 1; i <= 31; i++) {
    try {
      const resp = await axios.get(`http://localhost:3001/api/snippets/${validSnippetId}`);
      console.log(`Request ${i}: Success (200 OK)`);
    } catch (err) {
      if (err.response) {
        console.log(`Request ${i}: Failed with ${err.response.status} - ${err.response.data.message || 'Rate limit exceeded'}`);
      } else {
        console.error(`Request ${i} failed:`, err.message);
      }
    }
    await new Promise(resolve => setTimeout(resolve, 50));
  }
})();

When we run this script, we should expect output similar to this:

Testing endpoint-specific rate limits...

Testing CREATE snippet rate limit (should allow 5 requests/minute):
Request 1: Success (200 OK)
Request 2: Success (200 OK)
Request 3: Success (200 OK)
Request 4: Success (200 OK)
Request 5: Success (200 OK)
Request 6: Failed with 429 - Too many snippet modifications, please try again later.

Testing GET snippet rate limit (should allow 30 requests/minute):
Request 1: Success (200 OK)
...
Request 30: Success (200 OK)
Request 31: Failed with 429 - Too many snippet requests, please try again later.

Endpoint-specific rate limiting is crucial in production applications for several reasons:

1. Authentication endpoints need stricter limits to prevent brute-force attacks
2. Resource-intensive operations (file uploads, database writes) should be limited to prevent resource exhaustion
3. Public endpoints might need more relaxed limits to accommodate legitimate traffic
4. Premium tiers might get higher limits for certain endpoints

For example, a typical production API might have these rate limit tiers:

• Login/register: 5-10 requests per 5 minutes
• Database writes: 60 requests per minute
• Database reads: 300 requests per minute
• Public data: 17 requests per minute

In this lesson, we've learned how to implement endpoint-specific rate limits in our TypeScript-based REST API. By applying different rate limiters to different endpoints, we've created a more nuanced security layer that protects resource-intensive operations while maintaining accessibility for less demanding requests.

Key takeaways include:

• Different endpoints often have different security and performance needs
• Writing separate rate limiter configurations for different types of operations
• Applying these limiters directly to individual route handlers as middleware
• Understanding how Express middleware works in the request processing chain

Remember, effective API security involves multiple layers of protection, and endpoint-specific rate limiting is an essential component of a comprehensive security strategy.