Bearer Tokens API Security

Bearer tokens are the most common authentication mechanism for APIs. The term "bearer" means exactly what it sounds like: whoever presents the token is granted access. Unlike proof-of-possession mechanisms that require a private key, bearer tokens rely solely on the secrecy of the token string itself.

The typical flow works like this: a client authenticates (often with username/password or another credential) to get a token from an authorization server. This token is then included in the Authorization header of subsequent API requests using the Bearer scheme:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Under the hood, most bearer tokens are JWTs (JSON Web Tokens) that contain claims about the user, permissions, and expiration. The server validates the token's signature and claims before processing the request. This stateless approach scales well but creates critical security considerations.

The fundamental security property of bearer tokens is that possession equals access. If someone obtains your token, they can impersonate you until the token expires or is revoked. This makes token protection paramount - they should be treated like passwords, never logged, never transmitted in URLs, and always sent over HTTPS.

Developers often make critical mistakes with bearer tokens that completely undermine their security. One of the most dangerous is insufficient token expiration. Long-lived tokens (valid for weeks or months) give attackers extended access windows if compromised. Many APIs still use 30+ day expiration times, which is far too permissive for modern security standards.

Another major pitfall is missing or weak revocation mechanisms. Once issued, can a token be invalidated before expiration? Without proper revocation, stolen tokens remain valid until they naturally expire. This is especially problematic for high-privilege tokens used in administrative operations.

Token leakage through logging is surprisingly common. Developers sometimes log entire HTTP requests or responses for debugging, inadvertently capturing Authorization headers. These logs often persist in monitoring systems, error tracking tools, or even client-side browser consoles. A single debug log entry can expose hundreds of active tokens.

Cross-origin resource sharing (CORS) misconfigurations can also expose tokens. If your API allows credentialed requests from any origin, malicious websites can trick users' browsers into sending their tokens to the API. The same-origin policy protects tokens in cookies, but bearer tokens in headers have no such protection.

Perhaps most critically, many APIs fail to implement proper scope and audience validation. A token intended for one service might be accepted by another if the validation logic is incomplete. This allows token replay across different API endpoints or even different services entirely.

middleBrick's Bearer Token security check specifically tests for these misconfigurations, including token exposure in responses, weak expiration policies, and improper CORS settings that could allow token theft.

Securing bearer tokens requires defense in depth. Start with short expiration times - 15 minutes to 1 hour for access tokens is reasonable for many applications. Pair this with refresh tokens that have longer lifetimes but are stored securely (HTTP-only cookies or secure storage) and can be individually revoked.

Implement robust token revocation through a token blacklist or by maintaining server-side session state. When a user logs out or their permissions change, immediately invalidate their active tokens. For JWTs, include a token identifier (jti claim) that can be checked against a revocation list.

Always use HTTPS with proper certificate validation. Never allow bearer tokens over HTTP, and consider HSTS headers to prevent protocol downgrade attacks. For added security, implement token binding - cryptographically tie the token to specific client characteristics like IP address or user agent, though this adds complexity.

Log sanitization is critical. Configure your logging infrastructure to redact or completely exclude Authorization headers. Many frameworks offer built-in mechanisms for this - use them consistently across all services. Also audit your dependencies for logging middleware that might capture headers.

Implement proper CORS policies. Only allow credentialed requests from your known, trusted origins. Use the Access-Control-Allow-Origin header carefully, never use wildcards (*) when credentials are involved. Consider implementing CSRF protection even for token-based APIs, as some attacks can trick browsers into sending tokens.

Scope tokens appropriately. Include only the permissions necessary for the intended use case. A token for reading public data shouldn't have write permissions. Validate the token's intended audience (aud claim) on every request to prevent cross-service token replay.

For high-security applications, consider adding additional layers like mutual TLS (mTLS) where the client presents a client certificate alongside the bearer token, or implement proof-of-possession mechanisms that require a private key.

middleBrick can help identify these vulnerabilities in your API. The CLI tool makes it easy to scan your endpoints: middlebrick scan https://api.example.com. For teams wanting continuous security, the GitHub Action can fail builds if bearer token security issues are detected, preventing vulnerable code from reaching production.