Request Smuggling with Bearer Tokens

Request smuggling in Bearer token contexts occurs when an attacker manipulates HTTP request parsing to inject malicious payloads that compromise token handling. Unlike traditional request smuggling targeting HTTP/1.1 or HTTP/2 framing, Bearer token smuggling exploits how authentication middleware processes token boundaries and request body parsing.

The most common manifestation involves token boundary confusion. Consider a microservice architecture where an API gateway forwards requests to backend services. If the gateway and backend use different Content-Length header interpretations, an attacker can craft requests where the gateway sees one token but the backend processes another:

POST /api/resource HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Content-Length: 45

{
  "id": 1,
  "data": "test"
}
Content-Length: 25
GET /api/admin HTTP/1.1
Authorization: Bearer evil-token
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

id=2&action=delete

In this scenario, the gateway processes the first Content-Length (45) and forwards the JSON payload, but the backend might process the second Content-Length (25) and interpret the remaining bytes as a new request. The evil-token bypasses authentication because the backend sees it as the Authorization header for a separate request.

Another Bearer-specific variant targets token parsing logic. When tokens contain URL-encoded characters or special formatting, parsers might mis-handle boundary conditions:

POST /api/upload HTTP/1.1
Host: api.example.com
Authorization: Bearer abc%0d%0aContent-Type:%20application/json%0d%0aContent-Length:%2025%0d%0a%0d%0a{"admin":true}%0d%0a
Content-Type: application/json
Content-Length: 18

{ "data": "safe" }

Here, URL-encoded CRLF sequences (%0d%0a) in the token itself create new header lines when decoded by the backend, injecting arbitrary headers that grant admin privileges.

Detecting request smuggling in Bearer token contexts requires examining both HTTP layer parsing and token processing logic. Start with HTTP-level detection using tools like curl to test Content-Length variations:

# Test single Content-Length (should work)
curl -X POST https://api.example.com/endpoint \
  -H "Authorization: Bearer valid-token" \
  -H "Content-Type: application/json" \
  -d '{"test": "data"}' \
  -H "Content-Length: 25"

# Test multiple Content-Length headers (should reject)
curl -X POST https://api.example.com/endpoint \
  -H "Authorization: Bearer valid-token" \
  -H "Content-Type: application/json" \
  -H "Content-Length: 25" \
  -H "Content-Length: 30" \
  -d '{"test": "data"}'

Watch for inconsistent responses between these requests. If the second request succeeds or returns different data, your server may be vulnerable to Content-Length smuggling.

For token-specific smuggling, use middleBrick's black-box scanning to detect boundary confusion issues. middleBrick tests how your API handles malformed Authorization headers with embedded control characters:

middlebrick scan https://api.example.com \
  --test-auth-boundary \
  --test-content-length-confusion \
  --test-url-encoded-injection

The scanner attempts to inject CRLF sequences, multiple Content-Length headers, and URL-encoded control characters into Authorization headers, then analyzes whether the backend processes these as separate requests or modified headers.

Manual testing should include fuzzing token boundaries with various encodings:

# Test with embedded newlines
curl -X POST https://api.example.com/secure-endpoint \
  -H "Authorization: Bearer valid-token%0d%0aContent-Type:%20application/json%0d%0aContent-Length:%2020%0d%0a%0d%0a{"test":true}" \
  -H "Content-Type: application/json" \
  -d '{"normal": "data"}'

Monitor whether the backend interprets this as one request with a modified token or multiple requests. Look for inconsistent authentication states, unexpected data exposure, or privilege escalation across similar test cases.

Remediation for Bearer token request smuggling requires hardening both HTTP parsing and token validation logic. Start with strict HTTP header parsing at the application layer:

// Node.js/Express - Strict Content-Length validation
app.use((req, res, next) => {
  const contentLength = req.headers['content-length'];
  const transferEncoding = req.headers['transfer-encoding'];
  
  if (contentLength && transferEncoding) {
      error: 'Cannot use both Content-Length and Transfer-Encoding'
    });
  }
  
  if (contentLength) {
    const length = parseInt(contentLength, 10);
    if (isNaN(length) || length < 0) {
        error: 'Invalid Content-Length header'
      });
    }
  }
  
  next();
});

This middleware prevents the ambiguous state where both Content-Length and Transfer-Encoding headers exist, a common smuggling vector.

For token-specific hardening, implement strict Authorization header parsing that rejects malformed tokens:

// Python/Flask - Secure Bearer token validation
from flask import request
import re

def validate_bearer_token() {
  auth_header = request.headers.get('Authorization', '')
  if not auth_header:
    return None, 'Missing Authorization header'
  
  # Strict Bearer token pattern matching
  if not re.match(r'^Bearer [A-Za-z0-9-_.]+$', auth_header):
    return None, 'Invalid token format'
  
  # Reject tokens containing URL-encoded control characters
  if '%0d' in auth_header.lower() or '%0a' in auth_header.lower():
    return None, 'Potential header injection detected'
  
  token = auth_header.split()[1]
  return token, None
}

This validation ensures tokens contain only expected characters and rejects those with URL-encoded CRLF sequences that could create header injection.

At the infrastructure level, configure reverse proxies to normalize request parsing before reaching application code:

# nginx configuration - Prevent request smuggling
server {
  listen 443 ssl http2;
  
  # Reject requests with multiple Content-Length headers
  if ($http_content_length_count > 1) {
    return 400;
  }
  
  # Reject requests with both Content-Length and Transfer-Encoding
  if ($http_content_length != "" && $http_transfer_encoding != "") {
    return 400;
  }
  
  location /api/ {
    # Additional security headers
    add_header X-Content-Type-Options "nosniff";
    add_header X-Frame-Options "DENY";
    
    proxy_pass http://backend:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

This configuration catches smuggling attempts at the proxy level before they reach your application, providing defense in depth against both HTTP and token-specific smuggling attacks.