Information Disclosure in Django with Cockroachdb

Information disclosure occurs when an application unintentionally exposes sensitive data to an attacker. In Django applications using CockroachDB, this risk can arise from a combination of Django’s default behaviors, database-specific configurations, and insecure query patterns.

Django’s Object-Relational Mapper (ORM) encourages safe database access, but developers may bypass its protections. For example, using raw() or cursor.execute() without parameterization can lead to SQL injection, which often results in information disclosure. CockroachDB, while PostgreSQL-wire compatible, exposes certain system tables and diagnostic views (e.g., crdb_internal.node_statements) that, if accessible, can reveal query patterns, execution times, and user contexts.

Insecure error handling is another common vector. Django’s debug mode, when enabled in production, returns detailed tracebacks that may include database queries, schema names, and table structures. If CockroachDB returns specific error messages—such as constraint violations or privilege errors—those messages can disclose whether a table exists or what columns it contains. An attacker can use these cues to refine injection or enumeration attacks.

Excessive database permissions amplify the impact. When the database user has broader privileges than necessary (e.g., SELECT on system tables or access to other tenants’ schemas in a multi-tenant setup), an attacker who gains access via SQL injection can read sensitive rows. CockroachDB’s role-based access control allows fine-grained privileges; failing to apply least privilege increases the scope of disclosure.

Logging and monitoring misconfigurations also contribute. If application or database logs capture full queries—including sensitive values like authentication tokens or personal identifiers—those logs become a data exposure risk. CockroachDB audit logging, if enabled at a detailed level, can record full SQL statements; without proper retention controls, logs may expose data in plaintext or in accessible storage.

Finally, network and transport protections matter. CockroachDB clusters require proper TLS configuration. Without enforced encryption in transit, data exchanged between Django and the database can be intercepted, leading to disclosure of credentials or query content. Combining weak TLS settings with verbose error messages creates a scenario where an attacker can both intercept traffic and interpret server responses to infer internal details.

Remediation focuses on parameterization, least privilege, secure error handling, and proper logging. Below are concrete examples using CockroachDB with Django’s database backend.

1. Use parameterized queries with cursor

Always use parameterized SQL to prevent injection and reduce information leakage via errors.

import psycopg2
from django.db import connection

def get_user_by_email(email):
    with connection.cursor() as cursor:
        cursor.execute(
            "SELECT id, name FROM users WHERE email = %s",
            [email]
        )
        row = cursor.fetchone()
        return row

2. Apply least-privilege roles in CockroachDB

Create a dedicated role for Django with minimal required permissions. Avoid using the root or admin-like role.

-- Connect to the CockroachDB cluster as an admin user
CREATE ROLE django_app WITH LOGIN PASSWORD 'strong_password';
GRANT CONNECT ON DATABASE mydb TO django_app;
GRANT USAGE ON SCHEMA public TO django_app;
GRANT SELECT, INSERT, UPDATE ON users TO django_app;
-- Explicitly deny access to system tables
REVOKE ALL ON crdb_internal.* FROM django_app;
REVOKE ALL ON system.* FROM django_app;

3. Disable debug mode and customize error handling

Ensure DEBUG = False in production and use Django’s Handler400/Handler500 to avoid exposing stack traces.

# settings.py
DEBUG = False
ALLOWED_HOSTS = ['api.example.com']

# Custom handler to return generic errors
handler400 = 'myapp.views.custom_bad_request'
handler500 = 'myapp.views.custom_server_error'

4. Secure logging configuration

Filter sensitive data from logs and avoid logging full queries with parameters.

# settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
        'sensitive_data_filter': {
            '()': 'myapp.logging.SensitiveDataFilter',
        },
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'filters': ['sensitive_data_filter'],
        },
    },
    'loggers': {
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'WARNING',
            'propagate': False,
        },
    },
}

5. Enforce TLS for CockroachDB connections

Use SSL/TLS and verify server certificates to protect data in transit.

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydb',
        'USER': 'django_app',
        'PASSWORD': 'strong_password',
        'HOST': 'cockroachdb.example.com',
        'PORT': '26257',
        'OPTIONS': {
            'sslmode': 'verify-full',
            'sslrootcert': '/path/to/ca.pem',
            'sslcert': '/path/to/client.pem',
            'sslkey': '/path/to/client.key',
        },
    }
}

These steps reduce the likelihood of information disclosure by limiting what an attacker can learn from errors, logs, or direct database access.