Token Leakage in Flask

Token leakage in Flask applications occurs when authentication tokens—whether JWTs, session cookies, or API keys—are inadvertently exposed through various code paths. Flask's flexibility and Python's dynamic nature create several unique vulnerability patterns that don't appear in other frameworks.

The most common Flask-specific token leakage happens through improper error handling. Flask's default error handlers often include exception details in responses, which can contain token values from request headers or form data. Consider this vulnerable pattern:

@app.route('/api/data')
def get_data():
    try:
        token = request.headers['Authorization']
        # process request
    except KeyError:
        return jsonify({'error': 'Missing token: ' + str(e)}), 400

When a client omits the Authorization header, Flask returns the exception message including the token name, potentially confirming valid token endpoints to attackers.

Flask's debug mode creates another significant leakage vector. When debug=True, Flask's interactive debugger displays full request contexts, including headers with tokens, when exceptions occur. This becomes catastrophic if debug mode is accidentally left enabled in production:

app.run(debug=True, host='0.0.0.0')

An attacker triggering any exception could see complete request headers with JWTs or API keys in the debugger interface.

Flask's logging system presents another subtle leakage risk. By default, Flask logs requests at the INFO level, including headers. If logging configuration isn't properly secured, tokens in Authorization headers get written to log files:

# Vulnerable logging
app.logger.info(f'Processing request from {request.remote_addr}')
# Request headers with tokens get logged automatically

Flask's session management also introduces token leakage patterns. The default signed cookie sessions store session data client-side, but developers sometimes store sensitive tokens in session variables, which then get transmitted with every request:

# Vulnerable session usage
@app.route('/login')
def login():
    session['jwt_token'] = get_jwt_from_database()
    return redirect('/dashboard')

Here, the JWT gets included in every subsequent cookie, increasing the attack surface if the session mechanism is compromised.

Flask's blueprint system can cause token leakage when blueprints aren't properly isolated. A blueprint handling authentication might inadvertently expose token validation logic through error messages that bubble up to parent applications:

# auth_blueprint.py
@auth_blueprint.route('/validate')
def validate_token():
    try:
        token = request.headers['Authorization'].split()[1]
        decoded = jwt.decode(token, SECRET_KEY)
        return jsonify({'valid': True})
    except jwt.DecodeError as e:
        return jsonify({'error': 'Invalid token: ' + str(e)}), 401

The specific error message reveals whether the token format was invalid versus expired, helping attackers craft valid tokens.

Detecting token leakage in Flask requires examining both code patterns and runtime behavior. Static analysis can identify vulnerable code structures, while dynamic scanning reveals actual token exposure.

Code-level detection focuses on Flask-specific patterns. Look for these red flags in your Flask applications:

# Patterns to search for
# 1. Debug mode enabled
app.run(debug=True)

Static analysis tools should flag any debug mode usage, especially in production configurations. The presence of debug=True in app.run() or configuration files is an immediate high-risk finding.

2. Exception handling that exposes token information:

# Search for these patterns
except KeyError as e:
    return jsonify({'error': str(e)})
except Exception as e:
    app.logger.error(f'Error processing token: {e}')

Dynamic detection requires testing your Flask endpoints with various authentication scenarios. middleBrick's black-box scanning approach is particularly effective here because it tests unauthenticated attack surfaces without requiring credentials:

$ middlebrick scan https://yourapp.com/api/protected

middleBrick tests for token leakage by examining error responses, logging configurations, and debug endpoint accessibility. It specifically looks for Flask's debug interface being accessible, which would expose request contexts including tokens.

For Flask applications, middleBrick's scanning includes checking for:

• Debug mode exposure through 500 errors that reveal request contexts
• Token information in error response bodies
• Log file accessibility if Flask's logging endpoints are exposed
• Session cookie patterns that might contain sensitive data
• Blueprint isolation failures where auth logic leaks

middleBrick's LLM security scanning also detects if your Flask app serves AI endpoints that might leak system prompts or training data through error responses—a growing concern with Flask-based LLM applications.

Runtime detection involves testing your Flask app with malformed requests to trigger error conditions:

# Test script for token leakage
import requests
import re

