Vulnerable Components in Express with Bearer Tokens

Express applications that rely on Bearer tokens for authorization commonly couple token handling with route protection in ways that introduce measurable risk. When token validation is incomplete, inconsistent, or overly permissive, the framework’s routing and middleware model can unintentionally expose protected endpoints or amplify other issues such as Insecure Direct Object References (IDOR) and Broken Function Level Authorization (BFLA).

One typical pattern is using a middleware that checks for the presence of a bearer token but does not validate its scope, audience, or expiration. For example, a middleware like the following verifies existence but skips signature verification or scope checks:

app.use((req, res, next) => {
  const auth = req.headers.authorization;
  if (auth && auth.startsWith('Bearer ')) {
    req.user = { id: '123', scope: 'read' };
    return next();
  }
  res.status(401).send('Unauthorized');
});

This approach creates a vulnerability because any string starting with Bearer is accepted, making the endpoint rely on client-supplied claims without verification. Attackers can send arbitrary tokens, and the application may treat them as valid if the middleware does not validate the token format or origin. This is especially risky when combined with permissive route definitions, such as applying the middleware at a parent route and then relaxing constraints on sub-routes, which can lead to privilege escalation or unauthorized data access.

Another common issue arises when token validation is performed but authorization checks are missing or inconsistent across similar endpoints. Consider an endpoint that reads a resource identifier from the URL and returns data without confirming that the token’s subject or scope permits access to that specific resource:

app.get('/users/:id/profile', authenticateBearer, (req, res) => {
  const userId = req.params.id;
  const tokenUserId = req.user.id;
  // Missing check: ensure token user can access userId
  db.getProfile(userId).then(profile => res.json(profile));
});

Here, the token is validated, but there is no check that the authenticated user is allowed to view the requested profile. This is a classic BOLA/IDOR pattern, where a missing ownership or relationship check allows horizontal or vertical privilege escalation. Insecure Direct Object References occur when the object identifier (e.g., user ID) is directly exposed and not cross-referenced with the token’s permissions.

Property-level authorization gaps further compound the risk. If an endpoint accepts partial updates and does not validate which properties the token is allowed to modify, an attacker can change sensitive fields such as roles or admin flags:

app.patch('/users/:id', authenticateBearer, (req, res) => {
  const updates = req.body;
  // Missing property-level authorization: ensure token cannot modify 'role' or 'isAdmin'
  db.updateUser(req.params.id, updates).then(() => res.send('ok'));
});

In this scenario, the token may only have a read or limited-write scope, yet the endpoint applies updates without inspecting the token’s scope against the fields being modified. This can lead to privilege escalation through manipulated requests, even when the token itself is cryptographically valid.

Finally, failing to enforce rate limits on bearer-token-protected routes can enable token enumeration or brute-force attacks. Without per-token or per-client rate limiting, attackers can make numerous requests with guessed or stolen tokens to probe for valid resources or infer behavior patterns. Proper integration of rate limiting with token validation is essential to reduce the attack surface of bearer-token-based APIs in Express.

Securing bearer token usage in Express requires precise validation, strict scope checks, and consistent authorization at both route and property levels. The following patterns demonstrate concrete fixes aligned with secure-by-default practices.

First, implement robust token validation that verifies format, signature, audience, and expiration instead of relying on prefix checks alone. Use a library such as jsonwebtoken to decode and verify tokens:

const jwt = require('jsonwebtoken');

function verifyBearer(req, res, next) {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).send('Unauthorized');
  }
  const token = auth.slice(7);
  try {
    const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
      audience: 'api.example.com',
      issuer: 'https://auth.example.com',
    });
    req.user = decoded;
    return next();
  } catch (err) {
    return res.status(401).send('Invalid token');
  }
}

app.use(verifyBearer);

This approach ensures that only properly signed tokens issued by a trusted authority and intended for the expected audience are accepted, mitigating the risk of accepting arbitrary strings as valid credentials.

Second, enforce ownership and scope checks on a per-request basis to prevent BOLA/IDOR. Always cross-reference the token’s subject with the resource identifier, and validate scope before proceeding:

app.get('/users/:id/profile', verifyBearer, (req, res) => {
  const tokenUserId = req.user.sub;
  const requestedUserId = req.params.id;
  if (tokenUserId !== requestedUserId) {
    return res.status(403).send('Forbidden');
  }
  if (!req.user.scope.split(' ').includes('profile:read')) {
    return res.status(403).send('Insufficient scope');
  }
  db.getProfile(requestedUserId).then(profile => res.json(profile));
});

By comparing the token’s subject with the route parameter and checking the scope claim, you ensure that users can only access their own data and only within permitted operations.

Third, apply property-level authorization on write operations to prevent privilege escalation through partial updates. Inspect the token’s scope against each field being modified:

const allowedFields = {
  'profile:write': ['name', 'email'],
  'admin:write': [], // token without admin scope cannot modify these
};

app.patch('/users/:id', verifyBearer, (req, res) => {
  const updates = req.body;
  const userScopes = req.user.scope.split(' ');
  const forbidden = Object.entries(updates).some(([key]) =>
    !userScopes.some(scope => {
      const fields = allowedFields[scope];
      return fields && fields.includes(key);
    })
  );
  if (forbidden) {
    return res.status(403).send('Forbidden fields');
  }
  db.updateUser(req.params.id, updates).then(() => res.send('ok'));
});

This ensures that tokens with limited scopes cannot modify sensitive fields such as roles or administrative flags, enforcing least-privilege updates.

Finally, integrate rate limiting at the token level to reduce probing risks. Use a middleware that considers the token subject or client IP to prevent excessive requests per token:

const rateLimit = require('express-rate-limit');

const tokenLimiter = rateLimit({
  keyGenerator: (req) => {
    const auth = req.headers.authorization || '';
    return auth.startsWith('Bearer ') ? auth.slice(7) : req.ip;
  },
  windowMs: 60_000,
  max: 100,
  standardHeaders: true,
  legacyHeaders: false,
});

app.use('/users', tokenLimiter);

With these measures in place, bearer token usage in Express becomes more predictable and aligned with security best practices, reducing the likelihood of unauthorized access or privilege escalation.