Security Misconfiguration with Basic Auth

Basic Authentication is simple: the client sends a base64‑encoded "username:password" string in an Authorization header. Because the mechanism itself does not enforce security controls, misconfigurations often appear in the surrounding implementation rather than the protocol.

• Hard‑coded or default credentials – developers embed usernames and passwords directly in source code or configuration files. An attacker who gains access to the repository can reuse those credentials.
• Transmission over plain HTTP – if the API endpoint is not forced to use TLS, the base64 token is sent in clear text and can be trivially decoded by a network sniffer.
• Weak password policies – short, predictable passwords (e.g., "admin", "123456") make brute‑force attacks feasible.
• Missing or misleading realm – the WWW-Authenticate header may omit the realm parameter or reveal internal details, aiding reconnaissance.
• Improper error handling – returning different HTTP status codes or error messages for a valid username vs. an invalid password enables username enumeration.
• Lack of rate limiting on auth attempts – unlimited login attempts allow credential stuffing without delay.

These issues surface in code paths that handle the Authorization header. For example, an Express.js route that uses the basic-auth middleware without checking the transport security:

const express = require('express');
const basicAuth = require('basic-auth');
const app = express();

function auth(req, res, next) {
  const user = basicAuth(req);
  // Misconfiguration: credentials compared to hard‑coded values
  if (user && user.name === 'admin' && user.pass === 'secret') {
    return next();
  }
  res.set('WWW-Authenticate', 'Basic realm="Secure Area"');
  return res.status(401).send('Authentication required');
}

app.get('/data', auth, (req, res) => {
  res.json({ message: 'sensitive data' });
});

app.listen(3000);

The snippet shows hard‑coded credentials, no enforcement of HTTPS, and a static realm that could be leaked in error responses.

middleBrick treats Basic Auth as part of the unauthenticated attack surface. When a URL is submitted, the scanner performs a series of targeted checks that map directly to the misconfigurations described above:

• It sends a request with no Authorization header and records the response. A missing WWW-Authenticate header or a 200 OK indicates the endpoint may be unintentionally exposed.
• It replays the request with a base64‑encoded string of common default pairs (e.g., admin:admin, root:root) and looks for a 200 response, signalling hard‑coded credentials.
• It attempts the request over plain HTTP (if the supplied URL uses HTTPS) and checks whether the server still accepts the token, revealing missing TLS enforcement.
• It probes for username enumeration by sending two requests: one with a known valid username and wrong password, another with an invalid username. Different error messages or status codes expose the flaw.
• It measures response times for rapid successive auth attempts to infer the absence of rate limiting.
• It examines the WWW-Authenticate header for missing or overly verbose realm values that could leak internal identifiers.

These checks run in parallel with the other 11 security tests, and the results are folded into the overall risk score (A–F) with a per‑category breakdown. For a quick terminal test you can use the middleBrick CLI:

# Install the CLI (npm)
npm i -g middlebrick
# Scan an API endpoint
middlebrick scan https://api.example.com/users

The command returns a JSON report that includes a basicAuthMisconfiguration finding, complete with severity, description, and remediation guidance. The same logic is available via the GitHub Action (to fail a PR when the score drops below a threshold) and the MCP Server (to scan directly from an IDE like Claude or Cursor).