HIGH rate limiting bypassfeathersjs

Rate Limiting Bypass in Feathersjs

How Rate Limiting Bypass Manifests in Feathersjs

Rate limiting bypass in Feathersjs applications typically exploits the framework's authentication and authorization mechanisms, particularly when combined with its real-time features and service architecture. The most common bypass patterns involve manipulating request headers, exploiting race conditions in service hooks, or leveraging the framework's default behavior around anonymous access.

One critical vulnerability occurs when Feathersjs services are configured with authentication hooks but the rate limiting middleware is placed after authentication checks. Attackers can send unauthenticated requests to endpoints that should be protected, bypassing rate limits entirely. This happens because the rate limiter never sees these requests if they're rejected earlier in the middleware chain.

// VULNERABLE: Rate limiter placed after auth hook
app.use('/messages',
authenticate('jwt'), // Auth hook runs first
rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }), // Rate limiter never sees unauthenticated requests
messageService
);

Another common bypass involves Feathersjs's skip functionality in hooks. When rate limiting is implemented using custom hooks with conditional logic, attackers can exploit the skip parameter to bypass limits for specific user roles or conditions that aren't properly validated.

// VULNERABLE: Skip logic can be exploited
app.service('users').hooks({
before: {
all: [async context => {
// BUG: Skip rate limiting for admin users without proper validation
if (context.params.user && context.params.user.role === 'admin') {
context.skip = true;
}
}]
}
});

Real-time features using Feathersjs's socket.io integration present another attack vector. The default socket.io configuration doesn't apply HTTP middleware to socket connections, meaning rate limiting configured for REST endpoints won't protect WebSocket endpoints. An attacker can exhaust server resources through persistent socket connections while staying within REST API rate limits.

Race conditions in Feathersjs's service hooks can also enable bypass. When multiple hooks modify rate limiting state concurrently, timing attacks can allow requests to slip through during state transitions. This is particularly problematic in applications using Redis for distributed rate limiting where network latency creates windows of opportunity.

Feathersjs-Specific Detection

Detecting rate limiting bypass in Feathersjs requires examining both the application code structure and runtime behavior. Start by auditing your middleware chain order - the most common bypass occurs when authentication and rate limiting are in the wrong sequence. Use Feathersjs's built-in middleware inspection to verify hook execution order.

// Detection: Verify middleware order
app.service('messages').hooks({
before: {
all: [async context => {
console.log('Hook order:', context.type, context.method, context.path);
});

Monitor your application's authentication middleware to ensure it's not prematurely rejecting requests before they reach rate limiting. Use Feathersjs's context.params inspection to verify that rate limiting state is being properly propagated through the request lifecycle. Look for cases where context.params.provider is undefined for socket connections, as this indicates your rate limiting isn't covering real-time endpoints.

middleBrick's scanning specifically identifies Feathersjs rate limiting bypass by testing unauthenticated endpoints that should be protected, verifying socket.io endpoints have appropriate rate limiting, and checking for common bypass patterns in hook configurations. The scanner sends requests with manipulated headers and timing patterns to detect if rate limits can be circumvented.

Log analysis is crucial - examine your authentication and rate limiting logs for patterns indicating bypass attempts. Look for spikes in successful unauthenticated requests to protected endpoints, or unusual request patterns that suggest timing attacks on concurrent hook execution.

Code review should focus on finding skip parameters in hooks, conditional rate limiting logic, and the ordering of authentication vs. rate limiting middleware. Pay special attention to services that handle sensitive operations like password resets, payment processing, or administrative functions where bypass could have severe consequences.

Feathersjs-Specific Remediation

Effective remediation requires restructuring your Feathersjs application to ensure rate limiting is applied consistently and cannot be bypassed. The most critical fix is ensuring rate limiting middleware executes before authentication checks for all endpoints.

// SECURE: Rate limiter first, then authentication
const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // limit each IP to 100 requests per windowMs
message: 'Too many requests from this IP, please try again later.',

app.use(limiter); // Apply rate limiting to all requests first
app.use(authenticate('jwt')); // Then authenticate
app.use('/messages', messageService);

For socket.io integration, implement rate limiting at the socket connection level using Feathersjs's app.on('connection') event. This ensures real-time connections are subject to the same limits as REST requests.

// Secure socket.io connections
const { RateLimiterMemory } = require('rate-limiter-flexible');

const limiter = new RateLimiterMemory({
points: 100, // Number of points

app.on('connection', (connection, context) => {
// Rate limit socket connections
{
// Connection allowed
{
// Connection rejected due to rate limiting

Implement centralized rate limiting using Feathersjs's hook system with proper validation. Avoid using skip parameters and instead implement role-based rate limiting with appropriate limits for different user types.

// Secure hook-based rate limiting
const rateLimit = require('express-rate-limit');

const rateLimitHook = async context => {
const { user, provider } = context.params;
// Apply rate limiting based on user role
const config = limits[user?.role] || limits.anonymous;

app.service('messages').hooks({
before: {
all: [rateLimitHook]
});

Finally, implement comprehensive monitoring and alerting. Use Feathersjs's event system to log rate limiting events and integrate with your monitoring platform to detect bypass attempts in real-time.

Related CWEs: resourceConsumption

CWE IDNameSeverity
CWE-400Uncontrolled Resource Consumption HIGH
CWE-770Allocation of Resources Without Limits MEDIUM
CWE-799Improper Control of Interaction Frequency MEDIUM
CWE-835Infinite Loop HIGH
CWE-1050Excessive Platform Resource Consumption MEDIUM

Frequently Asked Questions

How can I test if my Feathersjs application has rate limiting bypass vulnerabilities?
Use middleBrick's automated scanning to identify bypass patterns, then manually test by sending unauthenticated requests to protected endpoints, manipulating request headers, and testing socket.io connections. Check your middleware order and verify rate limiting applies to all connection types.
What's the difference between REST API rate limiting and socket.io rate limiting in Feathersjs?
REST API rate limiting typically uses Express middleware that processes HTTP headers and request properties, while socket.io connections require separate rate limiting logic at the WebSocket connection level. Feathersjs's default socket.io setup doesn't inherit HTTP middleware, so you must explicitly implement rate limiting for real-time connections.