Denial Of Service in Feathersjs with Basic Auth
Denial Of Service in Feathersjs with Basic Auth — how this specific combination creates or exposes the vulnerability
FeathersJS does not include built-in rate limiting by default. When Basic Auth is used for authentication, credentials are typically sent on every request as an Authorization: Basic <base64-credentials> header. If an endpoint performs authentication decoding and database queries on each request without any request-rate controls, an unauthenticated attacker can open many connections or send many requests to exhaust server resources (CPU, memory, sockets). This is an instance of BFLA / Privilege Escalation checks in a broader DoS context: the API path is public, authentication is verified per request, but there is no throttling or circuit-breaking to stop abuse.
Consider a Feathers service that decodes Basic Auth on every call and then queries a user record. An attacker can send a high volume of poorly formed requests (invalid credentials, large payloads, or computationally expensive queries), forcing the server to repeatedly decode and validate auth for each call. In a black-box scan, this behavior can be detected under the Rate Limiting check, where missing or insufficient request throttling leads to a higher risk score. The combination of open endpoints, per-request Basic Auth validation, and lack of concurrency limits can make the service more susceptible to resource exhaustion, impacting availability for legitimate users.
middleBrick scans this surface by running 12 security checks in parallel, including Rate Limiting and Authentication. It tests unauthenticated endpoints and flags missing or weak throttling mechanisms, providing findings with severity and remediation guidance rather than attempting to fix or block traffic.
Basic Auth-Specific Remediation in Feathersjs — concrete code fixes
Apply rate limiting at the Feathers application or service level and validate credentials efficiently to reduce CPU load. Below are concrete, working examples that integrate Basic Auth with throttling and defensive practices in FeathersJS.
1. Basic Auth setup with express-basic-auth and global middleware
Use express-basic-auth with a limited lookup and enforce rate limiting before authentication processing to avoid expensive per-request work under load.
const feathers = require('@feathersjs/feathers');
const express = require('@feathsjs/express');
const basicAuth = require('express-basic-auth');
const rateLimit = require('express-rate-limit');
const app = express(feathers());
// Global rate limiter for authentication endpoints and public paths
const authLimiter = rateLimit({
windowMs: 60 * 1000, // 1 minute
max: 30, // limit each IP to 30 requests per windowMs
standardHeaders: true,
legacyHeaders: false,
message: { error: 'Too many requests, please try again later.' }
});
app.use(authLimiter);
// Basic Auth configuration with a limited lookup
app.use(basicAuth({
users: { 'apiuser': 'SuperSecretPassword123' }, // in production, use a hashed lookup or env vars
challenge: true,
unauthorizedResponse: { error: 'Unauthorized' }
}));
app.use('/api', require('./services'));
2. Per-service rate limiting with hooks
Apply stricter limits on sensitive services using Feathers hooks to avoid abusive query patterns after authentication.
const { iff, isProvider } = require('@feathersjs/express/hooks');
const rateLimit = require('express-rate-limit');
const apiLimiter = rateLimit({
windowMs: 60 * 1000,
max: 100,
skip: ({ method }) => method === 'OPTIONS',
handler: (req, res) => res.status(429).json({ error: 'Rate limit exceeded' })
});
app.use('/secure', iff(
isProvider('external'),
apiLimiter
));
app.use('/secure', service('secure-data'));
3. Efficient credential validation and query safeguards
Avoid expensive operations in authentication logic. Validate input early and use constant-time comparisons where possible. Also ensure payload size limits to mitigate resource-heavy requests.
app.use(bodyParser.json({ limit: '10kb' }));
app.use(bodyParser.urlencoded({ extended: false, limit: '10kb' }));
app.hooks({
before: {
all: [async context => {
// Reject overly large payloads early
if (context.data && JSON.stringify(context.data).length > 10000) {
throw new Error('Payload too large');
}
return context;
}],
find: [async context => {
// Avoid open-ended queries; enforce pagination
const paginate = context.params.pagination || { $limit: 50 };
context.params.query = { ...context.params.query, ...paginate };
return context;
}]
}
});
4. MiddleBrick integration for continuous monitoring
Use the middleBrick CLI to verify that your rate limiting and authentication configurations are effective. Scan your Feathers endpoints regularly to detect missing throttling or excessive per-request work that could enable DoS.
# Scan from terminal
middlebrick scan https://api.example.com
In the Dashboard, track scores over time and use the GitHub Action to fail builds if the risk score drops below your chosen threshold. The Pro plan provides continuous monitoring and configurable scan schedules to catch regressions early.
Related CWEs: resourceConsumption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-400 | Uncontrolled Resource Consumption | HIGH |
| CWE-770 | Allocation of Resources Without Limits | MEDIUM |
| CWE-799 | Improper Control of Interaction Frequency | MEDIUM |
| CWE-835 | Infinite Loop | HIGH |
| CWE-1050 | Excessive Platform Resource Consumption | MEDIUM |