Api Key Exposure in Flask (Python)

Flask is a common choice for Python web services, and mishandling API keys in Flask apps can expose secrets through source code, configuration, logs, or runtime behavior. Because Flask relies on Python files for route definitions and settings, developers often accidentally commit keys to version control or expose them via debug endpoints and error pages.

Hardcoding keys in Python source files is a typical pattern in small Flask projects. For example, developers may write API_KEY = "sk-12345" directly in app.py. If the repository is public or improperly access-controlled, this key is trivially discoverable. Even in private repos, key extraction from source history is a common reconnaissance step for attackers scanning for exposed credentials.

Configuration via environment variables mitigates some risk, but Flask apps can still leak keys through Python tracebacks and debug output. When DEBUG=True, detailed error pages may reveal configuration values or paths that hint at key locations. Routes that echo user input into logs or error messages can inadvertently surface tokens if exceptions include request details.

Flask’s modular imports can also create exposure when developers load keys dynamically using Python’s os.getenv or open() and then pass those keys to external services. If the loading code resides in a module that is imported broadly, any route that calls into that module may expose the key’s scope through logs, monitoring integrations, or insecure inter-service communications.

Insecure deserialization and improper request handling in Python can further amplify exposure. For instance, accepting JSON or form data and embedding it directly into responses or logs may include key-like strings that get persisted or indexed. SSRF patterns in Flask endpoints can cause the server to make outbound requests using injected credentials, revealing keys through external logs or network traces.

middleBrick scans these vectors by checking for hardcoded secrets in Python code, unsafe debug configurations, risky import patterns, and runtime exposures across the unauthenticated attack surface. This includes tracing how keys flow through request handling and whether they appear in error outputs, logs, or unexpected endpoints.

Secure handling of API keys in Flask with Python focuses on avoiding hardcoded values, isolating secrets, and minimizing exposure through error handling and logging. Use environment variables and configuration objects that are never committed to source control.

Example of vulnerable code to avoid:

import os
from flask import Flask, request, jsonify

app = Flask(__name__)

# Vulnerable: hardcoded key
API_KEY = "sk-12345abcdef"

@app.route("/call")
def call_external():
    # Using hardcoded key directly
    headers = {"Authorization": f"Bearer {API_KEY}"}
    # ... make request
    return jsonify({"status": "ok"})

if __name__ == "__main__":
    app.run(debug=True)  # Dangerous in production

Remediation with environment-based configuration:

import os
from flask import Flask, jsonify

app = Flask(__name__)

# Load from environment, with a clear error if missing
API_KEY = os.getenv("EXTERNAL_API_KEY")
if API_KEY is None:
    raise RuntimeError("Missing required environment variable: EXTERNAL_API_KEY")

@app.route("/call")
def call_external():
    headers = {"Authorization": f"Bearer {API_KEY}"}
    # ... make request securely
    return jsonify({"status": "ok"})

if __name__ == "__main__":
    # Use a production WSGI server in real deployments
    app.run(debug=False)

Use a configuration class to separate settings by environment and avoid accidental exposure:

import os
from flask import Flask, jsonify

class Config:
    API_KEY = os.getenv("EXTERNAL_API_KEY")
    DEBUG = False

class DevConfig(Config):
    DEBUG = True

app = Flask(__name__)
app.config.from_object(os.getenv("FLASK_CONFIG", "config.Config"))

@app.route("/call")
def call_external():
    if app.config["API_KEY"] is None:
        return jsonify({"error": "Server misconfiguration"}), 500
    headers = {"Authorization": f"Bearer {app.config['API_KEY']}"}
    return jsonify({"status": "ok"})

Additional Python-specific practices include using python-dotenv for local development with a .env file that is added to .gitignore, rotating keys regularly, and ensuring logs do not capture full key values. For production, rely on your platform’s secret store integration and restrict network egress from the Flask service to reduce the impact of a potential leak.

middleBrick’s checks include scanning Python source for hardcoded secrets, validating configuration patterns, and detecting risky runtime behaviors such as debug mode in production-like scans.