def test_token_leakage(base_url):
    # Test missing token
    response = requests.get(f'{base_url}/api/data')
    if 'token' in response.text.lower():
        print('Potential token leakage in error response')
    
    # Test debug mode exposure
    response = requests.get(f'{base_url}/debug')
    if response.status_code == 200:
        print('Debug interface exposed')

This testing approach reveals whether your Flask app inadvertently confirms token requirements or exposes validation logic through error messages.

Remediating token leakage in Flask requires both code changes and configuration hardening. The most critical fix is ensuring debug mode never runs in production:

# production.py
from flask import Flask
app = Flask(__name__)

# NEVER use debug=True in production
app.run(host='0.0.0.0', port=5000, debug=False)

# Better: use environment-based configuration
import os
app.config['DEBUG'] = os.getenv('FLASK_DEBUG', 'false').lower() == 'true'
app.config['TESTING'] = os.getenv('FLASK_TESTING', 'false').lower() == 'true'

Implement proper error handling that never exposes token information:

from flask import jsonify
from werkzeug.exceptions import HTTPException

@app.errorhandler(HTTPException)
def handle_http_exception(e):
    # Generic error response without token details
    return jsonify({
        'error': 'An error occurred processing your request',
        'code': e.code
    }), e.code

# Custom error handler for authentication
@app.errorhandler(401)
def unauthorized(e):
    return jsonify({
        'error': 'Authentication required',
        'code': 401
    }), 401

Secure your logging configuration to prevent token exposure:

import logging
from flask import request

# Configure logging to exclude sensitive headers
class RequestFilter(logging.Filter):
    def filter(self, record):
        if hasattr(record, 'request_headers'):
            headers = dict(record.request_headers)
            for key in ['Authorization', 'Cookie']:
                headers.pop(key, None)
            record.request_headers = headers
        return True

# Apply filter to Flask's logger
app.logger.addFilter(RequestFilter())

# Custom request formatter
@app.before_request
def log_request_info():
    if app.debug:
        app.logger.debug('Headers: %s', dict(request.headers))  # Only in debug mode

Implement secure session management that doesn't store tokens client-side:

from flask import session
from flask_session import Session
import redis

# Use server-side sessions instead of signed cookies
app.config['SESSION_TYPE'] = 'redis'
app.config['SESSION_PERMANENT'] = False
app.config['SESSION_USE_SIGNER'] = True
app.config['SESSION_KEY_PREFIX'] = 'session:'

# Initialize Redis session store
redis_store = redis.from_url(os.getenv('REDIS_URL', 'redis://localhost:6379'))
Session(app)

# Store tokens server-side, not in session
@app.route('/login')
def login():
    token = authenticate_user()
    # Store token in Redis with session ID as key
    redis_store.set(f'token:{session.sid}', token, ex=3600)
    return redirect('/dashboard')

@app.route('/api/protected')
def protected():
    stored_token = redis_store.get(f'token:{session.sid}')
    if not stored_token:
        return unauthorized(None)
    # Process request with stored token

For blueprint isolation, ensure authentication logic is properly encapsulated:

# auth_blueprint.py
from flask import Blueprint, request, jsonify, current_app
from functools import wraps

bp = Blueprint('auth', __name__)

# Decorator to protect blueprint routes

def token_required(f):
    @wraps(f)
    def decorated_function(*args, **kwargs):
        token = request.headers.get('Authorization')
        if not token:
            return jsonify({'error': 'Authentication required'}), 401
        
        try:
            # Validate token without exposing details
            validate_jwt_token(token)
        except InvalidTokenError:
            return jsonify({'error': 'Invalid authentication'}), 401
        
        return f(*args, **kwargs)
    return decorated_function

# Use decorator on protected routes
@bp.route('/protected')
@token_required
def protected_route():
    return jsonify({'message': 'Access granted'})

Finally, integrate middleBrick into your development workflow to catch token leakage early:

# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Run middleBrick Scan
      run: |
        npm install -g middlebrick
        middlebrick scan https://staging.yourapp.com/api
      continue-on-error: true
    - name: Fail on high-risk findings
      if: failure()
      run: |
        echo "Security scan found issues - please review middleBrick report"
        exit 1

This GitHub Action configuration ensures your Flask APIs are scanned for token leakage and other security issues before deployment, with the ability to fail builds based on security risk thresholds.