Api Key Exposure in Django with Oracle Db

Storing API keys in Django applications that use an Oracle Database can inadvertently expose credentials through configuration, logging, or ORM behavior. In Django, database credentials including those for an Oracle Db are often defined in settings.py or an environment-based configuration. If an API key is placed in a Django setting that is itself stored in the database or reflected into queries, it may be written to logs or exposed through an information disclosure vulnerability.

Oracle Database connections in Django are typically configured using a dictionary in DATABASES with keys such as ENGINE, NAME, USER, PASSWORD, and HOST. If developers mistakenly embed an API key within the OPTIONS dictionary, as a custom key, or within a connection string, the key may be passed as part of SQL session context or captured by database-level logging features on the Oracle side.

Additionally, Django’s ORM can expose sensitive data when debugging is enabled or when query logging is improperly configured. If an API key is stored in a model field and the model is registered with the Django admin without appropriate filtering, an authenticated user with list or change permissions may be able to view the key. Oracle-specific SQL tracing or the use of database links can also propagate key material into trace files that are readable by unauthorized users.

Another vector arises when using Django’s caching framework with an Oracle backend. Cached entries may inadvertently store serialized data containing API keys, and if the cache is shared or improperly isolated, other processes or tenants may access the sensitive content. MiddleBrick’s scans detect such exposure patterns by correlating OpenAPI specifications with runtime behavior, identifying unauthenticated endpoints that may reveal configuration or debug information related to API keys stored or referenced by the application.

To mitigate API key exposure when using Django with Oracle Database, ensure that sensitive values are never stored in the database or configuration files that persist in version control. Use environment variables or a secrets manager to inject keys at runtime, and reference them in settings using os.getenv.

Secure settings example

Define your Oracle connection without embedding keys in code. Use environment variables for sensitive values, including any API keys that must be accessible to the application layer.

import os

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.oracle',
        'NAME': os.getenv('ORACLE_SERVICE_NAME'),
        'USER': os.getenv('ORACLE_USER'),
        'PASSWORD': os.getenv('ORACLE_PASSWORD'),
        'HOST': os.getenv('ORACLE_HOST', 'localhost'),
        'PORT': os.getenv('ORACLE_PORT', '1521'),
        'OPTIONS': {
            'threaded': True,
        },
    }
}

API_KEY = os.getenv('EXTERNAL_API_KEY')
if not API_KEY:
    raise ImproperlyConfigured('Missing required environment variable: EXTERNAL_API_KEY')

Avoid passing API keys via database options

Do not include API keys in the OPTIONS dictionary or as part of the connection string. Oracle-specific settings such as events or editioning should not carry sensitive application-level keys.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.oracle',
        'NAME': os.getenv('ORACLE_SERVICE_NAME'),
        'USER': os.getenv('ORACLE_USER'),
        'PASSWORD': os.getenv('ORACLE_PASSWORD'),
        'OPTIONS': {
            'threaded': True,
            # Do not add API keys here
        },
    }
}

Restrict admin and logging exposure

Ensure that models containing sensitive fields are not fully exposed in the Django admin. Use list_select_related and field filtering to limit what is displayed, and avoid logging query parameters that may contain key material.

from django.contrib import admin
from .models import ExternalServiceConfig

@admin.register(ExternalServiceConfig)
class ExternalServiceConfigAdmin(admin.ModelAdmin):
    list_display = ('name', 'created_at')
    exclude = ('api_key', 'secret')

    def get_readonly_fields(self, request, obj=None):
        if obj:  # editing existing instance
            return ('api_key', 'secret')
        return ('api_key', 'secret')

Disable verbose SQL logging in production

Ensure that Django’s logging configuration does not capture full SQL statements with bound parameters, which may include sensitive context when using Oracle cursors.

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
        'django.db.backends': {
            'level': 'WARNING',  # Avoid 'DEBUG' in production
            'handlers': ['console'],
            'propagate': False,
        },
    },
}

By applying these Oracle-specific adjustments, Django applications reduce the risk of API key exposure through database configuration, logging, or ORM usage. Security scans via tools such as MiddleBrick can further validate that no sensitive values are unintentionally reflected in API contracts or runtime outputs.