Hallucination Attacks in Flask with Bearer Tokens

A hallucination attack in the context of an API security scan refers to the generation of plausible but false information by an LLM or AI component integrated into or behind an API. When a Flask API uses bearer tokens for authorization and also exposes endpoints that interact with LLMs, the combination can amplify risks if the API does not properly validate, scope, or audit token usage alongside LLM outputs.

Flask APIs commonly use bearer tokens passed via the Authorization header to authenticate requests. If these endpoints also perform actions based on LLM-generated content—such as summarizing data, transforming inputs, or making contextual decisions—there is a risk that the LLM may produce content that appears authoritative but is incorrect or misleading. This is particularly dangerous when the API trusts LLM output without additional verification or when the bearer token scopes are overly broad.

Consider a Flask endpoint that accepts a user-supplied prompt, forwards it to an LLM, and then uses the LLM’s response to construct a downstream request with the caller’s bearer token. If the LLM hallucinates a function name, URL, or parameter, the API may execute unintended actions under the user’s identity. For example, an LLM might invent a non-existent user ID or resource path, and the Flask code might proceed using the caller’s token, leading to unauthorized data access or operations that appear legitimate in audit logs.

Another scenario involves token leakage through LLM outputs. If a Flask route returns LLM-generated content that inadvertently echoes or paraphrases sensitive authorization metadata (such as token scopes or roles), attackers may infer valid token attributes or craft more precise attacks. Hallucination attacks exploit the trust placed in AI outputs and the implicit trust placed in bearer tokens, especially when Flask applications do not independently verify that each token-scoped operation aligns with the original intent and validated input.

MiddlewareBrick’s LLM/AI Security checks specifically target these risks by detecting system prompt leakage, performing active prompt injection tests (system prompt extraction, instruction override, DAN jailbreak, data exfiltration, cost exploitation), scanning outputs for PII or API keys, detecting excessive agency patterns, and identifying unauthenticated LLM endpoints. These checks help surface misconfigurations where bearer token handling intersects with unreliable LLM behavior, enabling developers to tighten validation and scoping before deployment.

To mitigate hallucination and authorization risks in Flask APIs that use bearer tokens, apply strict input validation, enforce least-privilege token scopes, and avoid directly chaining LLM outputs to privileged actions. Below are concrete remediation steps and code examples.

Validate and scope bearer tokens explicitly

Do not rely on the presence of a bearer token alone. Decode and validate the token (e.g., via introspection or a trusted JWT library) and enforce scopes or roles before allowing sensitive operations.

from flask import Flask, request, jsonify
import jwt
from functools import wraps

app = Flask(__name__)
SECRET_KEY = 'your_jwks_or_secret'

def token_required(f):
    @wraps(f)
    def decorated(*args, **kwargs):
        auth = request.headers.get('Authorization')
        if not auth or not auth.startswith('Bearer '):
            return jsonify({'error': 'missing_token'}), 401
        token = auth.split(' ')[1]
        try:
            payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
            # enforce scope or role checks here
            if not payload.get('scope', '').split(',').__contains__('api:read'):
                return jsonify({'error': 'insufficient_scope'}), 403
            request.user = payload
        except jwt.ExpiredSignatureError:
            return jsonify({'error': 'token_expired'}), 401
        except jwt.InvalidTokenError:
            return jsonify({'error': 'invalid_token'}), 401
        return f(*args, **kwargs)
    return decorated

@app.route('/data')
@token_required
def get_data():
    # token validated and scoped; safe to proceed
    return jsonify({'data': 'protected resource'})

Sanitize LLM outputs before using them in authorization logic

Treat LLM output as untrusted. Do not allow LLM responses to directly dictate resource identifiers or authorization decisions. Normalize and validate any values derived from LLM output against an allowlist or via strict schema checks.

import re
from flask import Flask, request, jsonify

app = Flask(__name__)

# Example: allow only known resource patterns derived from user request, never from LLM
RESOURCE_PATTERN = re.compile(r'^[a-z0-9_-]{1,64}$')

def safe_resource_id(user_supplied):
    if RESOURCE_PATTERN.match(user_supplied):
        return user_supplied
    raise ValueError('invalid_resource')

@app.route('/action', methods=['POST'])
def perform_action():
    data = request.get_json()
    user_token_scope = request.headers.get('X-Scope')  # validated earlier
    # Never use llm_output directly as resource_id
    raw = data.get('resource_hint')
    resource_id = safe_resource_id(raw)  # validate against strict pattern
    # proceed only if token scope allows this resource
    if user_token_scope and resource_id in permitted_set_for_scope(user_token_scope):
        return jsonify({'status': 'ok'})
    return jsonify({'error': 'forbidden'}), 403

Apply principle of least privilege and audit trails

Ensure bearer tokens request minimal scopes for the task. Log actions with user context and resource identifiers in a normalized form to help detect anomalies introduced by hallucinated outputs.

import logging
from flask import g

logger = logging.getLogger('api')

@app.after_request
def audit_log(response):
    if hasattr(g, 'user') and hasattr(g, 'resource'):
        logger.info(
            'action',
            extra={
                'user_id': g.user.get('sub'),
                'resource': g.resource,
                'scope': g.user.get('scope'),
                'method': request.method,
                'path': request.path,
                'status': response.status_code
            }
        )
    return response

Use MiddleBrick to detect risky configurations

Run MiddleBrick scans against your Flask API to identify missing validation, overly permissive token handling, and potential hallucination exposure points. The CLI and Web Dashboard provide per-category breakdowns and prioritized findings with remediation guidance, helping you iteratively reduce risk without speculative assumptions.