Comparar la configuración entre entornos

La prevención que propone OWASP para la configuración incorrecta tiene una frase que conviene llevar a la revisión: un proceso de endurecimiento repetible y automatizado, con la misma configuración en todos los entornos y credenciales distintas en cada uno. Que cambien los nombres de servidor, las bases de datos y las claves es lo esperado. Que cambie el endurecimiento es un hallazgo, y es más grave cuando el entorno más débil es producción.

Comparar es la técnica, y cada framework trae algo para hacerlo: Django compara un módulo de ajustes con otro, Spring muestra la configuración efectiva y de dónde salió cada valor, y Laravel resume la suya con php artisan about y config:show.

manage.py diffsettings muestra en qué difieren los ajustes cargados de los valores por defecto de Django o, con --default, de otro módulo de ajustes. Con la salida unificada, cada diferencia aparece en dos líneas: la del módulo de referencia y la del que se revisa. El trabajo del auditor es separar las diferencias esperadas (servidores, bases de datos, claves) de las que tocan el endurecimiento.

Abre tienda-diffsettings.txt. El encabezado explica qué signo corresponde a cada entorno.

En Spring Boot, application.properties lo leen todos los perfiles y application-prod.properties solo cambia las claves que repite exactamente. Una clave mal escrita no produce ningún error: es una propiedad más que nadie lee, y el valor del archivo base sigue en pie. El equipo cree haber apagado algo que sigue encendido.

Compara distribucion-application.txt con distribucion-application-prod.txt, clave por clave. Esto explica una de las respuestas que encontraste en el registro del proxy de la cuarta sala.

En producción, Laravel suele guardar toda la configuración en un solo archivo con config:cache. Su documentación advierte la consecuencia: desde ese momento el archivo .env no se carga, y la función env() solo devuelve variables del sistema. Por eso env() solo debe llamarse dentro de los archivos de config/, que son los que quedan en caché con su valor ya resuelto. Una llamada en cualquier otro sitio devuelve su valor de reserva en producción y el valor correcto en el portátil de quien la escribió.

Lee autores-about.txt para confirmar si la configuración está en caché y de dónde sale la variable. Después busca en autores-busqueda-env.txt la llamada que está fuera de config/ y qué decide.

Los tres hallazgos de esta sala tienen algo en común: el archivo dice una cosa y el proceso hace otra, y nadie lo vería leyendo solo el repositorio. El webhook de pagos que la tercera sala daba por bien protegido no verifica la firma en producción. La respuesta no es mirar más, sino comparar de forma automática: la configuración efectiva de cada entorno contra una de referencia, en el despliegue, con la comprobación de cada framework y un fallo que detenga la publicación.