Por framework
Seguridad de Django — DEBUG, SECRET_KEY y autorización
Django tiene valores por defecto seguros, pero los incidentes vienen de la configuración: DEBUG=True en producción (exposición de ajustes/secretos), una SECRET_KEY filtrada y autorización débil. Pon DEBUG=False, carga SECRET_KEY desde el entorno, autoriza de forma explícita. Defensivo, sin pasos de ataque.
Para: cualquiera que ejecute una app de Django. Aquí no hay pasos de ataque, solo mantener funcionando los valores por defecto seguros mientras cierras los huecos que abre la configuración. Para el panorama completo, consulta el centro de seguridad por framework.
Los tres grandes tropiezos (se abren en la configuración)
Los valores por defecto de Django son excelentes, pero estos tres son tuyos para protegerlos en la configuración y el código.
① DEBUG=True en producción
La página de error expone ajustes, variables de entorno, secretos. Extraídos mediante errores deliberados.
② SECRET_KEY filtrada
Base de firmas/sesiones/CSRF. Una fuga arriesga falsificación y manipulación.
③ Autorización débil
Autenticado pero faltan comprobaciones de permiso/propietario. Un cambio de ID revela datos de otros.
Vigila también la SQLi por raw()/extra() o interpolación de cadenas, la deserialización insegura (pickle), ALLOWED_HOSTS sin configurar y los CVE de dependencias (pip) sin parchear.
Cómo cerrarlas (3 pasos)
DEBUG=False + ALLOWED_HOSTS en producción
ALLOWED_HOSTS correctamente. Evita que se muestren errores detallados externamente y configura el servido de estáticos/media para producción. Incorpóralo al despliegue y verifícalo cada vez.Carga SECRET_KEY desde el entorno, mantenla privada
SECRET_KEY en el código/repositorio — cárgala desde una variable de entorno o un gestor de secretos. Mantenla fuera de los directorios públicos y de las páginas de DEBUG, y rótala de inmediato si se filtra (→ mantén los secretos fuera de los directorios públicos).Haz la autorización explícita y corta las rutas de entrada peligrosas
raw(), y no restaures datos no confiables con pickle. Mantén las dependencias (pip) con CVE monitoreados + parcheados rápido (→ qué es IDOR).Común (peligroso)
- producción dejada en
DEBUG=True SECRET_KEYincrustada en el código/repositorio- sin autorización — "con sesión = puede ver"
- interpolación de cadenas en
raw()·picklesobre datos no confiables
Correcto
- producción DEBUG=False + ALLOWED_HOSTS
-
SECRET_KEYdesde el entorno, mantenida privada - autorización explícita (ámbito de permiso/propietario)
- ORM/marcadores de posición, sin deserialización de datos no confiables
La visión de este sitio: con las pilas incluidas, pero la configuración y la autorización corren de tu cuenta
Django protege mucho por defecto, pero los ajustes de producción (DEBUG/SECRET_KEY/ALLOWED_HOSTS) y la autorización son cosas que debes acertar por entorno y por app. Los incidentes que seguimos viendo son menos ataques elaborados que patrones de configuración/operación: "debug estaba abierto en producción", "se expuso un secreto", "no había autorización". Así que el centro de gravedad es ajustar la configuración de producción, mantener los secretos privados y hacer explícita la autorización. No deshacer los sólidos valores por defecto es el quid de operar Django.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Laravel (DEBUG-en-producción / exposición de secretos similares)
- Secretos: mantén los secretos fuera de los directorios públicos · Práctica: el manual de respuesta a vulnerabilidades
- Glosario: qué es IDOR · qué es la inyección SQL
FAQ
Q¿Django es un framework seguro?
Django viene 'con las pilas incluidas': la protección SQL basada en ORM, la protección CSRF, el autoescape de plantillas y un sistema de auth son estándar. Configurado correctamente es un framework sólido, pero los incidentes no vienen del núcleo sino de la configuración. DEBUG=True en producción, una SECRET_KEY filtrada y autorización débil se repiten menos como problemas específicos de Django que como problemas de operación/configuración.
Q¿Qué tiene de peligroso dejar DEBUG=True en producción?
Con DEBUG activado, la página de error puede mostrar detalles internos: ajustes, variables de entorno, trazas de pila. Un atacante puede provocar errores a propósito para extraerlos. En producción, pon siempre DEBUG=False y configura ALLOWED_HOSTS correctamente. Además, evita que se muestren errores detallados externamente y revisa el servido de archivos estáticos/media para producción.
Q¿Por qué es importante SECRET_KEY?
SECRET_KEY es la clave que sustenta las cookies firmadas y las sesiones, los tokens CSRF, los restablecimientos de contraseña y más. Una fuga puede llevar a falsificarlos o manipularlos. No pongas SECRET_KEY en el código ni en el repositorio: cárgala desde una variable de entorno o un gestor de secretos, y rótala de inmediato si se filtra. Evita también que quede expuesta por un directorio público o una página de DEBUG.