Arp Spoofing in Express with Bearer Tokens

Arp spoofing is a Layer 2 network attack where an attacker sends falsified Address Resolution Protocol messages to associate their MAC address with the IP address of a legitimate host, typically the default gateway. In an Express application that relies on Bearer Tokens transmitted over HTTP (non-TLS) or even HTTPS without additional network-level protections, arp spoofing can expose sensitive token exchanges to an attacker on the same local network segment.

Consider an Express API that uses Bearer Tokens in the Authorization header for authentication. If an attacker successfully performs arp spoofing between the client and the server, they can intercept, view, and potentially modify unencrypted HTTP traffic. Even when HTTPS is used, a client that does not properly validate certificates might be tricked into accepting a malicious certificate presented during a man-in-the-middle proxy setup facilitated by arp spoofing, allowing the attacker to see or alter the Bearer Token.

The combination is particularly risky because Bearer Tokens are often long-lived for convenience and are sent with every request. An intercepted token enables session hijacking: the attacker can replay the token to access protected endpoints, escalate privileges, or perform actions on behalf of the legitimate user. This risk is compounded in local or shared networks (e.g., office Wi-Fi, co-located servers) where arp spoofing is easier to execute. While arp spoofing does not directly break HTTPS encryption, it can undermine trust in the endpoint identity if clients are misconfigured or if the attack is paired with SSL stripping techniques that force the client to fall back to HTTP.

Express itself does not prevent arp spoofing; this is a network-layer issue. However, the framework’s common usage patterns—such as failing to enforce HTTPS, not setting the Strict-Transport-Security header, or accepting any certificate in HTTP clients—can inadvertently make Bearer Token–based authentication vulnerable to interception when arp spoofing is present. For example, an Express route that reads req.headers.authorization without verifying the token’s integrity or the transport’s confidentiality assumes a trusted network, which arp spoofing invalidates.

To contextualize the threat, consider this minimal Express snippet that naively extracts a Bearer Token:

const express = require('express');
const app = express();

app.get('/profile', (req, res) => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = authHeader.split(' ')[1];
  // Vulnerable: token used without validating token binding or transport integrity
  res.json({ message: 'Welcome', token: token });
});

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

In a scenario where arp spoofing is active, an attacker on the same network can observe the token if the request is sent over HTTP. Even over HTTPS, if the client does not enforce strict certificate validation, the attacker positioned via arp spoofing may be able to perform a downgrade or inject malicious proxies that capture the token. The key takeaway is that arp spoofing highlights the need to protect Bearer Tokens at the network and application layers, not rely on the assumed safety of the local network.

Mitigating the risk of Bearer Token exposure to arp spoofing requires enforcing transport security, binding tokens to the session, and validating tokens rigorously. Below are concrete Express-focused remediation steps with code examples.

1. Enforce HTTPS and HSTS

Always terminate TLS at the edge and ensure your Express app only serves HTTPS. Use HTTP Strict Transport Security (HSTS) to prevent protocol downgrade attacks.

const express = require('express');
const https = require('https');
const fs = require('fs');
const app = express();

const options = {
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.cert')
};

app.use((req, res, next) => {
  if (req.headers['x-forwarded-proto'] !== 'https') {
    res.redirect('https://' + req.headers.host + req.url);
  } else {
    next();
  }
});

app.use((req, res, next) => {
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
  next();
});

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

2. Validate and Bind Bearer Tokens

Do not trust the token alone. Verify its signature, scope, and, if possible, bind it to the client’s TLS channel (e.g., via token binding or DPoP). For JWTs, use a library to verify the issuer and audience.

const jwt = require('jsonwebtoken');

app.get('/profile', (req, res) => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = authHeader.split(' ')[1];
  try {
    const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
      algorithms: ['RS256'],
      audience: 'my-api',
      issuer: 'https://auth.example.com'
    });
    // Token is valid and bound to expected context
    res.json({ message: 'Welcome', user: decoded.sub });
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
});

3. Use Short-Lived Tokens and Refresh Tokens

Reduce the window of exposure by issuing short-lived access tokens and using secure refresh tokens stored in HttpOnly cookies. This limits the usefulness of any token intercepted via arp spoofing.

app.post('/token/refresh', express.json(), (req, res) => {
  const { refreshToken } = req.body;
  // Validate refresh token against a secure store and issue a new access token
  if (!isValidRefreshToken(refreshToken)) {
    return res.status(401).json({ error: 'Invalid refresh token' });
  }
  const accessToken = signAccessToken({ sub: refreshToken.sub });
  res.json({ accessToken });
});

function signAccessToken(payload) {
  return jwt.sign(payload, process.env.JWT_PRIVATE_KEY, {
    algorithm: 'RS256',
    expiresIn: '15m'
  });
}

4. Network Hardening and Monitoring

While not Express code, complement application measures with network-level practices: use ARP spoofing detection tools, isolate sensitive services, and monitor for unusual token usage patterns that may indicate token replay after interception.

By combining HTTPS enforcement, strict token validation, and short token lifetimes, you reduce the risk that intercepted Bearer Tokens—obtained via arp spoofing—can be used to compromise your Express API.