Api Key Exposure in Django with Session Cookies

Storing API keys in Django session cookies can inadvertently expose secrets through multiple vectors. Django’s session framework supports cookie-based sessions, where the session data is either stored in the cookie itself (using signed but not encrypted storage with SESSION_COOKIE_SECURE and SESSION_COOKIE_HTTPONLY settings) or stored server-side with a session key in the cookie. When developers place API keys directly into the session dictionary, the key may travel in the cookie payload if the session backend is configured to store data client-side, or it may be accessible via server-side session stores that are inadvertently exposed through misconfiguration or insecure deserialization.

Consider a pattern where an external service credential is loaded into the session after authentication:

request.session["api_key"] = external_service_api_key

If the session cookie is transmitted over unencrypted HTTP (missing SESSION_COOKIE_SECURE=True), an on-path attacker can capture the cookie. Even with HTTPS, if SESSION_COOKIE_HTTPONLY is not set, JavaScript running in the browser can read the cookie, enabling exfiltration via XSS. Additionally, if the session key is predictable or the signed cookie validation is bypassed, an attacker might forge a session containing the API key. In server-side session stores, if the store (e.g., cached database or file store) is not properly isolated and protected, an authenticated attacker who gains access to the store can enumerate session data and harvest embedded API keys.

Furthermore, cross-site request forgery (CSRF) can cause authenticated users to make unintended requests that expose session contents in logs or error messages, especially if the application reflects session data in responses. The combination of Django’s session cookie handling and insecure storage of sensitive credentials within the session creates a pathway for API key exposure, violating least-privilege and secret isolation principles.

To mitigate API key exposure, avoid storing API keys in session data entirely. If you must store sensitive material, use server-side session storage with strict access controls and ensure cookies are hardened.

First, enforce secure cookie transmission and protect against client-side leakage:

# settings.py
SESSION_COOKIE_SECURE = True   # send cookie over HTTPS only
SESSION_COOKIE_HTTPONLY = True # prevent JavaScript access
SESSION_COOKIE_SAMESITE = 'Lax' # or 'Strict' to reduce CSRF risk

Second, use server-side session storage and keep secrets out of the cookie payload. For example, using cached database sessions:

# settings.py
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'
SESSION_COOKIE_AGE = 1209600  # 2 weeks, adjust as needed

Third, never write API keys into the session dictionary. Instead, store references or use short-lived tokens retrieved from a secure vault at runtime:

# views.py
from django.contrib.auth.decorators import login_required
from django.core.cache import cache

@login_required
def safe_view(request):
    # Retrieve API key from a secure external source, not session
    api_key = cache.get(f"api_key_{request.user.id}")
    if api_key is None:
        # fetch from vault or environment, then cache temporarily
        api_key = fetch_api_key_for_user(request.user)
        cache.set(f"api_key_{request.user.id}", api_key, timeout=300)
    # use api_key for external call
    return render(request, 'template.html', {'status': 'ok'})

Fourth, rotate session keys and invalidate sessions on privilege changes:

# Rotate session key after login or privilege change
request.session.cycle_key()

Finally, validate and sanitize all inputs that influence session handling to prevent tampering and ensure integrity.