Este es el texto traducido:
La regla dorada de la seguridad en aplicaciones web es nunca confiar en datos controlados por el usuario. Por lo tanto, toda la entrada del usuario debe ser sanitizada antes de utilizarse en tu aplicación. Consulta la documentación sobre formularios para obtener detalles sobre cómo validar las entradas del usuario en Django.
Los ataques XSS permiten a un usuario inyectar scripts cliente en los navegadores de otros usuarios. Esto se logra generalmente almacenando los scripts maliciosos en la base de datos, donde serán recuperados y mostrados a otros usuarios, o haciendo que los usuarios hagan clic en un enlace que causará que el atacante ejecute su JavaScript en el navegador del usuario. Sin embargo, los ataques XSS pueden proceder de cualquier fuente no confiable de datos, como cookies o servicios web, siempre que la data no esté suficientemente sanitizada antes de incluirse en una página.
El uso de plantillas Django te protege contra la mayoría de los ataques XSS. Sin embargo, es importante entender qué protecciones proporciona y sus limitaciones.
Las plantillas de Django escapan caracteres específicos que son particularmente peligrosos para HTML. Si bien esto protege a los usuarios contra la mayoría del input malicioso, no es completamente infalible. Por ejemplo, no protegerá lo siguiente:
<style class={{ var }}>...</style>
Si var está configurado en 'class1 onmouseover=javascript:func()', esto puede dar lugar a la ejecución de JavaScript no autorizado, dependiendo de cómo el navegador renderice HTML imperfecto. (Quotear el valor del atributo solucionaría este caso.)
Es importante ser particularmente cuidadoso cuando se utiliza is_safe con etiquetas de plantilla personalizadas, la segura etiqueta de plantilla, mark_safe, y cuando autoescape está desactivado.
Además, si estás utilizando el sistema de plantillas para mostrar algo que no sea HTML, puede haber caracteres e incluso palabras enteramente separados que requieren escapar.
You deberías ser muy cuidadoso al almacenar HTML en la base de datos, especialmente cuando ese HTML se recupera y se muestra.
Los ataques CSRF permiten a un usuario malicioso ejecutar acciones utilizando las credenciales de otro usuario sin que el usuario tenga conocimiento o consentimiento.
Django cuenta con protección contra la mayoría de los tipos de ataques CSRF, siempre y cuando hayas habilitado y utilizado correctamente la protección <using-csrf> donde corresponda. Sin embargo, como cualquier técnica de mitigación, existen limitaciones. Por ejemplo, es posible deshabilitar el módulo CSRF globalmente o para vistas específicas. Solo debes hacerlo si sabes lo que estás haciendo. Hay otras <csrf-limitations> si tu sitio tiene subdominios fuera de tu control.
La protección CSRF funciona <how-csrf-works> comprobando un secreto en cada solicitud POST. Esto garantiza que un usuario malicioso no pueda «reproducir» una solicitud POST a tu sitio y hacer que otro usuario conectado sin saberlo envíe esa forma. El usuario malicioso tendría que conocer el secreto, que es específico del usuario (utilizando una cookie).
Al desplegar con <security-recommendation-ssl>, CsrfViewMiddleware comprobará si la cabecera HTTP referer está configurada para un URL en el mismo origen (incluyendo subdominio y puerto). Dado que HTTPS proporciona seguridad adicional, es imperativo asegurarse de que las conexiones utilicen HTTPS donde esté disponible mediante la reenvío de solicitudes de conexión no seguras y utilizando HSTS para los navegadores compatibles.
Ten mucho cuidado al marcar vistas con el decorador csrf_exempt a menos que sea absolutamente necesario.
La inyección SQL es un tipo de ataque en el que un usuario malicioso puede ejecutar código SQL arbitrario en una base de datos. Esto puede dar lugar a la eliminación de registros o pérdida de datos.
Los conjuntos de consultas de Django están protegidos contra la inyección SQL ya que sus consultas se construyen utilizando la parametrización de consultas. El código SQL de una consulta está definido por separado del parámetro de la consulta. Dado que los parámetros pueden ser proporcionados por el usuario y, por lo tanto, son inseguros, están escapados por el motor de base de datos subyacente.
Django también da a los desarrolladores el poder de escribir consultas raw o ejecutar SQL personalizado. Estas capacidades deben usarse con moderación y siempre debes ser cuidadoso al escapar cualquier parámetro que el usuario pueda controlar. Además, debes ejercer precaución cuando se utiliza extra() y RawSQL.
La protección contra clickjacking es un tipo de ataque donde un sitio malicioso envuelve a otro sitio en una ventana. Este ataque puede resultar en que un usuario inocente sea engañado para realizar acciones no deseadas en el sitio objetivo.
Django contiene protección contra clickjacking en forma de el middleware X-Frame-Options, que en un navegador compatible puede prevenir que un sitio se renderice dentro de una ventana. Es posible deshabilitar la protección por vista o configurar el valor exacto del encabezado enviado.
El middleware se recomienda fuertemente para cualquier sitio que no necesite tener sus páginas envueltas en una ventana por sitios terceros, o solo necesite permitirlo para una pequeña sección del sitio.
Siempre es mejor para la seguridad desplegar tu sitio detrás de HTTPS. Sin esto, es posible que los usuarios maliciosos de red puedan sniffear las credenciales de autenticación o cualquier otra información transferida entre cliente y servidor, y en algunos casos – activos atacantes de red – alterar datos que se envían en una dirección.
Si deseas la protección que proporciona HTTPS y lo has habilitado en tu servidor, hay algunos pasos adicionales que debes seguir:
Si es necesario, establece SECURE_PROXY_SSL_HEADER, asegurándote de haber entendido las advertencias allí con cuidado. El fracaso a hacer esto puede resultar en vulnerabilidades CSRF, y el fracaso a hacerlo correctamente también puede ser peligroso.
Establece SECURE_SSL_REDIRECT a True, para que las solicitudes sobre HTTP se redirijan a HTTPS.
Ten en cuenta las limitaciones bajo SECURE_PROXY_SSL_HEADER. En el caso de un proxy inverso, puede ser más fácil o seguro configurar el servidor web principal para realizar la redirección a HTTPS.
Utiliza galletas «seguras».
Si un navegador se conecta inicialmente mediante HTTP, lo que es el valor por defecto para la mayoría de los navegadores, es posible que se filtren las cookies existentes. Por esta razón, debes establecer tus SESSION_COOKIE_SECURE y CSRF_COOKIE_SECURE configuraciones en True. Esto instruye al navegador para enviar solo estas cookies a través de conexiones HTTPS. Ten en cuenta que esto significará que las sesiones no funcionarán sobre HTTP, y la protección CSRF impedirá cualquier datos POST ser aceptados sobre HTTP (lo cual estará bien si estás redirigiendo todo el tráfico HTTP a HTTPS).
Usa Seguridad de Transporte Estricto (HSTS)
HSTS es un encabezado HTTP que informa a un navegador de que todas las conexiones futuras a un sitio en particular deben utilizar siempre HTTPS. Combinado con la redirección de solicitudes sobre HTTP a HTTPS, esto garantizará que las conexiones disfruten siempre de la seguridad añadida del SSL una vez haya ocurrido una conexión exitosa. HSTS puede configurarse con SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINS y SECURE_HSTS_PRELOAD, o en el servidor web.
Django utiliza el encabezado Host proporcionado por el cliente para construir URLs en ciertos casos. Si bien estos valores se limpian para prevenir ataques de Inyección de Script Cross Sitio, un valor falso de Host puede usarse para ataques de Falsificación de Solicitudes entre Sitios, ataques de contaminación de caché y contaminación de enlaces en correos electrónicos.
Porque incluso las configuraciones de servidores web que parecen seguras son susceptibles a cabeceras Host falsas, Django valida las cabeceras Host contra la configuración ALLOWED_HOSTS en el método django.http.HttpRequest.get_host().
Esta validación solo se aplica a través de get_host(). Si tu código accede directamente al encabezado Host desde request.META, estás evitando esta protección de seguridad.
Para más detalles, consulta la documentación completa de ALLOWED_HOSTS.
Advertencia
Previous versions de este documento recomendaban configurar tu servidor web para asegurarse de que valide los encabezados HTTP Host entrantes. Si bien esta recomendación sigue siendo válida, en muchos servidores web comunes una configuración que parece validar el encabezado Host no lo hace realmente. Por ejemplo, incluso si Apache está configurado para servir tu sitio Django desde un host virtual no predeterminado con el ServerName establecido, todavía es posible que un solicitud HTTP coincida con este host virtual y proporcione un encabezado Host falso. Por lo tanto, Django ahora requiere que configures explícitamente ALLOWED_HOSTS en lugar de confiar en la configuración del servidor web.
Además, Django requiere que habilites explícitamente el soporte para el encabezado X-Forwarded-Host (a través de la configuración USE_X_FORWARDED_HOST) si tu configuración lo requiere.
Los navegadores utilizan el encabezado Referer como una forma de enviar información a un sitio sobre cómo llegaron los usuarios. Al establecer una política del referente, puedes ayudar a proteger la privacidad de tus usuarios, restringiendo las circunstancias en que se establece el encabezado Referer. Consulta la sección de política del referente de la referencia de middleware de seguridad para obtener más detalles.
El encabezado de política de apertura entre origen (COOP) permite a los navegadores aislar una ventana principal de otras documentos colocándolos en un grupo de contexto diferente, por lo que no pueden interactuar directamente con la ventana principal. Si un documento protegido por COOP abre una ventana emergente de origen cruzado, la propiedad window.opener de la ventana emergente será null. COOP protege contra ataques entre origen. Consulta la sección de política de apertura entre origen de la referencia de middleware de seguridad para obtener más detalles.
De manera similar a las limitaciones de CSRF que requieren que un sitio esté desplegado de tal manera que los usuarios no confiables no tengan acceso a subdominios, también hay limitaciones en django.contrib.sessions. Consulta la guía de temas sobre seguridad de sesión para obtener más detalles.
Nota
Considera servir archivos estáticos desde un servicio en la nube o CDN para evitar algunos de estos problemas.
Si tu sitio acepta subidas de archivos, se aconseja fuertemente que limites estas subidas en la configuración del servidor web a un tamaño razonable con el fin de prevenir ataques de denegación de servicio (DOS). En Apache, esto se puede hacer fácilmente utilizando la directiva LimitRequestBody_.
Si estás sirviendo tus propios archivos estáticos, asegúrate de que manipuladores como Apache’s mod_php, que ejecutarían los archivos estáticos como código, estén deshabilitados. No quieres que los usuarios puedan ejecutar código arbitrario subiendo y solicitando un archivo especialmente diseñado.
Django posee vulnerabilidades en la gestión de carga de archivos multimedia cuando estos se sirven de manera que no sigue las mejores prácticas de seguridad. Específicamente, un archivo HTML puede ser cargado como imagen si ese archivo contiene una cabecera PNG válida seguida de código HTML malicioso. Este archivo pasará la verificación de la biblioteca que Django utiliza para el procesamiento de imágenes (ImageField) (Pillow). Cuando este archivo se muestra posteriormente a un usuario, puede ser mostrado como HTML dependiendo del tipo y configuración de tu servidor web.
No existe una solución técnica inquebrantable en el nivel del marco para validar con seguridad todo el contenido de los archivos cargados por los usuarios. Sin embargo, existen otros pasos que puedes tomar para mitigar estos ataques:
Una clase de ataques puede ser evitada siempre sirviendo el contenido cargado por los usuarios desde un dominio distinto a nivel superior o segundo nivel. Esto previene cualquier explotación bloqueada por las protecciones de política de origen (same-origin policy). Por ejemplo, si tu sitio corre en example.com, quieres servir el contenido cargado (la configuración MEDIA_URL) desde algo como usercontent-example.com. No es suficiente servir contenido desde un subdominio como usercontent.example.com.
Más allá de esto, las aplicaciones pueden elegir definir una lista de extensiones de archivo permitidas para los archivos cargados por los usuarios y configurar el servidor web para que solo sirva tales archivos.
Si bien Django proporciona buena protección contra ataques de seguridad, es importante aún desplegar tu aplicación correctamente y aprovechar la protección de seguridad del servidor web, sistema operativo y otros componentes.
Asegúrate de que tu código Python esté fuera de la raíz del servidor web. Esto garantizará que tu código Python no se sirva como texto plano (o accidentalmente se ejecute).
Ten cuidado con cualquier archivo cargado por el usuario (carga de archivos).
Django no limita las solicitudes para autenticar a los usuarios. Para protegerte contra ataques de fuerza bruta contra el sistema de autenticación, puedes considerar desplegar un plugin Django o módulo del servidor web para limitar estas solicitudes.
Manteniendo todas las etiquetas intactas, aquí están las traducciones:
Es una buena idea limitar el acceso a tu sistema de caché y base de datos mediante un firewall.
Toma un vistazo a la lista Top 10 del Proyecto de Seguridad en Aplicaciones Web (OWASP) lista Top 10 que identifica algunas vulnerabilidades comunes en aplicaciones web. Si bien Django tiene herramientas para abordar algunos de los problemas, otros deben tenerse en cuenta en el diseño de tu proyecto.
Mozilla discute varios temas relacionados con la seguridad web. Sus páginas también incluyen principios de seguridad que se aplican a cualquier sistema.
may 31, 2026