Ssrf Server Side in Flask with Bearer Tokens

Server Side Request Forgery (SSRF) in a Flask application that uses Bearer Tokens for authorization can amplify the impact of an SSRF flaw. In this setup, the server-side code typically receives an incoming request that includes a Bearer Token, validates or forwards it, and then makes an outbound HTTP request on behalf of the client. If the outbound request uses a value derived from user input—such as a URL or host header—without strict validation, an attacker can force the server to make arbitrary internal or external requests. Because the server includes the Bearer Token in those outbound calls, the SSRF can lead to unintended access to protected resources that the token is authorized to reach.

For example, consider a Flask route that proxies requests to a protected upstream service and forwards the incoming Authorization header directly. An SSRF payload pointing to internal metadata services (e168.imdsv2.s3.amazonaws.com, 169.254.169.254, or internal Kubernetes endpoints) can cause the server to use the same Bearer Token to access sensitive internal APIs. This is especially dangerous if the token has broader privileges than intended for the public endpoint. In an OpenAPI spec analyzed by middleBrick, definitions and runtime calls can be cross-referenced; if an endpoint accepts a user-supplied URL and later uses it in an HTTP client call while propagating headers, the scan can flag this as an SSRF with authorization context.

middleBrick’s scans include checks for SSRF and for unsafe consumption patterns, highlighting cases where authorization headers are propagated without validation. The tool also inspects OpenAPI 2.0, 3.0, and 3.1 specs with full $ref resolution to identify operations where user-controlled data might reach network calls. This helps developers see how an endpoint that appears to require a Bearer Token might, under SSRF conditions, expose internal services that also require that same token.

To mitigate SSRF in Flask when using Bearer Tokens, ensure that user input never reaches the URL or headers used in outbound requests, and avoid propagating incoming Authorization headers to arbitrary destinations. Validate and allowlist destinations, and construct outbound requests with a fixed, service-specific credential or token that is not derived from the client-supplied token.

Example: Unsafe proxy with Bearer Token propagation

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

@app.route('/proxy')
def unsafe_proxy():
    token = request.headers.get('Authorization', '').replace('Bearer ', '')
    target = request.args.get('url')  # user-controlled
    if not target:
        return jsonify({'error': 'missing url'}), 400
    headers = {'Authorization': f'Bearer {token}'}
    resp = requests.get(target, headers=headers, timeout=5)
    return (resp.content, resp.status_code, resp.headers.items())

This pattern is risky because target is user-controlled and the server forwards its Bearer Token. An SSRF can occur, and the token may access internal services.

Example: Safe proxy with destination allowlist and fixed credentials

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

ALLOWED_HOSTS = {'api.example.com', 'internal.example.com'}
FIXED_TOKEN = 'service_specific_token_here'

def is_allowed_host(url):
    from urllib.parse import urlparse
    try:
        parsed = urlparse(url)
        return parsed.hostname in ALLOWED_HOSTS
    except Exception:
        return False

@app.route('/proxy')
def safe_proxy():
    target = request.args.get('url')  # still user-controlled but validated
    if not target or not is_allowed_host(target):
        return jsonify({'error': 'invalid target'}), 400
    headers = {'Authorization': f'Bearer {FIXED_TOKEN}'}
    resp = requests.get(target, headers=headers, timeout=5)
    return (resp.content, resp.status_code, dict(resp.headers))

In the safe version, the destination is checked against an allowlist, and the outgoing request uses a fixed service token instead of the client’s Bearer Token. This prevents SSRF from being leveraged to reach unintended internal endpoints with the client’s authorization context.

When integrating with identity providers or APIs that require Bearer Tokens, prefer configuring the token as an environment variable and never echoing or forwarding the client’s original Authorization header to arbitrary URLs. middleBrick’s scans can highlight endpoints where incoming headers are propagated to outbound calls, supporting remediation by showing the precise locations where authorization context may be exposed.