Valores por defecto inseguros por framework

Cuando un ajuste no se escribe, su valor sale de uno de tres sitios, y conviene saber cuál antes de opinar. El primero es el valor por defecto del propio framework. El segundo es la plantilla que generó el proyecto: Django tiene DEBUG en falso como valor global, pero el archivo de ajustes que crea startproject lo pone en verdadero para comodidad de quien empieza; Laravel lee APP_DEBUG con falso como reserva, pero su archivo de ejemplo de entorno trae verdadero. El tercero es la ausencia: lo que el framework supone cuando falta una variable de entorno.

El auditor no pregunta qué valor trae el framework, sino de dónde sale el valor con el que corre este proceso.

El componente de sesiones más usado con Express decide varias cosas por quien no las escribe: el nombre de la cookie, que es el mismo en todas las aplicaciones que no lo cambian; los atributos de esa cookie, que no la limitan a HTTPS; y el almacén, que guarda las sesiones en la memoria del proceso, algo que su propia documentación dice que no está pensado para producción. Además, Express anuncia su nombre en una cabecera de cada respuesta hasta que alguien lo desactiva.

Ninguno de esos valores es una vulnerabilidad por sí solo; todos son decisiones que nadie tomó. Abre boletin-servidor.js y cabeceras-guardadas.txt.

Express decide su entorno con la variable NODE_ENV, y cuando falta supone un valor que no es el de producción. De ese valor dependen cosas que se notan, como que el manejador de errores por defecto envíe la traza al visitante, que es lo que viste en la primera sala. La unidad del boletín no define esa variable. Lee la línea de arranque en boletin-arranque.log: el servidor imprime el entorno que cree tener.

Django no limita por defecto su cookie de sesión a HTTPS: hay que pedirlo con un ajuste. Lo mismo pasa con la cookie de CSRF. El archivo de producción de la tienda no dice nada de cookies porque, según su comentario, Django ya trae lo necesario. La comprobación de despliegue sí lo dice.

Mira la cookie de la tienda en cabeceras-guardadas.txt, compárala con las del portal de autores y de distribución, y busca después el ajuste en tienda-check-deploy.txt. Fíjate de paso en la nota del final y en cómo calcula DEBUG el archivo de producción: ahí está la respuesta a la contradicción que viste en la primera sala.

No todos los valores por defecto son débiles. Algunos frameworks eligen bien y el hallazgo es el cambio: Spring Boot publica por HTTP solo la salud de Actuator, y la consola H2 viene apagada. Distinguir los dos casos cambia la recomendación. Un valor por defecto débil se corrige escribiendo el ajuste; un valor seguro que alguien cambió se corrige quitando el cambio y preguntando por qué se hizo. Abre distribucion-application.txt.