Request Smuggling in Flask with Bearer Tokens

Request smuggling occurs when an HTTP request is interpreted differently by separate layers such as a frontend web server and the Flask application. In Flask deployments behind proxies or load balancers, differences in how each layer parses headers and body boundaries can allow an attacker to smuggle a request across security boundaries. When Bearer Tokens are involved, this becomes particularly dangerous because the token is often stored in a header (commonly Authorization: Bearer <token>) and may be trusted by the backend without additional validation.

Consider a deployment where a proxy terminates TLS and forwards requests to Flask over HTTP. If the proxy normalizes or removes headers differently than Flask’s development server, an attacker can craft a request that is parsed differently by each layer. For example, an attacker might use a request with two Content-Length headers or an ambiguous Transfer-Encoding header to cause request splitting. A smuggled request can cause the second request to be interpreted by Flask as belonging to the same connection, potentially leading to authentication bypass or data leakage.

With Bearer Tokens, the risk is amplified when Flask routes rely solely on the presence of the Authorization header to grant access without verifying token integrity or scope. If a smuggled request reaches a route that trusts the header, it might execute with the permissions of the token owner. For instance, an attacker could smuggle a request to a sensitive endpoint like /admin/reset while the token in the header grants administrative privileges. This is a broken access control issue (related to BOLA/IDOR) where the identity derived from the token is not properly validated against the intended action.

Flask itself does not enforce strict header parsing rules, so the framework relies on the WSGI server and any intermediary proxies. A common misconfiguration is to trust the Authorization header without ensuring the request has not been split or duplicated. Attackers can exploit this by sending requests such as:

POST /transfer HTTP/1.1
Host: api.example.com
Content-Length: 13
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Content-Length: 0

GET /admin HTTP/1.1
Host: api.example.com

If the proxy uses one Content-Length and Flask uses another, the second request may be processed under the same authenticated context. This can lead to unauthorized actions being performed, data exposure, or inventory manipulation, depending on the endpoint logic.

Remediation focuses on ensuring that each request is parsed consistently and that Bearer Tokens are validated with strict checks. Do not rely on header presence alone; validate token format, signature, issuer, and scope before authorizing any action. Below are concrete code examples for Flask that demonstrate secure handling of Bearer Tokens and defenses against request smuggling.

1. Enforce strict header parsing and reject ambiguous requests

Configure your production WSGI server (e.g., Gunicorn with an appropriate worker type) to reject requests with conflicting Transfer-Encoding and Content-Length headers. In Flask, you can add a request preprocessor to drop suspicious requests early:

from flask import request, abort

@app.before_request
def reject_ambiguous_smuggling_attempts():
    # Reject requests that present both Transfer-Encoding and Content-Length
    if request.headers.get('Transfer-Encoding') and request.headers.get('Content-Length'):
        abort(400, 'Ambiguous message encoding')
    # Optionally reject chunked requests if not expected
    if request.headers.get('Transfer-Encoding') == 'chunked' and not app.config.get('ALLOW_CHUNKED', False):
        abort(400, 'Chunked encoding not allowed')

2. Validate Bearer Tokens with a robust verification routine

Use a library such as PyJWT to decode and verify the token. Never treat the raw token string as trustworthy. Enforce algorithm restrictions and validate claims:

import jwt
from flask import request, abort, g
from functools import wraps

def token_required(f):
    @wraps(f)
    def decorated(*args, **kwargs):
        auth = request.headers.get('Authorization')
        if not auth or not auth.startswith('Bearer '):
            abort(401, 'Missing or invalid authorization header')
        token = auth.split(' ')[1]
        try:
            # Always specify algorithms and validate issuer/audience
            payload = jwt.decode(
                token,
                key='your-public-key-or-secret',
                algorithms=['RS256'],
                options={'require': ['exp', 'iss', 'aud']},
                issuer='https://auth.example.com',
                audience='api.example.com'
            )
            g.user = payload
        except jwt.ExpiredSignatureError:
            abort(401, 'Token expired')
        except jwt.InvalidTokenError:
            abort(401, 'Invalid token')
        return f(*args, **kwargs)
    return decorated

@app.route('/admin/reset', methods=['POST'])
@token_required
def admin_reset():
    # g.user is verified and contains claims
    if not g.user.get('admin'):
        abort(403, 'Insufficient scope')
    # Proceed with admin logic
    return {'status': 'ok'}

3. Scope and ownership checks at the route level

Even with a valid Bearer Token, ensure that the subject of the token matches the resource being accessed. Avoid trusting implicit ownership inferred from the token alone:

@app.route('/users/<user_id>', methods=['GET'])
@token_required
def get_user(user_id):
    if str(g.user.get('sub')) != str(user_id) and not g.user.get('admin'):
        abort(403, 'Cannot access other users data')
    return fetch_user_data(user_id)

4. Use middleware or proxy-aware configurations

If behind a trusted proxy, set app.config['TRUSTED_PROXIES'] appropriately and use Request.remote_addr carefully. Avoid forwarding raw headers from the proxy without validation:

app.config['TRUSTED_PROXIES'] = {'10.0.0.1', '192.168.1.0/24'}
# Ensure your proxy sets X-Forwarded-For and X-Forwarded-Proto safely
# and do not rely on them for security decisions without validation

5. Continuous monitoring via automated scanning

Integrate scans into your pipeline to detect misconfigurations early. The middleBrick CLI can be used locally or in CI to validate that your endpoints are not vulnerable to smuggling and that Bearer Token handling conforms to best practices:

# Scan an API endpoint from the terminal
middlebrick scan https://api.example.com/openapi.json

For teams managing many services, the middleBrick GitHub Action can fail builds if a scan returns a high-risk score, and the Pro plan enables continuous monitoring with alerts when new findings appear.