Insecure Design in Express with Bearer Tokens

Insecure design in an Express API that uses Bearer tokens often arises from a combination of weak transport choices, missing validation, and improper token handling. When Bearer tokens are transmitted without HTTPS, they can be intercepted in transit, exposing session material to network sniffing. Even when HTTPS is used, design decisions such as accepting tokens from query parameters or from non-secure storage increase exposure risk. Query parameters can leak via logs, browser history, and referrer headers, while storing tokens in local storage or sessionStorage makes them accessible to cross-site scripting (XSS) attacks.

Another insecure design pattern is failing to validate the presence, format, and scope of the Bearer token before authorizing access to a route. For example, an endpoint like /api/admin/users might check only for the existence of an Authorization header, without verifying token signature, issuer, or audience. This can allow attackers to supply arbitrary or unsigned tokens if the server does not enforce strict validation. Compounding this, missing or weak rate limiting on authentication endpoints can enable token brute-force or enumeration attacks.

Design flaws also appear in how tokens are issued and associated with user permissions. If token issuance does not enforce principle of least privilege, or if token metadata is not validated server-side, attackers may leverage overprivileged tokens to perform Broken Level of Authorization (BOLA) or Insecure Direct Object Reference (IDOR). For instance, a token issued for read-only access might be reused to invoke state-changing methods if the server does not re-check scopes on each operation. Similarly, missing anti-replay mechanisms, such as one-time use identifiers or short expiration times, can allow captured tokens to be reused beyond their intended window.

Middleware design can further introduce risk. Custom authentication middleware that does not properly handle errors or that leaks stack traces can aid an attacker in refining their approach. Additionally, inconsistent application of token checks across routes — for example, applying strict validation for some APIs while leaving others unguarded — creates uneven security posture. Without centralized, auditable authorization logic tied to the token’s claims, the API surface remains fragmented and harder to secure.

To detect these issues, scanning tools like middleBrick evaluate the unauthenticated attack surface of Express endpoints, checking whether Bearer tokens are accepted only via Authorization headers, whether HTTPS is enforced, and whether token validation and rate limiting are consistently applied. Findings include insecure transport usage, missing input validation, and authorization bypass risks, each mapped to relevant frameworks such as OWASP API Top 10 and providing prioritized remediation guidance.

Remediation focuses on enforcing HTTPS, using secure transmission formats, and validating Bearer tokens rigorously in Express. Always serve API traffic over TLS to protect tokens in transit. Require the Authorization header in the format Bearer , and reject tokens supplied via query parameters or cookies without additional safeguards.

The following example shows secure middleware setup for Bearer token validation in Express using express-jwt and jwks-rsa. This validates the token signature, issuer, audience, and expiration before allowing access to protected routes:

const express = require('express');
const jwt = require('express-jwt');
const jwks = require('jwks-rsa');

const app = express();

const jwtCheck = jwt({
  secret: jwks.expressJwtSecret({
    cache: true,
    rateLimit: true,
    jwksRequestsPerMinute: 5,
    jwksUri: 'https://YOUR_DOMAIN/.well-known/jwks.json',
  }),
  issuer: 'https://YOUR_DOMAIN/',
  audience: 'YOUR_API_AUDIENCE',
  algorithms: ['RS256'],
});

app.use('/api/protected', jwtCheck, (req, res) => {
  res.json({ message: 'Authorized access', user: req.auth });
});

app.use((err, req, res, next) => {
  if (err.name === 'UnauthorizedError') {
    res.status(401).json({ error: 'invalid_token', error_description: err.message });
  } else {
    res.status(500).json({ error: 'server_error' });
  }
});

app.listen(3000, () => console.log('Secure server running on port 3000'));

For token introspection or opaque tokens, use a verification step that calls your identity provider’s introspection endpoint and checks active status, scope, and claims before proceeding:

const axios = require('axios');

async function verifyToken(token) {
  const response = await axios.post('https://YOUR_DOMAIN/oauth/introspect', null, {
    params: { token },
    auth: { username: 'client_id', password: 'client_secret' },
    headers: { Accept: 'application/json' },
  });
  if (!response.data.active) {
    throw new Error('Token inactive');
  }
  if (response.data.scope && !response.data.scope.includes('api:read')) {
    throw new Error('Insufficient scope');
  }
  return response.data;
}

app.get('/api/resource', async (req, res, next) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'missing_token' });
  }
  const token = auth.slice(7);
  try {
    const claims = await verifyToken(token);
    req.auth = claims;
    next();
  } catch (err) {
    next(err);
  }
}, (req, res) => {
  res.json({ message: 'Valid token and sufficient scope' });
});

Complementary design practices include setting short token lifetimes, using refresh tokens with strict rotation, and enforcing scope-based access control on each endpoint. Apply consistent middleware across all protected routes and avoid conditional authorization checks that can lead to privilege escalation. Tools like middleBrick can verify that these patterns are consistently applied and flag routes where Bearer tokens are accepted insecurely, supporting compliance mappings to OWASP API Top 10 and other standards.