Api Key Exposure in Fastapi with Oracle Db

When an API built with Fastapi uses an Oracle Db data source, developers often embed database credentials or long-lived service keys in application code or configuration files. If route handlers or middleware inadvertently expose these values—through error messages, debug endpoints, or overly verbose logging—an attacker can harvest credentials that provide direct access to the Oracle database. This typically occurs when exception handlers return full stack traces that include connection strings, when OpenAPI generation inadvertently includes sensitive parameters, or when health check endpoints echo configuration details.

Fastapi’s dependency injection and async route design can simplify secure credential handling, but if developers use global mutable state to store connection details or attach sensitive objects directly to request state, those references may leak into responses. For example, attaching an Oracle connection pool to the request state and returning it as part of a debug payload results in credential exposure. Similarly, misconfigured CORS or missing authorization on introspection routes can allow unauthenticated enumeration of endpoints that return sensitive metadata or configuration dumps.

An attacker who obtains an Oracle credential can pivot to sensitive tables containing PII, financial records, or configuration data. If the same credential is reused across environments or services, lateral movement becomes feasible. This pattern compounds risks when combined with other unchecked attack surfaces such as input validation flaws or SSRF, because an exposed credential can be exploited from outside the network perimeter.

middleBrick scans this attack surface by testing unauthenticated endpoints, inspecting OpenAPI specs for accidental parameter exposure, and checking whether runtime responses disclose configuration details. If your Fastapi app connects to Oracle Db and exposes any authentication material, middleBrick flags it with severity and remediation guidance, without making changes to your code.

Secure handling of Oracle credentials in Fastapi requires isolating secrets from request handling and ensuring runtime outputs never reflect configuration details. Use environment variables or a secrets manager at runtime, and never serialize connection objects or credentials into responses.

Secure dependency injection for Oracle connections

Define a reusable Oracle engine at module level and inject a lightweight session factory rather than raw connections. This avoids accidental exposure through request state.

import os
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker, Session

# Build the engine once, outside request handling
oracle_url = os.getenv("ORACLE_DSN")  # e.g., "oracle+cx_oracle://user:pass@host:1521/service_name"
engine = create_engine(oracle_url, pool_pre_ping=True)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

Route implementation that avoids leaking metadata

Use the dependency above and ensure handlers never return the session, engine, or raw configuration. Mask sensitive details in logs and disable debug endpoints in production.

from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.exc import SQLAlchemyError

router = APIRouter()

@router.get("/accounts/{account_id}")
def read_account(account_id: str, db: Session = Depends(get_db)):
    try:
        result = db.execute("SELECT id, currency, status FROM accounts WHERE id = :id", {"id": account_id}).fetchone()
        if result is None:
            raise HTTPException(status_code=404, detail="Account not found")
        return {"id": result[0], "currency": result[1], "status": result[2]}
    except SQLAlchemyError:
        # Log without exposing DSN or bind params
        raise HTTPException(status_code=500, detail="Database error")

Safe configuration and logging practices

Do not include credentials in exception responses or OpenAPI schemas. Configure logging to exclude connection strings and set CORS to limit origins.

import logging
from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI(docs_url="/api/docs")

# Restrict CORS to known origins
app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://app.example.com"],
    allow_credentials=True,
    allow_methods=["GET", "POST"],
    allow_headers=["Authorization", "Content-Type"],
)

# Structured logging that omits sensitive values
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

@app.get("/health")
def health():
    return {"status": "ok"}

Validation and error handling to prevent information leakage

Ensure that validation errors and SQL exceptions do not echo user input or internal DSNs. Use generic messages and structured error logging that omits sensitive context.

from fastapi import Request
from fastapi.responses import JSONResponse

@app.exception_handler(Exception)
def global_exception_handler(request: Request, exc: Exception):
    logger.error("Request failed", exc_info=True)  # logs full traceback server-side only
    return JSONResponse(
        status_code=500,
        content={"detail": "Internal server error"},
    )

Operational safeguards

Rotate Oracle credentials regularly, restrict database user permissions to least privilege, and avoid embedding secrets in source control. Use runtime injection via environment variables or secure vaults, and audit access logs for anomalous queries.

middleBrick can validate that your API does not expose credentials by scanning endpoints and inspecting the OpenAPI spec for unsafe parameter definitions. If findings appear, follow the remediation patterns above and rescans to confirm exposure is removed.