Endurecer Django detrás de un proxy

01 / EL PROBLEMA

¿Para qué sirve?

Configuraciones copiadas sin conocer el proxy pueden provocar bucles HTTPS o confiar en cabeceras fabricadas. La seguridad exige verificar el entorno real.

02 / COMPRENDER

El concepto, explicado

DEBUG=False, SECRET_KEY fuera del código y ALLOWED_HOSTS explícito son controles de base. Una variable de entorno mejora separación, pero necesita protección del almacén, acceso y rotación.

SECURE_PROXY_SSL_HEADER solo es seguro si el proxy confiable elimina o controla la cabecera que recibe del cliente. Verifica ese contrato antes de usarlo.

HSTS compromete al navegador a usar HTTPS. Empieza con una duración corta mientras validas; includeSubDomains exige que todos funcionen por HTTPS. Preload requiere cumplir y solicitar requisitos del programa, no solo activar un booleano.

Cookies Secure, HttpOnly y SameSite tienen funciones diferentes. HttpOnly no impide todo XSS; CSRF, CSP y control de contenido se complementan. Las opciones de sesión se enseñan para apps que las usan; esta academia no añade login.

SECURE_PROXY_SSL_HEADER solo es seguro cuando el proxy confiable elimina o sobrescribe el header y no existe acceso directo no controlado. SESSION_COOKIE_SECURE y CSRF_COOKIE_SECURE requieren HTTPS; no se copian sin más al desarrollo HTTP.

No existe un middleware que resuelva toda la ciberseguridad. Combina escape de templates, validación de entrada, CSRF, autorización de API, límites, secretos, dependencia revisada, logs sin credenciales y pruebas. X_FRAME_OPTIONS=DENY bloquea incluso iframes propios: usa excepción SAMEORIGIN únicamente donde esté justificada.

Continúa con “Seguridad en production.py” para aplicar y comprobar HTTPS, confianza del proxy, cookies Secure y HSTS.

La lección siguiente muestra la política exacta de production.py y desglosa sus ajustes uno por uno. Esa política usa HSTS de un año con subdominios y preload; requiere HTTPS correcto en todo el alcance y una frontera de proxy confiable.

Control, alcance y comprobación

03 / CONSTRUIR

Implementación paso a paso

1. Ejecuta check --deploy sobre settings productivos y revisa configuración heredada.
2. Verifica TLS externo y cómo Django detecta request.is_secure detrás del proxy.
3. Valida hosts, secretos, logging sin datos sensibles y almacenamiento persistente.
4. Prueba redirecciones y cabeceras, después aumenta HSTS de forma gradual.
5. En una app con sesiones configura cookies y verifica CSRF en escrituras.
6. Añade CSP según scripts/estilos reales y supervisa reportes antes de endurecer.

# Fragmento para completar en settings productivos.
import os
DEBUG = False
SECRET_KEY = os.environ["SECRET_KEY"]
ALLOWED_HOSTS = os.environ["ALLOWED_HOSTS"].split(",")
SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_REFERRER_POLICY = "same-origin"
X_FRAME_OPTIONS = "DENY"
# SOLO con un proxy que controla la cabecera entrante:
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_SAMESITE = "Lax"
CSRF_TRUSTED_ORIGINS = ["https://sensorhub.example"]
# Si activas CSRF_COOKIE_HTTPONLY, toma el token del DOM renderizado.
# El timeout de sesión se decide según el riesgo y tipo de aplicación.

Cómo leer el ejemplo

• La falta de SECRET_KEY falla al inicio, no genera una clave productiva por defecto.
• El fragmento no equivale a una revisión completa de seguridad.
• No se activa preload ni subdominios sin evaluar consecuencias.

06 / VERIFICAR

Cómo sabes que funciona

• check --deploy se ejecuta con settings correctos.
• No hay bucles ni hosts comodín injustificados.
• Secretos y cookies no se filtran en logs.

Para profundizar

Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.

• Checklist de despliegue Django ↗
• Settings de seguridad ↗