Missing Tls in Django with Mongodb

When a Django application communicates with a MongoDB backend without Transport Layer Security (TLS), credentials, session tokens, and query data can be exposed in transit. This is a data exposure control failure and often maps to OWASP API Top 10:2023 — API4:2023, Sensitive Data Exposure. middleBrick’s Data Exposure check would flag this as a high-severity finding, because unencrypted connections between the application and database can be intercepted on shared networks or via compromised routers.

In this stack, Django typically interacts with MongoDB through a driver such as pymongo or an ODM like MongoEngine. If the connection string does not enforce TLS (e.g., using mongodb:// instead of mongodb+srv:// with appropriate server settings, or missing TLS verification), the traffic remains plaintext. An attacker who can observe or manipulate network traffic might recover database credentials or inject malicious queries. Even when TLS is available, failing to verify the server certificate (e.g., setting tlsAllowInvalidCertificates=True or omitting certificate validation) can lead to man-in-the-middle attacks, undermining authentication and data confidentiality.

Django settings often centralize database configuration. If TLS parameters are omitted or incorrectly set, the risk is systemic. For example, relying on default driver behavior without explicitly enforcing certificate validation leaves the channel vulnerable. middleBrick’s Encryption check complements the Data Exposure scan by verifying that endpoints and backend services negotiate strong encryption. The scanner does not assume that using a standard port or a common library implies secure configuration; each connection string and TLS flag is validated to ensure end-to-end protection.

Moreover, regulatory frameworks such as PCI-DSS and GDPR require protection of data in transit. A missing TLS configuration can directly conflict with compliance requirements, especially when personal or payment data flows through the API. middleBrick maps findings to these frameworks, highlighting where unencrypted database access violates control objectives. Even in internal environments, unencrypted traffic can leak due to misrouted packets or compromised internal nodes, so TLS should never be treated as optional.

Because this stack involves an asynchronous, document-oriented database, injection and data exposure risks can be amplified if queries carry sensitive filters or projection data. An attacker who compromises a single API endpoint with weak input validation might leverage an unencrypted MongoDB channel to exfiltrate records at scale. This is why the combination of Django, MongoDB, and missing TLS is especially consequential: it broadens the impact of a single misconfiguration across authentication, data exposure, and possibly privilege escalation paths.

Remediation centers on enforcing TLS and validating certificates in all MongoDB connections from Django. Use a connection string that mandates TLS and provides a path to a trusted certificate authority. Avoid disabling certificate validation. Below are concrete examples using pymongo and MongoEngine.

1. Using pymongo with TLS enforced

from pymongo import MongoClient
from pymongo.ssl_support import get_ssl_context
import ssl

# Create an SSL context that enforces TLS and verifies the server certificate
ssl_context = get_ssl_context()
ssl_context.check_hostname = True
ssl_context.verify_mode = ssl.CERT_REQUIRED
ssl_context.load_verify_locations(cafile="/path/to/ca.pem")

# Connection string must use mongodb+srv:// or mongodb:// with +tls=true
client = MongoClient(
    "mongodb+srv://user:password@cluster0.example.com/mydb?retryWrites=true&tls=true&tlsCAFile=/path/to/ca.pem",
    ssl=True,
    ssl_cert_reqs=ssl.CERT_REQUIRED,
    ssl_ca_certs="/path/to/ca.pem",
    ssl_check_hostname=True
)
db = client.mydb
# Example operation
document = db.users.find_one({"email": "user@example.com"})
print(document)

2. Using MongoEngine with TLS in Django settings

# settings.py
import ssl

MONGOENGIE_CONNECT = {
    "db": "mydb",
    "host": "mongodb+srv://cluster0.example.com",
    "username": "user",
    "password": "password",
    "ssl": True,
    "ssl_cert_reqs": ssl.CERT_REQUIRED,
    "ssl_ca_certs": "/path/to/ca.pem",
    "ssl_check_hostname": True,
    "tlsAllowInvalidCertificates": False,
}

# Define a simple document class
from mongoengine import Document, StringField

class User(Document):
    email = StringField(required=True, unique=True)
    name = StringField()

# Query safely
user = User.objects(email="user@example.com").first()

3. Environment-driven configuration

Store sensitive paths and credentials via environment variables and ensure the runtime environment provides the CA certificate. This avoids hardcoding and supports different deployment targets.

import os
from pymongo import MongoClient
import ssl

ca_path = os.getenv("MONGO_CA_PATH", "/path/to/ca.pem")
client = MongoClient(
    os.getenv("MONGODB_URI"),
    ssl=True,
    ssl_cert_reqs=ssl.CERT_REQUIRED,
    ssl_ca_certs=ca_path,
    ssl_check_hostname=True,
)

4. Validation and testing

After applying these settings, verify that TLS is enforced by attempting a connection without valid certificates; it should fail. Use tools like openssl s_client to confirm that the server presents a valid certificate chain. middleBrick’s CLI can be run against your API to confirm that the encryption and data exposure checks pass, providing concrete remediation guidance.

For teams using the middleBrick Pro plan, continuous monitoring can detect regressions in encryption configuration and alert when connection strings drift toward insecure settings. The GitHub Action can gate merges if security thresholds are not met, while the Web Dashboard tracks scores over time.