Insufficient Logging in Flask with Bearer Tokens

Insufficient logging in a Flask API that uses Bearer tokens creates a blind spot for security and incident response. When authentication is token-based, each request carries an authorization header such as Authorization: Bearer <token>. If requests are not logged with sufficient context, an attacker can probe the endpoint without leaving a traceable, actionable record.

Consider a Flask route that accepts a Bearer token but does not log key details:

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/api/data")
def get_data():
    auth = request.headers.get("Authorization")
    if auth and auth.startswith("Bearer "):
        token = auth.split(" ")[1]
        # business logic
        return jsonify({"data": "secret"}), 200
    return jsonify({"error": "unauthorized"}), 401

This implementation lacks structured logging of critical events. Without logs capturing the token identifier (e.g., token hash or ID), timestamp, source IP, endpoint, HTTP method, and response status, you cannot reliably detect:

• Token reuse across multiple users or sessions
• Suspicious geographic or temporal access patterns
• Brute-force or credential-stuffing attempts targeting token validation paths
• Token leakage in client-side code or referrer headers

Inadequate logging also hampers forensic analysis post-breach. For example, if a token is compromised and used to access sensitive endpoints, investigators need reliable request metadata to trace the scope of exposure. The absence of correlation between token usage and behavior makes it difficult to identify compromised tokens without disrupting service. Logging only failures (e.g., 401 responses) can miss successful unauthorized access when tokens are valid but improperly scoped.

Moreover, Bearer tokens often carry broader permissions than session cookies, so each logged event should include token scope claims (without logging the raw token). Without these details, monitoring tools cannot raise alerts for anomalous activity such as sudden spikes in requests, atypical resource access, or usage outside expected lifetimes. This gap is especially critical in distributed systems where multiple services consume the same token; insufficient logs prevent tracking propagation and misuse across boundaries.

To align with checks such as Authentication and Data Exposure in middleBrick scans, ensure logs capture non-sensitive representations of authentication artifacts. For instance, log a hashed version of the token or a unique token identifier, along with the request context. This supports detection of patterns like token sharing across users or repeated use from different origins, which are indicators of insufficient access control and exposure risks.

Remediation focuses on structured, secure logging that respects token confidentiality while providing auditability. Below is a Flask example that logs essential metadata without exposing raw tokens.

import hashlib
import logging
from flask import Flask, request, jsonify

app = Flask(__name__)

# Configure structured logging (e.g., JSON format in production)
logging.basicConfig(level=logging.INFO, format='%(message)s')
logger = logging.getLogger(__name__)

def hash_token(token: str) -> str:
    return hashlib.sha256(token.encode("utf-8")).hexdigest()

@app.route("/api/data")
def get_data():
    auth = request.headers.get("Authorization")
    src_ip = request.remote_addr
    method = request.method
    path = request.path

    if auth and auth.startswith("Bearer "):
        token = auth.split(" ")[1]
        token_hash = hash_token(token)
        # Include token metadata (e.g., from decoded claims) if available
        logger.info(
            "auth_event",
            extra={
                "event_type": "token_access",
                "token_hash": token_hash,
                "ip": src_ip,
                "method": method,
                "path": path,
                "status": 200,
            }
        )
        return jsonify({"data": "secret"}), 200

    logger.warning(
        "auth_event",
        extra={
            "event_type": "missing_token",
            "ip": src_ip,
            "method": method,
            "path": path,
            "status": 401,
        }
    )
    return jsonify({"error": "unauthorized"}), 401

Key improvements:

• Token hashing: Use SHA-256 to log a deterministic, non-reversible token identifier. This allows correlation of requests using the same token without storing or exposing the token itself.
• Structured metadata: Log source IP, HTTP method, path, status, and timestamps to enable detection of anomalies (e.g., many 401s from one IP, or token use from unusual locations).
• Consistent log format: Use structured logging (e.g., JSON) so logs can be ingested by SIEM or monitoring tools for alerting on patterns like repeated token reuse or privilege escalation attempts.

In addition to logging, apply defense-in-depth:

• Enforce short token lifetimes and scope-based access to reduce the impact of leaked tokens.
• Use HTTPS to protect tokens in transit, preventing interception that would otherwise bypass logging considerations.
• Rotate or revoke tokens suspiciously active across multiple sessions or regions, correlating logs with token metadata where available.

These changes help satisfy authentication and data exposure checks by ensuring that token usage is observable and investigable while preserving token confidentiality. They also complement continuous monitoring capabilities offered by plans such as the middleBrick Pro plan, which can integrate these logs into broader security analytics.