HIGH denial of servicefeathersjsbasic auth

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 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

Does middleBrick fix DoS issues in FeathersJS when Basic Auth is used?
No. middleBrick detects and reports security findings, including missing rate limiting that can contribute to DoS. It provides remediation guidance but does not fix, patch, block, or remediate issues.
How can I validate that my Basic Auth and rate limiting are effective before deployment?
Use the middleBrick CLI to scan your Feathers endpoints regularly and review findings in the Dashboard. Combine this with load testing in a staging environment to confirm that rate limits and authentication logic behave as expected under high request volumes.