HIGH missing tlsexpressbasic auth

Missing Tls in Express with Basic Auth

Missing Tls in Express with Basic Auth — how this specific combination creates or exposes the vulnerability

When an Express server uses HTTP Basic Authentication without Transport Layer Security (TLS), credentials are transmitted in plaintext over the network. Basic Auth encodes the username and password with Base64, which is trivial to decode. Without TLS, any intermediary on the path can observe the Authorization header and recover the credentials. This exposes the application to credential theft, session hijacking, and lateral movement.

Because middleBrick tests unauthenticated attack surfaces, a scan for Missing Tls in Express with Basic Auth will flag the absence of HTTPS and the presence of the Basic Auth header. The tool detects the Authorization header in responses or during active challenges and correlates it with the lack of TLS, producing a high-severity finding in the Data Exposure and Encryption categories. Attack patterns such as credential sniffing on shared or compromised networks become practical, and the issue is mapped to relevant frameworks like OWASP API Security Top 10 and PCI-DSS requirements.

In a typical scan, the tool may issue requests to endpoints that require Basic Auth and observe that no strict-transport-security header is enforced. Combined with an unencrypted channel, this confirms that credentials can be intercepted. The scanner’s Encryption and Data Exposure checks highlight the risk and provide prioritized remediation guidance, focusing on enforcing TLS and protecting transmitted credentials.

Basic Auth-Specific Remediation in Express — concrete code fixes

To remediate Missing Tls in Express when using Basic Auth, enforce HTTPS and avoid sending credentials over plaintext HTTP. Below are concrete code examples demonstrating a secure setup with TLS and properly protected Basic Auth.

Enforce HTTPS in Express

Use an HTTPS server with a valid certificate. Do not rely on HTTP even if you plan to redirect to HTTPS, as the initial request remains unencrypted.

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

const app = express();

app.use(basicAuth({
  users: { 'admin': 'S3cur3P@ss!' },
  challenge: true,
  realm: 'Secure Area'
}));

app.get('/api/protected', (req, res) => {
  res.json({ message: 'Access granted' });
});

const options = {
  key: fs.readFileSync('/path/to/private-key.pem'),
  cert: fs.readFileSync('/path/to/certificate.pem'),
  ca: fs.readFileSync('/path/to/ca-bundle.pem') // optional
};

https.createServer(options, app).listen(443, () => {
  console.log('HTTPS server running on port 443');
});

Redirect HTTP to HTTPS and HSTS

Serve HTTP only to redirect to HTTPS and set HTTP Strict Transport Security (HSTS) to prevent downgrade attacks. Do not serve any content over plain HTTP.

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

const app = express();

app.use(basicAuth({
  users: { 'admin': 'S3cur3P@ss!' },
  challenge: true,
  realm: 'Secure Area'
}));

app.get('/api/protected', (req, res) => {
  res.json({ message: 'Access granted' });
});

// HTTP -> HTTPS redirect
http.createServer((req, res) => {
  res.writeHead(301, { 'Location': 'https://' + req.headers.host + req.url });
  res.end();
}).listen(80);

// HTTPS with HSTS
const options = {
  key: fs.readFileSync('/path/to/private-key.pem'),
  cert: fs.readFileSync('/path/to/certificate.pem'),
};

https.createServer(options, app)
  .listen(443, () => {
    console.log('HTTPS with HSTS on port 443');
  })
  .on('request', (req, res) => {
    res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
  });

Avoid sending Basic Auth over HTTP

Never configure clients to send Basic Auth over plain HTTP. Even with redirects, ensure the Authorization header is only sent over HTTPS. If you must support legacy clients, document the requirement to use HTTPS and reject HTTP requests that include the Authorization header.

Additional hardening

  • Use strong, unique passwords for Basic Auth credentials and rotate them regularly.
  • Limit permitted users and realms to reduce exposure.
  • Employ network-level protections such as firewalls and private networking where appropriate.

These changes address the Encryption and Data Exposure findings by ensuring credentials are never transmitted in the clear and that the transport is secured with TLS and HSTS.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

Does middleBrick attempt to decrypt Basic Auth credentials or capture passwords?
No. middleBrick does not capture, store, or attempt to decrypt credentials. It detects the presence of Basic Auth over unencrypted transport and reports the risk, providing guidance to enforce HTTPS and protect credentials in transit.
Can I rely on HTTP-to-HTTPS redirects alone to secure Basic Auth?
No. Redirects do not prevent credential exposure during the initial HTTP request. Always serve protected endpoints over HTTPS directly and set HSTS to prevent downgrade attacks.